SSH

“Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke.[1] Häufig wird es verwendet, um lokal eine entfernte Kommandozeile verfügbar zu machen, d. h., 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 z. B. zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Servers. Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP.” [0]

Damit dürfte SSH den meisten Administratoren schon ein Begriff sein, zumindest wenn eine Maschine mit einem Unix im Netzwerk vorhanden war. Falls noch Unklarheit besteht: Wenn gelentlich PuTTY geöffnet wird, wird sehr wahrscheinlich SSH eingesetzt. Die Vorteile von SSH sind schnell benannt, es bietet schnelle, stabile, sichere (authentifiziert und verschlüsselt) und bandbreitensparsame Verbindungen ohne grossen Aufwand dafür betreiben zu müssen. Die Beginne des Protokolls liegen in den 90ern als damit mehrere klassische Unix-Dienste abgelöst wurden und seitdem gibts es nur selten grössere Neuerungen [1]. Dennoch sind einige sehr nützliche Funktionen in SSH recht unbekannt und dem soll hiermit Abhilfe geschaffen werden. Im folgenden gehe ich dabei auf zuerst ein wenig auf die Grundlagen ein und dann auf die etwas weniger bekannten Eigenschaften.

Das erste Mal

Ein typische SSH-Session beginnt mit der Eingabe des ssh-Kommandos und der Zieladdresse, also etwa eines DNS-Namens oder einer IP-Addresse:

# ssh 192.168.178.23

Ohne weitere Angaben wird dabei wird als Loginname der des aktuellen Nutzers verwendet, bei PuTTY wird man beim einwaehlen nach dem Loginnamen gefragt. Beim ersten Mal wird die folgende Meldung bzw. das Aequivalent auf PuTTY erscheinen:

The authenticity of host '192.168.178.23 (192.168.178.23)' can't be established.
ED25519 key fingerprint is SHA256:cBmwx2ZFgoK0EBvWf2CDtiu5a9hoPMn4xH4LjEnPH64.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Es ist an diesem Punkt bereits eine Verbindung zum Zielrechner aufgebaut und der öffentliche Schlüssel des Hosts abgerufen worden. Ohne jetzt auf die Details von asymmetrischer Kryptographie einzugehen zu wollen, muss dieser Mechanismus kurz erlaeutert werden. Bei der Installation erzeugt der SSH-Server ein oder mehrere Schlüsselpaare, ein Paar besteht aus einem öffentlichen und privaten Teil, diese sind mathematisch verbunden. Daten die mit dem öffentlichen Teil verschlüsselt werden sind nur mit dem privaten Teil entschlüsselbar. Mit dem privaten Teil können Daten signiert werden, was mit dem öffentlichen Teil verifiziert werden kann, dass heisst, die gesendeten Daten wurden genau so von etwas versandt, was Zugriff auf den privaten Schlüssel hat (als typischerweise die Person oder Maschine die den Schlüssel besitzt). Ein aehnliches Prinzip kommt auch an vielen Stellen beim Einsatz von TLS zum Tragen, also z.B. beim normalen Besuch einer Website (wenn oben in der Addressleiste des Browsers ein Schlosssymbol ist). Aufgrund eines Systems von Vertrauensankern kann jedoch der Browser schon mehr oder weniger garantieren, dass die Gegenstelle auch die gewünschte ist, ohne den Nutzer nach einer Bestaetigung zu fragen. Dieses Verfahren kommt bei SSH normalerweise NICHT zum Einsatz, dazu aber spaeter mehr.

