21.2 Konfiguration eines OpenSSH-Servers
Viele Unix-Systeme haben bereits einen SSH-Server vorinstalliert, und im Fall der weit verbreiteten Unix-Derivate Linux, Free-, Net- und OpenBSD handelt es sich meist um OpenSSH. Aus diesem Grund wollen wir im Folgenden eine typische Konfigurationsdatei (meist in /etc/ssh/sshd_config gespeichert) auszugsweise behandeln und entsprechend kommentieren.
/etc/ssh/sshd_config
Schauen wir uns also den ersten Teil der Konfiguration an:
Listing 21.1 Netzwerkeinstellungen
# 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
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 ist es jedoch sinnvoll, einen anderen Port für den Dienst zu wählen.
Security by Obscurity
Die meisten Port-Scanner suchen nämlich alle (privilegierten) Ports unterhalb von 1024 sowie eben die durch die IANA festgelegten »Known Ports« ab. Wählt man nun einen entsprechend »hoch« gelegenen Port, der auch nicht in der /etc/services auftaucht, hat man relativ gute Chancen, unentdeckt zu bleiben. Dies ist natürlich noch keine Sicherheit im eigentlichen Sinne, aber man muss Hacker ja nicht mutwillig provozieren, wenn man diesen Dienst schon anbieten will oder muss.
Listing 21.2 Protokolleinstellungen
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
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 zur Ablage der privaten Schlüssel des Systems angegeben werden.
Listing 21.3 Sicherheitseinstellungen
#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
Eine recht wichtige Option ist UsePrivilegeSeparation, die nach dem erfolgreichen Einloggen die Kommunikation über einen Kindprozess 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 vorgegeben sowie die Einstellungen für den syslogd vorgenommen werden.
Listing 21.4 Authentifizierung
# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
Methoden der Authentifizierung
Die Zahl nach LoginGraceTime gibt an, nach wie vielen Sekunden die Verbindung vom Server her getrennt wird, falls sich der Benutzer nicht korrekt einloggen konnte. In der nächsten Zeile erlaubt 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, dass 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 ein- und ausschalten.
Listing 21.5 Rhosts
#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
In diesen Zeilen wird unter anderem festgelegt, dass die Dateien .rhosts und .shosts im Home-Verzeichnis 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.
Listing 21.6 Passwörter
#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
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.
Listing 21.7 ... und der Rest
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
X11-Forwarding
Im letzten Teil der Konfigurationsdatei können wir einstellen, ob der SSH-Server X11-Forwarding unterstützen soll. Haben der Server und der Client [Fn. Um das X11-Forwarding 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.
Des Weiteren 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. Sämtliche Informationen (auch zu den von uns ausgeklammerten Direktiven) finden Sie auch in der Manpage von sshd_config(5).
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
