Es gibt so manche Dinge im Leben bei denen man sich fragt - wenn man sie
denn einmal herausgefunden hat - warum nicht gleich so? Eines dieser
Dinge ist bspw. eine eigene Konfigurationsdatei für ssh-Verbindungen.
Normalerweise sieht ein Login auf einem meiner Server nämlich so aus:
$ ssh -p 12345 -i ~/.ssh/server_key user@domain
Das ist vor allem immer eine elende Tipperei. Dabei geht es auch
einfacher, indem man das Ganze einfach in eine config-Datei schreibt und
in seinem Homeverzeichnis unter ~/.ssh/config ablegt:
Host Servername
HostName server.domain.de
Port 12345
User username
IdentityFile ~/.ssh/server_key
Danach kann man ganz einfach mit
sich zu seinem ssh-Server verbinden. Gerade wenn man mehrere
ssh-Verbindungen managen will (mit unterschiedlichen RSA-Keys) lohnt es
sich eine eigene Konfigurationsdatei anzulegen.
Richtig cool ist allerdings, dass man über ssh bestimmte Ports auf dem
Zielserver auf einen (nicht-privilegierten) Port auf dem lokalen Rechner
mappen kann. Ich kann also bspw. meinen internen Webserver der daheim
auf dem BananaPi zu administrativen Zwecken läuft auf einen beliebigen
Port meines Laptops mappen und so von außerhalb bequem darauf zugreifen.
Dazu muss man seine ~/.ssh/config nur wie folgt erweitern:
Host tunnel_zum_webserver
HostName server.domain.de
Port 12345
User username
IdentityFile ~/.ssh/server_key
LocalForward 4000 127.0.0.1:8080
Jetzt kann man mit
$ ssh -f -N tunnel_zum_webserver
eine einfache Verbindung zu seinem Webserver aufbauen und der ganze
Verkehr wird über ssh getunnelt :-)
Das ganze funktioniert nicht nur mit einem Webserver, sondern auch mit
allen anderen Diensten, die über das Netzwerk erreichbar sind, wie etwa
Samba-Freigaben oder ein MySQL-Server... :-)
Seit geraumer Zeit betreibe ich einen kleinen stromsparenden Server, der
auch über das Internet von überall mittels ssh erreichbar ist. Dieser
dient mir als Zugangspunkt zu meinem Heimnetzwerk, falls ich doch einmal
eine bestimmte Datei o. Ä. unterwegs brauche. Um diesen abzusichern,
sollte man die Standardkonfiguration ein wenig anpassen. Die
Konfigurationsdatei für den SSH-Server findet man unter
'/etc/ssh/sshd_config'.
Port umlegen
Standardmäßig arbeitet der SSH-Server auf dem Port 22. Das ist leider
auch so ziemlich jedem klar, der mit dem Begriff "SSH" etwas anfangen
kann. Was liegt also näher, als einfach einen anderen - möglichst von
keinem anderen Dienst belegten Port - einzustellen. Dazu trägt man in
der 'sshd_config' folgendes ein:
Einziger Nachteil ist, dass man von nun an beim Aufruf von ssh mit der
Option -p explizit den Port angeben muss. Allerdings bietet die Umlegung
des Ports allein keinen wirklichen Sicherheitsgewinn. Ein vollständiger
Portscan würde relativ schnell den richtigen Port enttarnen.
$ ssh -p 12345 user@serveradress.de
Rootlogin verbieten
Auf jeden Fall sollte man die Anmeldung als Root verbieten. So muss ein
potentieller Angreifer nicht nur das Passwort, sondern auch gleich noch
den richtigen Benutzernamen erraten. Um die Anmeldung als Root zu
verbieten muss die Option
...
Permit RootLogin no
...
gesetzt werden. Danach kann man sich nur noch mit einem "normalen" User
anmelden.
SSH-Keypair erzeugen
Wesentlich sicherer als die Eingabe eines bloßen Passwort ist die
Authentifizierung mittels RSA-Key. Dabei wird auf dem Client ein Private
Key und ein Public Key erzeugt und der Public Key anschließend auf den
Server transferiert. Die Erstellung eines RSA-Schlüsselpaars geschieht
über:
Danach kopiert man mittels folgendem Befehl den Schlüssel auf den
Server:
$ ssh-copy-id user@serveradress.de
Von nun an wird man bei der Authentifizierung immer nach der
RSA-Passphrase des RSA-Schlüssels gefragt, statt nach einem regulären
Passwort.
Passwortbasierte Anmeldung verhindern
Hat man einmal eine solche Authentifizierung eingerichtet, kann man
gleich auch die passwortbasierte Anmeldung unterbinden. Der Vorteil ist,
dass sich jetzt nur noch derjenige anmelden kann, der über den passenden
Schlüssel verfügt. Dazu muss man nur folgende Option setzen:
...
PasswortAuthentication no
...
Der Nachteil ist, dass man nun auf seinen private-Key Acht geben muss
und ihn irgendwo sicher aufbewahren muss. Hat man physisch keinen
Zugriff auf den Server, hilft bei Verlust des Schlüssels nur noch ein
trauriger Anruf beim Hoster.
StrictHostKeyChecking
Hat man einmal die Authentifizierung mittels RSA-Keys eingerichtet, ist
man im Prinzip schon recht gut abgesichert gegen Personen, die auf dem
Server nichts zu suchen haben. Hat man allerdings seinen Private-Key
verloren ist es prinzipiell dem Finder möglich sich auf dem Server
einzuloggen (falls er die richtige Passphrase für den Private Key
kennt). Zugegeben, dass sind schon recht viele Wenn's, aber 'Unverhofft
kommt oft :-)'Jedenfalls kann man zusätzlich noch das Strict Host Key
Checking aktivieren. Dazu setzt man folgende Option:
...
StrictHostKeyChecking yes
...
Das bewirkt, dass sich nur dem Server bereits bekannte Hosts anmelden
dürfen. Dabei wird der Client-Host-Key mit denjenigen Keys in der Datei
'\~/.ssh/known_hosts' bzw. '/etc/ssh/known_hosts' abgeglichen.
Fazit
Mit diesen relativ einfachen Mitteln hat man gegenüber der
Standardkonfiguration schon einiges an zusätzlicher Sicherheit gewonnen.
Absolute Sicherheit wird es wohl leider nie geben, sodass man auch
weiterhin Serverlast und die Log-Files auf Unstimmigkeiten überwachen
sollte. Man kann also nur hoffen, dass man es einem potentiellen
Angreifer so schwer wie möglich macht und dass dieser sich dann lieber
weniger aufwändigen Zielen zuwendet.