Mit einem yes oder der Eingabe des Fingerabdrucks des öffentlichen Schlüssel des Ziels kann nun bestaetigt werden, dass man diesen als authentisch annimmt, bei PuTTY gibt es dementsprechende Knöpfe. Anmerkung: Diese Meldung wird, der Erfahrung nach, IMMER und ohne Verifikation ignoriert. Dies ist in einem kontrollierten Netzwerk (zuhause oder vielleicht auch in einem Betrieb) vermutlich unbedenklich, nicht jedoch, wenn die Verbindung nicht der eigenen Kontrolle unterliegt. Ein Angreifer kann sich an dieser Stelle zwischen den Nutzer und das Ziel schalten! Diese Verifikation sollte also mit Bedacht und mittels eines zweiten (gesicherten) Kanals erfolgen. Wenn man zum Beispiel über eine virtuelle serielle Schnittstelle der Virtualisierungssoftware Zugriff auf die Maschine hat, so kann man mit ssh-keygen den Fingerprint ermitteln:

# ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:cBmwx2ZFgoK0EBvWf2CDtiu5a9hoPMn4xH4LjEnPH64 root@generic-debian11 (ED25519)

Dabei ist zu beachten, dass heutzutage mehrere Schlüsselpaare vorhanden sind und in /etc/ssh/ das passende ausgewaehlt werden muss, hier ist das ED25519, es könnte aber auch z.B. RSA oder ECDSA sein. Dies sind verschieden Algorithmen, was hier erstmal ignoriert wird.

Anschliessend sollte die Passwortabfrage erscheinen bzw. unter PuTTY die Frage nach dem Loginname:

user@192.168.178.23's password:

Nach der Eingabe des Passwortes landet man dann auf der eingestellten Loginshell.

SSH-Schlüssel

Das Passwort jedesmal einzugeben ist natürlich unnötige Arbeit und zudem problematisch, da dann schlussendlich doch schlechte und/oder schon mal benutzte Passwörter verwendet werden. Die Lösung dafür ist recht einfach und schon vorhanden: SSH-Schlüssel. Das klingt ja erstmal wie das Thema weiter oben und tatsaechlich ist es in etwa auch das Gleiche, nur dass wir dieses Mal das Schlüsselpaar für einen Nutzer verwenden. Dafür wird zuerst mal ein Schlüsselpaar erzeugt:

ssh-keygen
Enter file in which to save the key (/home/user/.ssh/id_rsa):

hier kann nun ein gewünschter Dateipfad angegeben werden (alternativ gleich in den Befehl mit der Option -f)

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Wie die Ausgabe beschreibt, kann hier eine Passphrase gesetzt werden, dies ist natürlich empfehlenswert. Waehrend einer laufenden Nutzersitzung, kann der Schlüssel einem SSH-Agenten hinzugefügt werden, so dass das Passwort nur einmal eingegeben werden muss.

Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa
The key fingerprint is:
SHA256:NY92co2ANzzBp6P82ILfZpmRALePZJxvU1Yxpt5UgGk user@host
The key's randomart image is:
+---[RSA 3072]----+
|         ..  o=o.|
|      . .o..Eo.o |
|       +.oO+...  |
|        BooOo=   |
|       +S*+=* o  |
|        +.B+     |
|       . = =     |
|      . o.B      |
|       ..+.      |
+----[SHA256]-----+

Der weitere Output zeigt dann noch den Erfolg der Operation an und stellt (aus irgendwelchen Gründen) den Fingerprint graphisch dar. Der Schlüssel kann dann auf die Zielmaschine kopiert werden:

ssh-copy-id -i $PFAD_ZUM_OEFFENTLICHEN_SCHLUESSEL $USER@$ZIEL

(wobei natürlich alle mit $ beginnenden Parameter durch die realen Werte ersetzt werden müssen) und dann benutzt werden mittels:

ssh -i $PFAD_ZUM_PRIVATEN_SCHLUESSEL $USER@$ZIEL

Da der Aufruf immer noch recht lang ist, kann man in einer Konfigurationsdatei ein paar Parameter setzen. Die Standardkonfigurationsdateien auf Unix-Systemen ist vermutlich ~/.ssh/config.

