16.2 Konfiguration eines OpenSSH-Servers 
Viele Unix-Systeme haben bereits einen SSH-Server vorinstalliert, und bei den weit verbreiteten Unix-Derivaten Linux, Free-, Net- und OpenBSD handelt es sich dabei meist um OpenSSH. Aus diesem Grund wollen wir im Folgenden eine meist in /etc/ssh/sshd_config gespeicherte typische Konfigurationsdatei auszugsweise behandeln und danach entsprechend kommentieren.
16.2.1 Die /etc/ssh/sshd_config 
Schauen wir uns also den ersten Teil der Konfiguration an:
# Package generated configuration file # See the sshd(8) manpage for defails # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/ # protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0
Listing 16.1 Netzwerkeinstellungen
Hier legt man fest, auf welchem Port und gegebenenfalls auf welcher Adresse der SSH-Server Verbindungen entgegennehmen soll. Laut IANA ist Port 22 für SSH reserviert, manchmal macht es jedoch Sinn, einen anderen Port für den Dienst zu wählen.
Security by Obscurity
Die meisten Portscanner suchen nämlich alle (privilegierten) Ports unterhalb von 1024 sowie eben die durch die IANA festgelegten »Known Ports« ab. Wählt man beispielsweise einen entsprechend »hoch« gelegenen Port, der auch nicht in der /etc/services auftaucht, hat man relativ gute Chancen, unentdeckt zu bleiben.
Das ist natürlich keine Sicherheit im eigentlichen Sinne, aber man muss Hacker ja nicht mutwillig provozieren, wenn man diesen Dienst schon nach außen anbieten will oder muss.
Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key
Listing 16.2 Protokolleinstellungen
Unterstützte Protokollversionen
Im Folgenden kann man festlegen, welche Protokollversionen unterstützt werden sollen.
Das Beispiel aus dem vorhergehenden Listing beschränkt sich auf Version 2, aber theoretisch könnte man über die Direktive »1,2« auch beide Versionen unterstützen. Außerdem können hier die Dateien für die Ablage der privaten Schlüssel des Systems angegeben werden.
#Privilege Separation is turned on for security UsePrivilegeSeparation yes # ...but breaks Pam auth via kbdint, so we have to # turn it off Use PAM authentication via keyboard- # interactive so PAM modules can properly interface # with the user (off due to PrivSep) #PAMAuthenticationViaKbdInt no # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO
Listing 16.3 Sicherheitseinstellungen
Eine recht wichtige Option ist »UsePrivilegeSeparation«, die nach dem erfolgreichen Einloggen die Kommunikation über einen Kindprozesses des Servers laufen lässt, der mit den Rechten des eingeloggten Users gestartet wird. Außerdem können die Anzahl der Bits des Serverschlüssels sowie die Einstellungen für den syslogd vorgenommen werden.
# Authentication: LoginGraceTime 600 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys
Listing 16.4 Authentifizierung
Methoden der Authentifizierung
Die Zahl nach LoginGraceTime gibt an, nach wie vielen Sekunden die Verbindung vom Server getrennt wird, falls sich der Benutzer nicht korrekt einloggen konnte. In der nächsten Zeile erlaubt man dann per PermitRootLogin das Login des Superusers über SSH.
Bis auf einige Ausnahmefälle ist es nämlich unnötig und damit ein potenzielles Sicherheitsrisiko, wenn sich root remote einloggen kann. Schließlich kann sich ein Administrator als ganz normaler Benutzer einloggen und dann per su oder sudo seine Aufgaben erledigen.
Über die Direktiven RSAAuthentication und PubkeyAuthentication lässt sich jeweils die Möglichkeit des Einloggens über ein asymmetrisches Schlüsselpaar für SSH-Protokoll 1 beziehungsweise SSH-Protokoll 2 an- und ausschalten.
#rhosts authentication should not be used #RhostsAuthentication no #Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes #For this to work you will also need host keys in #/etc/ssh_known_hosts RhostsRSAAuthentication no #similar for protocol version 2 HostbasedAuthentication no #Uncomment if you don't trust ~/.ssh/known_hosts for #RhostsRSAAuthentication #IgnoreUserKnownHosts yes
Listing 16.5 Rhosts
In diesen Zeilen wird unter anderem festgelegt, dass die .rhosts und .shosts im Homeverzeichnis der Benutzer nicht für eine eventuell mögliche hostbasierte Authentifizierung verwendet werden. Da diese Authentifizierung an sich schon problematisch ist, sollte man diese Optionen, wie schon per Default festgelegt, besser nicht nutzen.
#To enable empty passwords, change to yes (NOT #RECOMMENDED) PermitEmptyPasswords no #Uncomment to disable s/key passwords #ChallengeResponseAuthentication no #To disable tunneled clear text passwords, change to #no here! PasswordAuthentication yes
Listing 16.6 Passwörter
Im ersten Abschnitt aus dem obigen Listing verbieten wir nun leere Passwörter und schalten gleichzeitig die Möglichkeit ein, sich mit einem Passwort einzuloggen. Würde man dagegen PasswordAuthentication auf no setzen, könnte man sich immer noch über Public-Key-Verfahren einloggen.
X11Forwarding no X11DisplayOffset 10 PrintMotd no #PrintLastLog no KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp /usr/lib/sftp-server UsePAM yes
Listing 16.7 ... und der Rest
X11 Forwarding
Im letzten Teil der Konfigurationsdatei können wir einstellen, ob der SSH-Server X11Forwarding unterstützen soll. Haben der Server und der Client <Um das X11Forwarding beim Client zu aktivieren, muss entweder in dessen Konfigurationsdatei die Option ebenfalls aktiviert oder alternativ das ssh-Kommandozeilenprogramm mit dem Parameter -X gestartet werden.> beide dieses Feature aktiviert, so kann man per ssh auf dem Server ausgeführte X11-Anwendungen auf dem Client als Fenster darstellen und bedienen.
Mit anderen Worten: So ist durch das mögliche Tunneln grafischer Anwendungen über den verschlüsselten SSH-Zugang eine komplette und vor allem auch sichere Remote-Administration von Unix-Servern möglich.
Weiterhin wird auch das bereits erwähnte sftp-Subsystem aktiviert und die Nutzung des PAM-Systems zur Verifikation des Logins erlaubt.
Ein SSH-Server bietet also vor allem sicherheitsrelevante Einstellungen, auf die wir uns im letzten Abschnitt konzentriert haben. Wirklich alle Informationen (auch zu den von uns ausgeklammerten Direktiven) finden Sie auf der Manpage von sshd_config(5).
