SUSE Linux installiert das Paket OpenSSH standardmäßig. Daher stehen Ihnen die Programme ssh, scp und sftp als Alternative für telnet, rlogin, rsh, rcp und ftp zur Verfügung. In der Standardkonfiguration ist der Zugriff auf ein SUSE Linux-System nur mit den OpenSSH-Dienstprogrammen möglich, und nur wenn dies die Firewall erlaubt.

Mit ssh können Sie Verbindung zu einem entfernten System aufnehmen und dort interaktiv arbeiten. Es ersetzt somit gleichermaßen telnet und rlogin. Das Programm slogin ist lediglich ein symbolischer Link, der auf ssh weist. Sie können sich z. B. mit dem Befehl ssh sun auf dem Rechner sun anmelden. Der Host fordert Sie dann zur Eingabe des Passworts am System sun auf.

Nach erfolgreicher Authentifizierung können Sie dort in der Befehlszeile oder interaktiv, z. B. mit YaST, arbeiten. Sollten sich der lokale Benutzername und der auf dem entfernten System unterscheiden, können Sie einen abweichenden Namen angeben, z.B. ssh -l augustine sun oder ssh augustine@sun.

Darüber hinaus bietet ssh die von rsh bekannte Möglichkeit, Befehle auf einem entfernten System auszuführen. Im folgenden Beispiel wird der Befehl uptime auf dem Host sun ausgeführt und ein Verzeichnis mit dem Namen tmp angelegt. Die Programmausgabe erfolgt auf dem lokalen Terminal des Hosts earth.

ssh otherplanet "uptime; mkdir tmp" 
tux@otherplanet's password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Anführungszeichen sind hier zum Zusammenfassen der beiden Anweisungen in einem Befehl erforderlich. Nur so wird auch der zweite Befehl auf dem Host sun ausgeführt.

scp kopiert Dateien auf einen entfernten Computer. Es ist ein sicherer und verschlüsselter Ersatz für rcp. Beispielsweise kopiert scp MyLetter.tex sun: die Datei MyLetter.tex vom Host earth auf den Host sun. Wenn sich die Benutzernamen auf earth und sun unterscheiden, geben Sie den letzteren im Format benutzername@host an. Eine Option -l existiert für diesen Befehl nicht.

Nachdem das Passwort eingegeben wurde, beginnt scp mit der Datenübertragung und zeigt dabei den Fortschritt durch einen von links nach rechts anwachsenden Balken aus Sternen an. Zudem wird am rechten Rand die geschätzte Restübertragungszeit (bis zum Erreichen des rechten Balkenendes) angezeigt. Jegliche Ausgabe kann durch die Option -q unterdrückt werden.

scp bietet auch ein rekursives Kopierverfahren für ganze Verzeichnisse. Der Befehl scp -r src/ sun:backup/ kopiert den kompletten Inhalt des Verzeichnisses src einschließlich aller Unterverzeichnisse in das Unterverzeichnis backup auf dem Host sun. Das Unterverzeichnis wird automatisch angelegt, wenn es noch nicht existiert.

Die Option -p weist scp an, den Zeitstempel von Dateien unverändert zu belassen. -C sorgt für komprimierte Datenübertragung. Dadurch wird das zu übertragende Datenvolumen minimiert, aber der Prozessor stärker belastet.

Das Programm sftp kann anstelle von scp zur sicheren Dateiübertragung verwendet werden. Bei einer sftp-Sitzung können Sie viele bereits von ftp bekannte Befehle verwenden. Das Programm sftp ist gegenüber scp vor allem beim Übertragen von Daten, deren Dateinamen unbekannt sind, von Vorteil.

Damit die SSH-Clientprogramme ssh und scp eingesetzt werden können, muss im Hintergrund der SSH-Daemon laufen und an TCP/IP-Port 22 auf Verbindungen warten. Während des ersten Starts generiert der Daemon drei Schlüsselpaare. Die Schlüsselpaare bestehen jeweils aus einem privaten und einem öffentlichen (engl. public) Teil. Deshalb wird dies als ein Public-Key-basiertes Verfahren bezeichnet. Um die Sicherheit der Kommunikation über SSH zu gewährleisten, darf ausschließlich der Systemadministrator die Dateien der privaten Schlüssel einsehen. Die Dateirechte werden durch die Standardinstallation entsprechend eingestellt. Die privaten Schlüssel werden lediglich lokal vom SSH-Daemon benötigt und dürfen an niemanden weitergegeben werden. Demgegenüber werden die öffentlichen Schlüsselbestandteile (an der Namenserweiterung .pub erkennbar) an den Client weitergegeben, der die Verbindung anfordert. Sie sind für alle Benutzer lesbar.