Host bla
    User $USER
    Hostname $ZIEL
    IdentityFile $PFAD_ZUM_PRIVATEN_SCHLUESSEL

Danach ist der Aufruf nur noch ssh bla. In PuTTY ist das Erstellen von Schlüssel und den Konfigurationseintraegen durch Klicken möglich.

Dateitransfer

Es gibt hier verschiedene Möglichkeiten:

1.scp Die Verwendung von scp ist relativ simpel und auch brauchbar für Skripte:

scp $LOKALE_DATEI $ZIELHOST:$ZIELORT_ODER_DATEI
scp $ZIELHOST:DATEI $LOKALE_ZIEL_DATEI

2.sftp Die Verwendung erinnert an die des Kommandos ftp und ist interaktiv, inklusive Verzeichniswechsel usw.

3.sshfs Eine FUSE-Implementierung von einem Dateisystem über SSH.

sshfs $ZIELHOST:$PFAD $LOKALES_VERZEICHNIS

haengt $PFAD des $ZIELHOST im $LOKALES_VERZEICHNIS ein.

Netzwerk

Ein paar sehr nützliche Features sind die Netzwerkoptionen von SSH, z.B.:

ssh -L 5555:bla:80 foo

transportiert alle Anfragen die an den lokalen Port 127.0.0.1:5555 gehen über SSH an den Host foo von wo aus sie über den normalen Netzwerkpfad (ohne SSH-Tunnel) dann auf Port 80 auf bla gehen. Sehr nützlich, wenn man etwa ein nur lokal erreichbares Webinterface besuchen möchte.

ssh -R 5555:localhost:6767 $ZIEL

Das Gegenstück, öffnet auf dem $ZIEL den Port 5555 und leitet in an den lokalen Port 6767 weiter.

ssh -J hop1,hop2 ziel

“Springt” per SSH über hop1 und hop2 zu ziel. Natürlich muss sich der Nutzer auf allen Systemen authentifizieren, aber benötigt keine Shell. Es können damit reine Gateways benutzt werden, die als “Eingangstor” in ein Netzwerk dienen.

ssh -D 6767 $ZIEL

Öffnet eine dynamische Port-Weiterleitung auf $Ziel. Kann auch von Browsern als SOCKS Proxy verwendet werden.

ssh $ZIEL -o "ProxyCommand=nc -X connect -x $PROXYHOST:$PROXYPORT %h %p"

Verbindet sich über den (HTTP-)Proxy $PROXYHOST auf Port $PROXYPORT zum $ZIEL

SSH-Zertifikate

Während die bisherigen Abschnitte SSH-Grundlagen und diverse Nutzungsmöglichkeiten behandelt haben, stellt sich dem interessierten Lesen oder auch dem fortgeschrittenen Nutzer schon die Frage nach der Skalierung solcher Setups. Die Authentizität einer Verbindung ist ja theoretisch durch die Schlüssel sicher gestellt, aber rein praktisch ist da die Problematik, dass man ja erstmal alle Host-Schlüssel in seiner ~/.ssh/known-hosts sammeln muss. Bei großen und dynamischen Umgebungen ein Sysiphos-Unterfangen, dass recht bald in Problemen resultiert. Das gleiche gilt natürlich für die Schlüssel der Nutzer. Da diese lokal für den sshd (den SSH-Daemon) verfügbar sein müssen, müssten potentiell ALLE Schlüssel ALLER Nutzer auf ALLE relevanten Maschinen kopiert und dort natürlich auch aktualisiert werden. Netzwerkdateisysteme sind natürlich ein Aus- oder Umweg, aber bergen das Risiko, dass bei einem Ausfall dieser Infrastruktur der Login überall sonst nicht mehr funktioniert. Naheliegenderweise gibt es dafür zumindest teilweise eine Lösung. In SSH gibt es nämlich auch Komponenten für eine Zertifikatsinfrastruktur. Diese ähnelt ein wenig der von TLS, ist jedoch deutlich rudimentärer und simpler. Dabei lassen sich SSH-Zertifizierungsschlüssel erstellen, die sowohl Host- als auch Nutzerschlüssel signieren können. Ein Nutzer muss dann nur noch dem Zertifizierungsschlüssel vertrauen um einen Host zu verifizieren und ein Host um einen Nutzer zu authentifizieren.

