Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke. Häufig wird es verwendet, um lokal eine entfernte Kommandozeile verfügbar zu machen, das heißt, auf einer lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben und die lokalen Tastatureingaben werden an den entfernten Rechner gesendet. Genutzt werden kann dies beispielsweise zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Servers. Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP. (aus Secure Shell)
Per Default wird nach dem Aufbau des ssh-Verbindung eine interaktive Login-Session für den entsprechenden User aufgebaut. In manchen Fallgestaltungen ist ein eingeschränkterer Zugriff gewünscht. Mittels Forced Commands können die verfügbaren Befehle durch Vorgaben in der ~/.ssh/authorized_keys
eingeschränkt werden.
Um die Angriffsfläche eines (ssh)-Servers zu verringern, kann man die folgenden beiden Maßnahmen ergreifen. Dies gilt insbesondere dann, wenn der Server aus dem Internet erreichbar ist.
Auf vielen Systmen ist root der einzige Account mit Remote-Zugriff und einem bekannten Benutzernamen. Damit ist er ein gutes Ziel für Brute-Force-Angriffe1). Wenn dieser Account gehackt wird, ist er aufgrund der umfassenden Benutzerrechte eine besonders lohnender Beute. Auf anderen Systemen ist der Account bereits „deaktiviert“.2)
Dort, wo der root-Account noch aktiv ist, sollte für diese Benutzerkennung den Remote-Zugriff unterbunden werden.3) Die notwendigen administrativen Aufgaben können mit einem „normalen“ Account unter Verwendung von sudo
erledigt werden.4)
Um den ssh-Remote-Zugang für root zu sperren, wird in der Datei /etc/ssh/sshd_config
den Eintrag PermitRootLogin
auf no
gesetzt.
PermitRootLogin no
sudo
tatsächlich funktioniert.
Die Änderung wird erst mit dem Restart des ssh-Daemons 5) (oder ersatzweisem Reboot des Rechners) aktiv.
Die Authentifizierung über Public-Keys erleichtert nicht nur den ssh-Zugang, sondern vermindert durch den Wegfall der Passworteingabe auch die Angriffsfläche des ssh--Servers, weil damit die Möglichkeit der Brute-Force-Angriffe reduziert wird. Dieser Sicherheitsvorteil kann nur realisiert werden, wenn die Passwort-Authentifizierung unterbunden wird.
Hierfür werden in der Datei /etc/ssh/sshd_config
die Einträge ChallengeResponseAuthentication
und PasswordAuthentication
jeweils auf no
gesetzt.
ChallengeResponseAuthentication no PasswordAuthentication no
/etc/ssh/sshd_config
den Eintrag UsePAM
auf no
zu setzen ist, finden sich unterschiedliche Antworten. Nach meiner Erfahrung funktioniert es unabhängig von der Stellung des Eintrags UsePAM
.
Ich empfehle hier, sich sicherheitshalber selbst ein Bild zu machen.
~/.ssh/authorized_keys
die Public-Keys mehrerer Rechner abgelegt worden sein. Anderenfalls besteht die Gefahr, dass man sich aus dem eigenen System ausschließt, wenn der Zugriff ausschließlich remote möglich ist..
Die Änderung wird erst mit dem Restart des ssh-Daemons 6) (oder ersatzweisem Reboot des Rechners) aktiv.