SSH Client

Einloggen

Beim ersten Verbindungsaufbau zu einem Server kennt SSH den Zielrechner noch nicht und fragt nach einer Bestätigung. Das ist ein Sicherheitsmechanismus gegen Man-in-the-Middle-Angriffe.

xinux@orville:~$ ssh kit@server

The authenticity of host 'server (192.168.16.216)' can't be established.
ED25519 key fingerprint is SHA256:GOyaDogwsT3hrFwp3lEelZqiTQ6l3ORN+aSnzwo5Wdg.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'server' (ED25519) to the list of known hosts.
kit@server's password: *****
...
kit@server.it216.int:~$

Was passiert hier?

• SSH zeigt den Fingerprint des Server-Schlüssels – im Idealfall vergleicht man diesen

 mit dem vom Administrator bekanntgegebenen Wert.

• Nach der Bestätigung wird der Schlüssel in ~/.ssh/known_hosts gespeichert.
• Ab dem zweiten Login erscheint diese Meldung nicht mehr – SSH erkennt den Server wieder.

Hinweis: Erscheint die Warnung bei einem bekannten Server plötzlich erneut (z.B. nach einer Neuinstallation), unbedingt beim Administrator nachfragen bevor man yes eingibt.

Ausloggen

Mit exit wird die SSH-Verbindung sauber beendet. Alternativ funktioniert auch die Tastenkombination Strg+D.

kit@server.it216.int:~$ exit

logout
Connection to server closed.

User Keys generieren

Statt eines Passworts kann man sich mit einem Schlüsselpaar authentifizieren. Das besteht aus zwei Dateien:

• id_ed25519 – der private Schlüssel. Dieser verlässt den eigenen Rechner niemals.
• id_ed25519.pub – der öffentliche Schlüssel. Dieser wird auf den Server übertragen.

ED25519 ist ein modernes, sicheres Verfahren und die empfohlene Wahl. Die Passphrase schützt den privaten Schlüssel zusätzlich – sie ist zwar optional, aber dringend empfohlen.

xinux@orville:~$ ssh-keygen

 Generating public/private ed25519 key pair.
 Enter file in which to save the key (/home/xinux/.ssh/id_ed25519): 
 Enter passphrase for "/home/xinux/.ssh/id_ed25519" (empty for no passphrase): 
 Enter same passphrase again: 
 Your identification has been saved in /home/xinux/.ssh/id_ed25519
 Your public key has been saved in /home/xinux/.ssh/id_ed25519.pub
 The key fingerprint is:
 SHA256:GgiLput73H6NERA15OBg/pTRYYMnHzEz4dgxRgxQcb0 xinux@orville
 The key's randomart image is:
 +--[ED25519 256]--+
 |   +oB@^=        |
 |  o o+%=O.       |
 |  .. ==+. .      |
 | . oo. o E       |
 |... ... S        |
 |o      +         |
 |. . . . +        |
 | . o . o .       |
 |ooo ...          |
 +----[SHA256]-----+

Was passiert hier?

• Die Eingabetaste bei der Datei-Frage übernimmt den Standardpfad – das ist in der Regel richtig.
• Das Randomart-Bild ist eine visuelle Darstellung des Fingerprints – rein zur

 Wiedererkennung, kein Sicherheitsmerkmal.

Öffentlichen Schlüssel übertragen

Mit ssh-copy-id wird der öffentliche Schlüssel automatisch in die richtige Datei auf dem Server (~/.ssh/authorized_keys) eingetragen. Dafür ist einmalig das Passwort des Ziel-Benutzers nötig.

xinux@orville:~$ ssh-copy-id kit@server

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/xinux/.ssh/id_ed25519.pub"
kit@server's password: ******

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'kit@server'"
and check to make sure that only the key(s) you wanted were added.

Ab jetzt wird beim Login nicht mehr das Passwort des Benutzers abgefragt, sondern die Passphrase des privaten Schlüssels:

xinux@orville:~$ ssh kit@server

Enter passphrase for key '/home/xinux/.ssh/id_ed25519': ******

Hinweis: Das ist ein wichtiger Unterschied – die Passphrase verlässt den eigenen Rechner nicht. Sie entschlüsselt nur lokal den privaten Schlüssel.

SSH-Agent (Passphrase nur einmal eingeben)