Der Zertifizierungsschlüssel besteht dabei, wie bisher bei den anderen Schlüsseln, auch wieder aus einem Schlüsselpaar:

# ssh-keygen -f ./ca_host_key -t ed25519
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./ca_host_key
Your public key has been saved in ./ca_host_key.pub
The key fingerprint is:
SHA256:3UmaB6K4wy/obEBhmeGYWZIKnlvF9emPY8xQgZmygPM user@host
The key's randomart image is:
+--[ED25519 256]--+
|.o* . ..+.       |
|=% . + +. o      |
|O.= o o .+. .    |
|.+ E o .oo * .   |
|. o . ..S.+ +    |
|.. . .  + o.     |
| . .+    * .     |
| .o .o  . .      |
| oo  ..          |
+----[SHA256]-----+

# cat ./ca_host_key.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICCdmjMLjw+WGI+Aj1FUHUCG16daqoyeet+GZWi1O/TS user@example.com

und damit können nun Host- oder Nutzerschlüssel signiert werden. Der Parameter -I enthält dabei die certificate_ID welche im Prinzip frei wählbar ist, aber für diesen Fall (der Host-Zertifikate) auf den eindeutigen Hostnamen gesetzt werden sollte.

# ssh-keygen -s ca_host_key -I testhost.local -h /etc/ssh/ssh_host_ecdsa_key.pub
Signed host key /etc/ssh/ssh_host_ecdsa_key-cert.pub: id "testhost.local" serial 0 valid forever

Dabei wird eine neue Datei host_ecdsa_key-cert.pub erstellt, die den unterschriebenen öffentlichen Schlüssel enthält, das sieht dann ungefähr so aus:

# cat ssh_host_ecdsa_key.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMuXZN6or69chS+ZT6++P37JeRC5km+cIbzXnfCos9hvJ9jUbB+Becozdcmhfhj6Udg6FfxwDJqc5WaKHA0uErY= root@example.com
# cat ssh_host_ecdsa_key-cert.pub
ecdsa-sha2-nistp256-cert-v01@openssh.com AAAAKGVjZHNhLXNoYTItbmlzdHAyNTYtY2VydC12MDFAb3BlbnNzaC5jb20AAAAgtZ2LJPOCioVR9tG19Zekk3x6qru6bYXCIlMXsKSc43QAAAAIbmlzdHAyNTYAAABBBMuXZN6or69chS+ZT6++P37JeRC5km+cIbzXnfCos9hvJ9jUbB+Becozdcmhfhj6Udg6FfxwDJqc5WaKHA0uErYAAAAAAAAAAAAAAAIAAAAOdGVzdGhvc3QubG9jYWwAAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAADMAAAALc3NoLWVkMjU1MTkAAAAgIJ2aMwuPD5YYj4CPUVQdQIbXp1qqjJ5634ZlaLU79NIAAABTAAAAC3NzaC1lZDI1NTE5AAAAQFgq6IqNBRjJrysFdBHHceU83AXF0Vg13uq17ZJXn2hk98H6rRnLCV8XvOtRd9o1bxtc8xQ7Poigw4wuRbMjigY= root@testhost.local

Nun fehlt nur noch ein Eintrag in die known_hosts Datei:

@cert-authority *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICCdmjMLjw+WGI+Aj1FUHUCG16daqoyeet+GZWi1O/TS

Damit werden alle Host-Schlüssel akzeptiert, die von einem Host mit dem Namensmuster *.example.com kommen und mit dem Zertifizierungsschlüssel signiert sind.

