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.
- Schlüssel generieren
- Schlüssel auf den Server kopieren
- Die Konfiguration des lokalen Clients anpassen
- Backup der originalen Konfiguration des Daemons
- Herunterladen und aktivieren der neuen Konfiguration
- 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
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.
Leider hast Du sie wieder aus dem gist genommen und ich muss somit den Link als nicht nutzbar markieren.
Hinterlasse einfach einen neuen Kommentar mit der neuen URL
Oh, ganz vergessen, dass ich den URL mal hier gepostet habe. Ja, es sind irgendwie über die Zeit zu viele Configs geworden, weshalb ich die alle mal in einem dotfiles-Repository zusammengefasst habe. Neuer URL ist: https://github.com/phoerious/dotfiles/blob/master/system/etc/ssh/sshd_config
X11Forwarding no
X11DisplayOffset 10
Wenn X11Forwarding deaktiviert ist, macht da X11DisplayOffset überhaupt noch Sinn?
Nein, ist durch gerutscht.
Danke dir für das Feedback.
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