Früher, als man noch jedem im Internet und sogar im Intranet vertraute, hat man sich ja einfach mit telnet in andere Rechner eingeloggt. Oder mit rlogin, damit die Umlaute auch funktioniert haben. Leider ging dabei das Password im Klartext über das Netz, was natürlich unverantwortlich ist.
Nun hat man also stattdessen ssh und es funktioniert recht ähnlich wie damals telnet, kann aber gleich noch sehr viel mehr, auch wesentlich mehr als ich hier in ein paar Zeilen schreiben kann. Wichtig ist nicht nur, dass man das Password verschlüsselt überträgt, sondern auch, dass man sicherstellt, dass die Gegenseite wirklich der gewünschte Rechner ist, sonst kan ein „man in the middle“ das Password abfangen und man ist wieder da, wo wir mit telnet standen.
Dazu gibt es im .ssh-Verzeichnis diese Zertifikate, also solche Dateien wie id_rsa und id_rsa.pub. Die id_rsa sollte man hüten wie seinen Augapfel, da die Sicherheit des ganzen Protokolls davon abhängt. Mit ssh-keygen kann man sich solche Zertifikate auch anlegen, wahlweise auch so, dass man bei deren Verwendung ein Password eingeben muss (das nur auf dem lokalen Rechner bleibt). Die Zertifikate haben sogenannte „Fingerprints“, die man sich mit ssh-keygen -l anzeigen lassen kann. Genau dieser Fingerprint wird beim ersten mal angezeigt und man muss ihn bestätigen. Man sollte diesen also auf einem sicheren Kanal vorher überprüfen, dass er auch wirklich stimmt, zum Beispiel wenn man zwischen zwei Rechnern in einem verkabelten Netz, dem man traut, aufeinander zugreift, oder indem an sich den Fingerprint notiert oder ausdruckt. Wenn man ihn einmal bestätigt hat, wird er in .ssh/known_hosts eingetragen und man kann dort natürlich auch aufräumen, indem man unnötige Einträge löscht. Oder sogar mit USB-Stick übertragene Fingerprints reineditieren, wenn man das Format verstanden hat. Solange known_hosts keine falschen Einträge enthält, hat ein „man in the middle“ es sehr schwer und das Verfahren bietet eine vernünftige Sicherheit.
Nun lässt sich der „public key“ aus id_rsa.pub des eigenen Rechners in .ssh/authorized_keys des Rechners, auf dem man sich einloggen will, eintragen. Damit erreicht man, dass das ohne Password-Abfrage möglich ist, außer das lokale Zertifikat braucht eine Password-Abfrage. Die kann man aber auch einmalig pro Session mittels ssh-add durchführen.
ssh wird auch für andere Zwecke verwendet, weil man andere Protokolle darüber tunneln kann, z.B. Subversion oder git.
Sehr schön ist es auch, wenn man unter X11 ein
ssh -X user@host
aufruft. Dann kann man auf dem entfernten Rechner grafische Applikationen starten und das Display wird über den ssh-Tunnel umgeleitet.
Display umleiten ist in der Unix- und Linux-Welt schon seit über 25 Jahren gängige Praxis, aber mit ssh geht es nun auch sicherer als mit den unverschlüsselten Protokollen, die man damals gerne verwendet hat. Wer kennt noch xhost +?
Diese Überlegungen beziehen sich auf ssh unter Linux, gelten aber auch für alle möglichen Unix-Systeme, wie z.B. Solaris. Auf MS-Windows-Rechnern gibt es putty als verbreitete SSH-Client-Implementierung. Mit Putty findet man sicher vieles von dem wieder, was das Linux/Unix ssh kann, nur in etwas anderer Verpackung. Ich bevorzuge aber auf MS-Windowsrechnern cygwin und dessen ssh-Implementierung, die sehr ähnlich funktioniert. Es ist sogar möglich, mit cygwin einen ssh-Server aufzusetzen. Allerdings ist der Vorgang nicht ganz einfach.
Schreibe einen Kommentar