Dasselbe lässt sich prinzipiell gleichartig auf Nutzerschlüssel übertragen, auf ein Beispiel wird hier nun verzichtet um diese Vorstellung hier knapp zu halten. Jedoch gibt es den einen oder anderen Punkt, der erwähnt werden sollte: Da es sich hier nicht um TLS handelt und die ganze Struktur sehr viel schmaller ist, ist das Widerrufen von Schlüsseln anderst gelöst. Es gibt keine zentrale Stelle die Revocation Lists führt, die abgefragt werden können. Eine solche Liste muss sich lokal auf der Maschine befinden, also etwa mit Ansible, Puppet, Salt, Chef… plaziert und aktualisiert werden. Dies ist natürlich gerade für Nutzerschlüssel zu empfehlen. Zusätzlich sollte erwähnt werden, dass es durchaus die Möglichkeit gibt, das System zu erweitern und eigene Erweiterungen zu erstellen, beispielsweise mit der AuthorizedKeysCommand-Direktive in der sshd-Konfiguration die einem erlaubt ein eigenes Programm zu erstellen/verwenden um die Nutzer zu authentifizieren und damit wiederum eine Anbindung an Datenbanken oder Netzwerkdienste.

Rekapitulation

SSH als Protokoll und mit den gängigen FOSS-Implementierungen ist ein sehr mächtiges Werkzeug für den Umgang mit vernetzten Computern und leider, zumindest in meiner Wahrnehmung, unterschätzt. Nicht nur lassen sich enorm viele Aufgaben damit erledigen, es ist dabei auch flexibel, schnell und ressourcensparend. Etwas, was in einer Zeit der eher penetranten, langsamen Anwendungen als Abwechslung doch mal wieder angenehm ist. Die Netzwerk-Tricks erlauben das sinnvolle Arbeiten, auch in Umgebungen mit eher kreativen Firewall-Regeln und mit ein wenig Einrichtung ist der Zugriff auf entfernte Rechner kaum noch von dem auf den eigenen, lokalen zu unterscheiden (ich würde zu eine Shell-Prompt raten, die dies farblich hervorhebt, es kann leicht zu Verwirrungen kommen). Mit ein bisschen zusätzlicher Arbeit kann das System auch gut skaliert werden. Und das schönste: Es ist schon da! Die Chancen sind gut, dass es bereits auf jedem Linux-System im Netzwerk vorhanden ist (und auf dem meisten aktiv) und auf jedem anderen Unix-System ist es sehr sicher verfügbar. Sogar auf den Windows-Systemen ist relativ einfach zu installeren (Microsoft bietet einfach auch OpenSSH als Dienst zur Installation an). Es lohnt sich hier auf jeden Fall mal ein wenig Zeit in das Setup zu investieren um die Arbeit ein wenig angenehmer und flüssiger zu gestalten und ich hoffe, dass dieser Artikel ein paar Anstösse in diese Richtung gegeben hat.

Danksagung

An dieser Stelle möchte ich kurz Dank ausrichten an das Entwicklungsteam von OpenSSH die das Protokoll und die wohl populärste Implementierung warten und stetig weiterentwickeln und etwas gebaut haben, was mir und vielen anderen den sinnvollen Umgang mit vernetzten Computern ermöglichen. Zusätzlich vielen Leuten im Internet die mir mit vielen Beispielen, Anleitungen und Erklärungen geholfen haben an diesen Punkt zu kommen, was sonst so nicht ohne weiteres möglich gewesen wäre.

Quellen

• https://de.wikipedia.org/wiki/Secure_Shell
• https://www.openssh.com/history.html
• https://www.openssh.com/
• https://wiki.archlinux.org/title/OpenSSH
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-ssh-configuration
• https://wiki.debian.org/SSH

Lorenz Kästle

Consultant

---

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Read more from Lorenz and meet the Team