SSH Client

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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

Abgerufen von „http://wiki.ixheim.de/index.php?title=SSH_Client&oldid=68517“