Secure Shell (SSH) ist das gängige Protokoll, um sich übers Netz zur Fernwartung mit einem Linux-Rechner zu verbinden. Das Standard-Setup ist nicht schwer durchzuführen, zudem ist SSH verschlüsselt und bietet somit Sicherheit gegen das Ausspähen von Passwörtern. Neben einfachen Fernzugriff auf die Konsole bietet aber SSH noch wesentlich mehr.
Basisinstallation
Um auf einen Debian-Linux-Rechner per SSH zugreifen zu können, muss das Paket ssh-server installiert sein.
Sicherheitseinstellungen
Grundsätzlich empfiehlt sich einige zusätzliche Sicherheitsmaßnahmen gegen ungewollte Einbruchsversuche zu unternehmen. Gerade Rechner, die aus dem Internet erreichbar sind, werden oft durch Programme mit Bruteforce-Attacken belästigt. Erste Abhilfe schaffen ein paar einfache Maßnahmen.
Root-Login verbieten
Will man sich auf ein Fremdsystem verbinden, so ist fast bei allen Linux-Systemen ein Root-Konto vorhanden. Wenn dieses dann auch noch per SSH sich einloggen kann, ist für die Benutzername/Kennwort-Kombination schon einmal die Hälfte der benötigten Informationen beim Angreifer vorhanden. Deshalb verbieten wir dem Root-User das Login:
In der Konfigurationsdatei /etc/sshd/sshd_config mittels
PermitRootLogin No
das Login für root deaktivieren. Davor aber, sofern nicht vorhanden, einen Arbeitsbenutzer anlegen, der sich dann noch per SSH verbinden kann. Andernfalls sperrt man sich hier grandios vom Rechner aus. Nach der Änderung in der Konfigurationsdatei muss der Server mittels „/etc/init.d/sshd reload“ bzw. „service ssh reload“ (Ubuntu) die Konfiguration neu einlesen.
Port wechseln
Standardnetzwerkport für SSH ist Port 22 TCP. Dort versuchen auch Bruteforce-Angreifer als erstes ihr Glück. Um sich von solchen undifferenzierten Angriffen das Auth-Log nicht allzusehr vollmüllen zu lassen, kann man den Port wechseln. Auch hier nicht vergessen den Dienst die Konfigurationsänderungen mittels reload bekannt zu machen.
Dazu in der Konfigurationsdatei /etc/sshd/sshd_config die Zeile Port 22 gegen einen anderen Port tauschen. Dabei ist aber Vorsicht geboten, hier nicht auf einen belegten Port (z.B. den Port 80 des Webservers) zu wechseln. Wenn man zudem das System administrieren will und hinter fremden Firewalls sitzt, sind ungewöhnliche Ports oftmals blockiert.
Das ist natürlich auch kein Schutz gegen Angreifer, die gezielt den Rechner ins Visier nehmen, da diese auch sicherlich einen Portscan durchführen um weitere offene Ports zu finden. Aber es hält das gröbste Gesindel erstmal von Bruteforce-Attacken ab.
Login mit Public-Key
Passwort-Logins sind nicht nur manchmal nervig, da man sich Passwörter für verschiedenste Systeme merken muss, sondern auch je nach Passwortstärke begrenzt sicher. Deshalb kann man sich einen Schlüssel erstellen, mit dem man sich auf die Rechner verbinden kann. Wird dieser Schlüssel ohne Kennwort erstellt, so kann er z.B. verwendet werden um Skritpe automatisch per SSH auf den Rechner zugreifen zu lassen.
Dazu erstellt man sich auf seinem Admin-Rechner einen SSH-Key und kopiert den Public Key-Teil davon auf die entfernte Maschine. Unter Windows wird das mit puttygen erledigt und der Key dann auf den zu administrierenden Rechner in der Datei /home/user/.ssh/authorized_keys angehängt. Dann lässt sich in Putty der private Teil des Schlüssels noch hinterlegen und der Login mit Schlüssel sollte funktionieren.
Unter Linux lässt sich ein SSH-Schlüssel mittels
ssh-keygen -t rsa
erzeugen und dann mit dem Befehl
ssh-copy-id user@remotehost
auf den entfernten Rechner „remotehost“ kopieren.
Wenn man das Login per Public Key aktiv hat, kann man gleich noch eine zusätzliche Sicherheitsmaßnahme umsetzen, nämlich den Login „nur“ mit Passwort zu verbieten. Dazu in der Konfigurationsdatei PasswordAuthentication no setzen. Wie bei allen Änderungen muss die Konfiguration des SSH-Server neu geladen werden, um das zu übernehmen. Nun ist nur noch Login mittels Pubkey möglich.
Weitere Maßnahmen
Weitere Sicherheitsmaßnahmen bieten z.B. fail2ban, welches automatisch Firewallregeln gegen Rechner erstellt, die Bruteforce-Attacken durchführen.
Dateitransfer
Auch die Möglichkeit, Dateien per SSH zu kopieren, will ich kurz erwähnen. So können mit dem Befehl scp, analog zu cp, Dateien auch mit einem entferntes System ausgetauscht werden. Praktischerweise muss hier kein weiterer Port oder ein weiteres Programm auf beiden Rechnern installiert werden. Wenn der ssh-Server läuft, steht auch scp zur Verfügung.
Der Syntax ist angelehnt an cp einfach:
scp lokaledatei user@remote:entferntedatei
Damit wird lokaledatei auf den Rechner remote im Homeverzeichnis des Benutzers user abgelegt.
Zusätzlich kann auch mittels sftp zugegriffen werden. SFTP verhält sich in der Bedienung analog zu FTP-Programmen, überträgt aber die Dateien verschlüsselt auf Port 22. Das ist gerade sinnvoll, wenn z.B. Textdateien mit Klartextpasswörtern kopiert werden.
Die weitere Funktionsweise und der Syntax der Programme wird in den man-Pages ausführlich erklärt.
Bergbau: Wir tunneln
SSH bietet eine weitere tolle Möglichkeit: Ports von einem Rechner auf den anderen tunneln. Somit kann man z.B. einen Webserver-Port (z.B. Administrationsoberfläche unter Port 8080) auf den lokalen Port 80 des Arbeitsrechners legen. Das Geschickte daran: Es muss keinerlei zusätzliche Firewall-Regel für besondere Ports aufgemacht werden, man tunnelt diese Ports einfach über den 22/TCP.
ssh -L 80:localhost:8080
Damit wird der Port 8080 des entfernten Systems auf dem localhost Port 80 verfügbar gemacht. Rechner im Netz des localhosts können jetzt auf den Port 80 zugreifen, werden per SSH auf den remotehost getunnelt und erhalten die Daten vom Port 8080 des Server-Systems.
Eine andere Möglichkeit ist die Fernwartung eines Systems (hier Rechner3), welches keine feste IP-Adresse hat und somit einfach von außen angesprochen werden kann. Dazu wird der gewünschte Port zur Fernwartung auf dem Server unter einem anderen Port verfügbar gemacht. Der eigene Admin-Rechner kann sich dann auf den bekannten Port auf dem Server verbinden, und die Fernwartung des Rechners 3 durchzuführen. Am zu wartenden System ist ein Reverse-Tunnel mittels
ssh -R
aufzubauen. Am lokalen Admin-Rechner kann sich dann auf dem Remoteport des Servers verbunden werden. Und siehe da, man landet am Fernwartungsrechner. Damit lässt sich übrigens nicht nur der SSH-Port „durchschleifen“, sondern auch z.B. VNC.
Bei der ganzen Tunnelei ist zu beachten, dass fürs Erstellen von Ports < 1024 Root-Rechte auf dem System benötigt werden. Für Firewall-Admins ist das natürlich die Hölle, da SSH hier schicke Tunnelbauten an den Regeln vorbei zulässt. Je nachdem auf welchem Port SSH auf dem externen Server lauscht (z.B. Port 80), kann da nur noch eine Application-Firewall helfen, die den Verkehr im Detail analysiert und erkennt. Update: Kurz nachgelesen: Tunnel lässt sich auf einem Rechner mit folgenden beiden Zeilen der sshd_config abstellen:
AllowTcpForwarding no
X11Forwarding no
Damit kann der SSH-Server nicht mehr zum Tunneln genutzt werden.
Fazit
SSH bietet umfangreiche Administrationsmöglichkeiten und ist aus meiner täglichen Arbeit nicht wegzudenken. Ich hoffe mit den obigen Beispielen etwas die Vielseitigkeit gezeigt zu haben.
P.S.: Puffy, das Maskottchen von OpenSSH unterliegt nicht einer CC-Lizenz, siehe hier.