Wer einen SSH-Schlüssel mit Passphrase verwendet, muss diese normalerweise bei jeder Verbindung neu eingeben. Der ssh-agent merkt sich die entschlüsselten Schlüssel für die Dauer der Sitzung.

Mit grafischer Oberfläche (GNOME, KDE, etc.)

Desktop-Umgebungen starten automatisch einen ssh-agent. Es reicht ein einmaliges:

xinux@orville:~$ ssh-add ~/.ssh/id_ed25519

Enter passphrase for /home/xinux/.ssh/id_ed25519: ******
Identity added: /home/xinux/.ssh/id_ed25519 (xinux@orville)

Ab jetzt funktioniert ssh kit@server ohne Passphrase-Eingabe – bis zum nächsten Login.

Ohne grafische Oberfläche (Server, reines Terminal)

Hier startet kein Agent automatisch. Folgenden Block an das Ende der ~/.bashrc anhängen:

#Existiert die Datei und ist ein »Socket«?
if [ ! -S ~/.ssh/ssh_auth_sock ]
then
  #eval wertet die Rückgabe nochmal aus
  eval $(ssh-agent) > /dev/null 2>&1
  #Ist das Verzeichnis vorhanden? Wenn nicht, wird es angelegt
  test -d ~/.ssh || mkdir ~/.ssh
  #Wir verlinken diesen Socket auf einen festen Pfad
  #Dieser lebt bis zum Neustart
  ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock
fi
export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock

Danach den Schlüssel einmalig zum Agent hinzufügen:

xinux@orville:~$ ssh-add ~/.ssh/id_ed25519

Enter passphrase for /home/xinux/.ssh/id_ed25519: ******
Identity added: /home/xinux/.ssh/id_ed25519 (xinux@orville)

Hinweis: Bei jedem Neustart muss ssh-add einmal erneut ausgeführt werden. Die Passphrase selbst wird dabei nicht gespeichert – das ist gewollt.

Remote Befehle ausführen

SSH kann Befehle direkt auf dem Server ausführen, ohne eine interaktive Shell zu öffnen. Der Befehl wird einfach nach der Adresse angehängt.

xinux@orville:~$ ssh kit@server cat /etc/hostname

server.it216.int

xinux@orville:~$ ssh kit@server whoami

kit

Die Ausgabe erscheint lokal – die Verbindung wird danach automatisch getrennt. Das ist nützlich für Skripte oder wenn man schnell einen einzelnen Wert abfragen möchte.

Hinweis: Bei Befehlen mit Leerzeichen oder Sonderzeichen empfehlen sich Anführungszeichen:

xinux@orville:~$ ssh kit@server "ls -la /etc/ssh"

Optionen

SSH kennt viele Optionen. Die wichtigsten für den Alltag:

-p (Port)

Standardmäßig verwendet SSH den Port 22. Viele Server laufen aber auf einem anderen Port – dann kommt -p zum Einsatz:

xinux@orville:~$ ssh -p 2222 kit@server

kit@server.it216.int:~$

-i (Identität / Schlüssel)

Standardmäßig verwendet SSH den Schlüssel in ~/.ssh/id_ed25519. Hat man mehrere Schlüssel, kann man mit -i einen bestimmten angeben:

xinux@orville:~$ ssh -i ~/.ssh/id_ed25519_work kit@server

kit@server.it216.int:~$

-l (Login-Name)

Statt user@host kann man den Benutzernamen auch mit -l angeben. Beide Schreibweisen sind gleichwertig:

xinux@orville:~$ ssh -l kit server

kit@server.it216.int:~$

-v (Verbose / Fehlersuche)

Wenn eine Verbindung nicht klappt, hilft -v weiter. SSH gibt dann detailliert aus was es versucht – nützlich um zu sehen warum z.B. ein Schlüssel nicht akzeptiert wird:

xinux@orville:~$ ssh -v kit@server

OpenSSH_9.9p2 Debian-3, OpenSSL 3.4.1 11 Feb 2025
debug1: Reading configuration data /home/xinux/.ssh/config
debug1: Connecting to server [192.168.16.216] port 22.
debug1: Connection established.
debug1: identity file /home/xinux/.ssh/id_ed25519 type 3
debug1: Authenticating to server:22 as 'kit'
...
kit@server.it216.int:~$

Tipp: Mit -vv oder -vvv bekommt man noch mehr Details – meist reicht aber -v.

ProxyJump (-J): Über einen Zwischenserver verbinden