Eine Verbindung wird vom SSH-Client eingeleitet. Der wartende SSH-Daemon und der anfragende SSH-Client tauschen Identifikationsdaten aus, um die Protokoll- und Softwareversion abzugleichen und eine Verbindung durch den falschen Port auszuschließen. Da ein untergeordneter Prozess des ursprünglichen SSH-Daemons antwortet, sind gleichzeitig viele SSH-Verbindungen möglich.

OpenSSH unterstützt zur Kommunikation zwischen SSH-Server und SSH-Client das SSH-Protokoll in den Versionen 1 und 2. Nach einer Neuinstallation von SUSE Linux wird automatisch die aktuelle Protokoll-Version 2 eingesetzt. Möchten Sie nach einem Update weiterhin SSH 1 beibehalten, folgen Sie den Anweisungen in /usr/share/doc/packages/openssh/README.SuSE. Dort ist ebenfalls beschrieben, wie Sie in wenigen Schritten eine SSH 1-Umgebung in eine funktionierende SSH 2-Umgebung umwandeln.

Bei Verwendung der SSH Protokoll-Version 1 sendet der Server dann seinen öffentlichen Host-Schlüssel und einen stündlich vom SSH-Daemon neu generierten Server-Schlüssel. Anhand dieser beiden verschlüsselt der SSH-Client einen von ihm frei gewählten Sitzungsschlüssel und sendet diesen an den SSH-Server. Der SSH-Client teilt dem Server zudem die gewählte Verschlüsselungsmethode (engl. cipher) mit.

Version 2 des SSH-Protokolls kommt ohne den Server-Schlüssel aus. Beide Seiten verwenden einen Algorithmus nach Diffie-Hellman, um ihre Schlüssel auszutauschen.

Die zur Entschlüsselung des Sitzungsschlüssels zwingend erforderlichen privaten Host- und Server-Schlüssel können nicht aus den öffentlichen Teilen abgeleitet werden. Somit kann allein der kontaktierte SSH-Daemon mit seinen privaten Schlüsseln den Sitzungsschlüssel entziffern (siehe man /usr/share/doc/packages/openssh/RFC.nroff). Diese einleitende Phase der Verbindung lässt sich mithilfe der Fehlersuchoption -v des SSH-Clients genau beobachten.

Version 2 des SSH-Protokolls wird standardmäßig verwendet. Jedoch kann mit dem Schalter -1 auch Version 1 des SSH-Protokolls erzwungen werden. Der Client legt nach der ersten Kontaktaufnahme mit einem entfernten Host alle öffentlichen Host-Schlüssel in ~/.ssh/known_hosts ab. So können so genannte „man-in-the-middle“-Angriffe unterbunden werden, d. h. Versuche von fremden SSH-Servern, Name und IP-Adresse eines anderen vorzutäuschen. Derartige Angriffe fallen entweder durch einen Host-Schlüssel auf, der nicht in ~/.ssh/known_hosts enthalten ist, oder durch die Unfähigkeit des Servers, den Sitzungsschlüssel mangels des passenden privaten Gegenstücks zu entschlüsseln.

Es empfiehlt sich, die in /etc/ssh/ abgelegten privaten und öffentlichen Schlüssel extern und gut geschützt zu archivieren. So können Änderungen der Schlüssel erkannt und nach einer Neuinstallation die alten wieder eingespielt werden. Dies erspart den Benutzern beunruhigende Warnungen. Wenn sichergestellt ist, dass es sich trotz der Warnung um den korrekten SSH-Server handelt, muss der vorhandene Eintrag zu diesem System aus ~/.ssh/known_hosts entfernt werden.

Nun erfolgt die eigentliche Authentifizierung, die in ihrer einfachsten Form aus der Eingabe eines Passworts besteht, wie bereits oben erwähnt. Ziel von SSH war die Einführung einer sicheren, aber zugleich bedienerfreundlichen Software. Wie bei den abzulösenden Programmen rsh und rlogin muss deshalb auch SSH eine im Alltag einfach zu nutzende Authentifizierungsmethode bieten. SSH realisiert dies mithilfe eines weiteren Schlüsselpaares, das vom Benutzer erzeugt wird. Dazu liefert das SSH-Paket ein Hilfsprogramm: ssh-keygen. Nach der Eingabe von ssh-keygen -t rsa oder ssh-keygen -t dsa wird das Schlüsselpaar generiert und der Basisdateiname zur Ablage der Schlüssel erfragt.

Bestätigen Sie die Voreinstellung und beantworten Sie die Frage nach einem Passwortsatz Auch wenn die Software einen leeren Passwortsatz vorschlägt, sollte bei der hier beschriebenen Vorgehensweise ein Text von 10 bis 30 Zeichen Länge gewählt werden. Verwenden Sie keine kurzen und einfachen Wörter oder Phrasen. Bestätigen Sie die Eingabe, indem Sie den Passwortsatz wiederholen. Anschließend wird der Speicherort des privaten und öffentlichen Schlüssels, in unserem Beispiel der Dateien id_rsa und id_rsa.pub, ausgegeben.

