Grundlage für eine sichere sshd_config

Meine grundlegende Konfigurationsdatei für OpenSSH, getestet mit Version 7.2.

Ich nutze als Werkzeug für das Überprüfen der Konfigurationen von openSSH das Werkzeug  ssh-audit von Github.

Das Pythonscript ist im Gegensatz zu der Wikiseite der Mozilla Foundation, auf dem letzten Stand der Technik für die Konfigurationen. Ich überprüfe mit diesem Script die Konfiguration monatlich die Konfiguration. Neben den einschlägigen Mailinglisten ist dies für mich eine Möglichkeit um auf dem sichersten Stand zu bleiben. Einen Besuch des Projektes auf Git und das Eingliedern in die Administrationswerkzeuge empfehle ich auf jeden Fall.

Ich habe meine sshd_config auf ein Gist gelegt, von welcher sie geforkt,  heruntergeladen und/oder bearbeitet werden kann.
Bei der Konfiguration habe ich die Einträge für das Bereitstellen des Servers auf verschiedenen IP-Adressen ignoriert und somit hört der Daemon auf jede IP des Servers, welches vielleicht nicht gewünscht ist. Hier kann/muss/sollte man die Konfiguration erweitern. Ich sehe diese Konfigurationsdatei nur als Grundlage an. Natürlich kann es sein, dass die Konfiguration für manche alte Clients und Endgeräte nicht funktioniert. Ich empfehle zu Überdenken, ob man wirklich die Verbindung so weit schwächen möchte um diesen Clients Zugang zu verschaffen.

Wie man Titel entnehmen kann ist sie eine Momentaufnahmen, denn schon Morgen kann sie veraltet sein und wie ich im ersten Absatz erwähne, sie muss turnusmäßig überprüft werden. Ich schließe jede Haftung meinerseits aus und diese Konfiguration könnte zu unmöglichen Problemen führen und es ist zu empfehlen sich einmal mit einer Reperaturkonsole zu befassen.

sshd_config

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel VERBOSE 
LoginGraceTime 1m 
PermitRootLogin no 
StrictModes yes
RSAAuthentication yes 
PubkeyAuthentication yes
AuthorizedKeysFile	%h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no 
X11Forwarding no 
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
ClientAliveInterval 600
ClientAliveCountMax 0

AllowUsers DEINUSERNAME

KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com

Step by Step SSH

Bitte einmal komplett durchlesen und Schritte nachvollziehen.

  1. Schlüssel generieren
  2. Schlüssel auf den Server kopieren
  3. Die Konfiguration des lokalen Clients anpassen
  4. Backup der originalen Konfiguration des Daemons
  5. Herunterladen und aktivieren der neuen Konfiguration
  6. Testweise einloggen mit dem lokalen Client

1. Schlüssel generieren und auf den Server kopieren

Für den Schlüssel muss ein geeignetes Passwort gewählt werden.

ssh-keygen -b 4096 -f .ssh/SERVERNAME
ssh-copy-id -i ~/.ssh/SERVERNAME NUTZERNAME@IPADRESSE

3. Die Konfiguration des lokalen Clients anpassen um Faul sein zu dürfen

vim .ssh/config
Host SERVERNAME
HostName SERVERIP
Port 22
User NUTZERNAME
IdentityFile ~/.ssh/SERVERNAMEDESERSTENAUFRUFS von ssh-keygen

4 und 5 Backup der originalen Konfiguration des Daemons und Herunterladen und aktivieren der neuen Konfiguration

Auf dem Server mit dem laufen SSHdaemon

[cmg@got-tty:~] $ sudo -s
[cmg@got-tty:~] # cd /etc/ssh/
[cmg@got-tty:/etc/ssh] # mv sshd_config sshd_configORIG
[cmg@got-tty:/etc/ssh] # wget https://gist.githubusercontent.com/seraphyn/f5321cba415e8c95552f3f86478965f6/raw/4de45336f5bdd8e4b6b67c4003701c3c42bb5602/sshd_config
[cmg@got-tty:/etc/ssh] # vim sshd_config
In AllowUsers deinen Benutzernamen einsetzen
[cmg@got-tty:/etc/ssh] # systemctl restart ssh.service
!!! Bitte nicht abmelden, da bei einem Fehler ein Anmelden nicht möglich ist !!!

6 Testweise einloggen mit dem lokalen Client

ssh SERVERNAME

Nun in einem neuen Terminal auf dem Client sich via ssh SERVERNAME anmelden.
Als SERVERNAME bitte jenen welcher in der Datei .ssh/config unter HOST definiert wurde.

6.1 Wenn dies nicht funktioniert, ausführlichen Login aktivieren

Redselig wird der Zugang via ssh mit der Option -v

ssh -v SERVERNAME

Noch Redseliger wird der Zugang mit der Option -vv

ssh – vv SERVERNAME

Am redseligsten wird der Zugang dann via -vvv ;)

ssh -vvv SERVERNAME

Normalerweise fallen hier schon die Fehler auf und können behoben werden

7 Gedanken zu „Grundlage für eine sichere sshd_config“

  1. Ich hab meine SSHD-Config auch mal zu meinen anderen Config-File-Gists hochgeladen $LINKFEHLERHAFT
    Die entspricht weitgehend deiner, aber ist etwas verschlankt, da ein paar alte SSH1-Optionen draußen sind. Außerdem hab ich noch die HostKeyAlgorithms den ssh-audit-Empfehlungen entsprechend angepasst. Da entsprechen die Defaults nämlich auch nicht immer dem, was man haben will.

  2. X11Forwarding no
    X11DisplayOffset 10

    Wenn X11Forwarding deaktiviert ist, macht da X11DisplayOffset überhaupt noch Sinn?

  3. Warum soll man pro Server jeweils einen eigenen Key auf Clientseite erzeugen? Wenn ein Angreifer Zugriff auf einen private Key aus .ssh/ hat, dann hat er auch Zugriff auf alle. Ich erkenne den Vorteil noch nicht.

    • Weil ich einen Key pro Kundenserver erstelle, somit habe ich Ordnung.
      Und wenn ich den Kunden nicht mehr habe, dann lösche ich auch den Schlüssel.
      Und Nein, ein Angreifer hat keinen Zugriff auf alle Keys, da sie verschlüsselt auf einem USB-Stick liegen, bzw nochmal verschlüsselt auf einem Share als Backup

Kommentare sind geschlossen.