Manchmal ist ein Zielserver nicht direkt aus dem Internet erreichbar – zum Beispiel weil er in einem privaten Netzwerk hinter einer Firewall sitzt. In diesem Fall kann man einen Jump Host (auch Bastion Host genannt) als Zwischenstation nutzen.

Der Parameter -J weist SSH an, zuerst eine Verbindung zum Jump Host aufzubauen und von dort aus automatisch weiter zum Zielserver zu verbinden. Dabei läuft der vollständige Verbindungsaufbau (alle drei Phasen) zweimal ab – einmal zum Jump Host, einmal zum Zielserver.

Analogie

Stell dir vor, du willst in ein Bürogebäude, das keinen öffentlichen Eingang hat. Du gehst zuerst zur Rezeption eines Nachbargebäudes (Jump Host), die dich dann intern ins Zielbüro weiterleitet.

Verwendung

Einmalig auf der Kommandozeile:

ssh -J user@jumphost user@zielserver

Mehrere Hops hintereinander sind ebenfalls möglich:

ssh -J user@hop1,user@hop2 user@zielserver

Hinweis: Der private Schlüssel bleibt dabei immer auf dem eigenen Rechner. SSH überträgt ihn nicht auf den Jump Host – die Authentifizierung am Zielserver findet direkt zwischen dem eigenen Client und dem Zielserver statt.

Siehe auch: SSH-Config – Jump Hosts und andere Optionen dauerhaft konfigurieren

SSH-Konfigurationsdatei (~/.ssh/config)

Wer regelmäßig SSH nutzt, tippt schnell immer wieder dieselben langen Befehle. Die Datei ~/.ssh/config erlaubt es, diese Optionen dauerhaft zu hinterlegen – pro Server individuell.

Die Datei wird nicht automatisch erstellt. Falls sie noch nicht existiert:

mkdir -p ~/.ssh && touch ~/.ssh/config && chmod 600 ~/.ssh/config

Aufbau

Jeder Eintrag beginnt mit Host gefolgt von einem frei wählbaren Alias. Darunter stehen die Optionen eingerückt:

Host <Alias>
    Option1 Wert
    Option2 Wert

Beispiel 1: Alias für einen Server

Statt ssh -p 2222 admin@192.168.1.100 jedes Mal einzutippen:

Host webserver
    HostName 192.168.1.100
    User admin
    Port 2222

Danach reicht:

ssh webserver

Beispiel 2: Bestimmten Schlüssel verwenden (IdentityFile)

Nützlich wenn man mehrere Schlüsselpaare hat – z. B. einen für die Arbeit, einen privaten:

Host arbeitsserver
    HostName server.firma.de
    User meinname
    IdentityFile ~/.ssh/id_ed25519_arbeit

Beispiel 3: Jump Host (ProxyJump) dauerhaft hinterlegen

Ergänzend zum -J-Parameter aus dem vorherigen Abschnitt:

Host jumphost
    HostName bastion.firma.de
    User admin

Host zielserver
    HostName 10.0.0.5
    User user
    ProxyJump jumphost

Danach reicht:

ssh zielserver

SSH verbindet automatisch zuerst zu jumphost, dann weiter zu zielserver.

Beispiel 4: ForwardAgent

Mit ForwardAgent yes kann der SSH-Agent des eigenen Rechners auf dem Zwischenserver genutzt werden – zum Beispiel um von einem Jump Host aus weiter auf andere Server zuzugreifen, ohne den privaten Schlüssel auf den Jump Host kopieren zu müssen.

Host jumphost
    HostName bastion.firma.de
    User admin
    ForwardAgent yes

Sicherheitshinweis: ForwardAgent yes nur bei Servern setzen, denen man vollständig vertraut. Ein kompromittierter Server könnte den weitergeleiteten Agenten missbrauchen, solange die SSH-Sitzung aktiv ist.

Alles zusammen: Vollständiges Beispiel

Host jumphost
    HostName bastion.firma.de
    User admin
    IdentityFile ~/.ssh/id_ed25519_arbeit
    ForwardAgent yes

Host prod
    HostName 10.0.0.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_arbeit
    ProxyJump jumphost

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Der Block Host * gilt für alle Verbindungen und ist nützlich für globale Standardwerte – hier z. B. damit die Verbindung bei Inaktivität nicht abbricht.

Hinweis: Berechtigungen der Datei müssen stimmen, sonst ignoriert SSH sie:

chmod 600 ~/.ssh/config