Verwenden Sie ssh-keygen -p -t rsa oder ssh-keygen -p -t dsa, um Ihren alte Passwortsatz zu ändern. Kopieren Sie den öffentlichen Teil des Schlüssels (in unserem Beispiel id_rsa.pub) auf den entfernten Computer und speichern Sie ihn dort unter ~/.ssh/authorized_keys. Zur Authentifizierung werden Sie beim nächsten Verbindungsaufbau nach Ihrem Passwortsatz gefragt. Sollte dies nicht der Fall sein, überprüfen Sie bitte Ort und Inhalt dieser Dateien.

Auf Dauer ist diese Vorgehensweise mühsamer als die Eingabe eines Passworts. Entsprechend liefert das SSH-Paket ein weiteres Werkzeug, ssh-agent, das für die Dauer einer X-Sitzung private Schlüssel bereithält. Dazu wird die gesamte X-Sitzung als untergeordneter Prozess von ssh-agent gestartet. Sie erreichen dies am einfachsten, indem Sie am Anfang der Datei .xsession die Variable usessh auf yes setzen und sich über einen Display-Manager, z. B. KDM oder XDM, anmelden. Alternativ können Sie ssh-agent startx verwenden.

Nun können Sie ssh oder scp wie gewohnt verwenden. Sofern Sie Ihren öffentlichen Schlüssel wie oben beschrieben verteilt haben, werden Sie jetzt nicht mehr nach Ihrem Passwort gefragt. Beenden Sie beim Verlassen Ihres Computers Ihre X-session unbedingt oder sperren Sie ihn durch eine entsprechende Anwendung, z. B. xlock.

Alle wichtigen Änderungen, die sich mit der Einführung von Version 2 des SSH-Protokolls ergeben haben, sind auch in der Datei /usr/share/doc/packages/openssh/README.SuSE dokumentiert.

Über die zuvor beschriebenen sicherheitsbezogenen Verbesserungen hinaus erleichtert SSH auch die Verwendung von entfernten X-Anwendungen. Insoweit Sie ssh mit der Option -X aufrufen, wird auf dem entfernten Computer automatisch die DISPLAY-Variable gesetzt und alle X-Ausgaben werden durch die bestehende SSH-Verbindung an den entfernten Computer exportiert. Gleichzeitig unterbindet dies die bisher bestehenden Abhörmöglichkeiten bei entfernt aufgerufenen und lokal betrachteten X-Anwendungen.

Durch Hinzufügen der Option -A wird der Authentifizierungsmechanismus von ssh-agent auf den nächsten Computer mit übernommen. So können Sie an unterschiedlichen Computern arbeiten, ohne ein Passwort eingeben zu müssen. Allerdings ist das nur möglich, wenn Sie zuvor Ihren öffentlichen Schlüssel auf die beteiligten Zielhosts verteilt und dort korrekt gespeichert haben.

Beide Mechanismen sind in der Voreinstellung deaktiviert, können jedoch in der systemweiten Konfigurationsdatei /etc/ssh/sshd_config oder der benutzereigenen Datei ~/.ssh/config permanent aktiviert werden.

ssh kann auch zur Umleitung von TCP/IP-Verbindungen benutzt werden. In den folgenden Beispielen wird SSH angewiesen, den SMTP- bzw. POP3-Port umzuleiten:

ssh -L 25:sun:25 earth

Mit diesem Befehl wird jede Verbindung zu Port 25 (SMTP) von earth auf den SMTP-Port von sun über den verschlüsselten Kanal weitergeleitet. Dies ist insbesondere für Benutzer von SMTP-Servern ohne SMTP-AUTH oder POP-before-SMTP-Funktionen von Nutzen. E-Mail kann so von jedem beliebigen Ort mit Netzanschluss zur Auslieferung durch den „home“-Mailserver übertragen werden. Analog können mit folgendem Befehl alle POP3-Anfragen (Port 110) an earth auf den POP3-Port von sun weitergeleitet werden:

ssh -L 110:sun:110 earth

Beide Befehle müssen Sie als Benutzer root ausführen, da die Verbindung zu privilegierten, lokalen Ports erfolgt. Bei bestehender SSH-Verbindung wird E-Mail wie gewohnt als normaler Benutzer verschickt und abgerufen. Der SMTP- und POP3-Host muss für diese Aufgabe auf localhost konfiguriert werden. Zusätzliche Informationen entnehmen Sie den Manualpages für die einzelnen Programme und den Dateien unter /usr/share/doc/packages/openssh.