SSH-Befehl: Optionen -l, -p und -i verwenden und Verbindungsfehler prüfen

Der SSH-Befehl ist der Befehl des OpenSSH-Clients, der sich in der Form ssh Konto@Serveradresse über eine verschlüsselte Verbindung mit einem entfernten Linux-Server verbindet und auf dem verbundenen Server Befehle ausführt. Wir haben ssh von einem AlmaLinux-9-Server zu einem Debian-12-Server ausgeführt und der Reihe nach alles geprüft, von der Host-Key-Prüfung bei der ersten Verbindung über die Optionen -l, -p und -i und das Ausführen entfernter Befehle bis zur Debug-Ausgabe von -v. Dabei zeigte sich, dass man mit ssh -G schon vorab und ohne Verbindung prüfen kann, wie Optionen tatsächlich angewendet werden.

Die Ausgabe unten ist genau das, was auf den beiden Servern ausgegeben wurde. Serveradresse und Konto, Hostname, Schlüsselpfad und Schlüssel-Fingerprint sowie die OpenSSL- und Kernel-Versionsnummern des verbindenden Servers wurden durch Beispielwerte ersetzt. Der verbindende AlmaLinux-Server nutzt das Konto root, der empfangende Debian-Server ein normales Konto.

1️⃣ Grundlegende Verwendung des SSH-Befehls

Um sich an einem entfernten Server anzumelden, schreibt man nach ssh den Kontonamen und die Serveradresse, verbunden mit @. Nach der Anmeldung wechselt die Eingabeaufforderung zu der des verbundenen Servers, und mit exit wird die Verbindung getrennt und man kehrt zum ursprünglichen Server zurück.

ssh user@192.0.2.10

Linux server2 6.1.0-53-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.187-1 (2026-09-07) x86_64
Last login: Wed Oct 28 20:27:41 2026 from 198.51.100.7
[user]:~$ whoami
user
[user]:~$ exit
exit
Connection to 192.0.2.10 closed.

Der verbundene Debian-Server zeigte bei der Anmeldung zusätzlich einige Zeilen Serverhinweis (motd) und eine Mail-Benachrichtigung; nur diese Zeilen wurden in der Ausgabe oben weggelassen.

Bei der ersten Verbindung zu einem Server wird vor der Anmeldung der Fingerprint des Host-Keys ausgegeben und gefragt, ob die Verbindung fortgesetzt werden soll. Nach Eingabe von yes wurde der Host-Key in ~/.ssh/known_hosts gespeichert, danach erschien das Ergebnis von whoami.

ssh user@192.0.2.10 whoami

The authenticity of host '192.0.2.10 (192.0.2.10)' can't be established.
ED25519 key fingerprint is SHA256:9fT2kL0qX8vN4cR1yB6sW3mZ7aH5dE0uJ2pG8oK1iVc.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.0.2.10' (ED25519) to the list of known hosts.
user

Nachdem der Schlüssel in known_hosts gespeichert war, erschien die Frage bei weiteren Verbindungen zum selben Server nicht mehr. Weicht der Fingerprint von dem Wert ab, den man vom Serveradministrator erhalten hat, gibt man no ein. Nach Eingabe von no endete ssh ohne Verbindung.

ssh user@192.0.2.10

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

Beim Beenden mit no wurde keine Datei known_hosts angelegt. Deshalb erscheint bei der nächsten Verbindung wieder dieselbe Frage.

2️⃣ Optionen des SSH-Befehls

ssh-Optionen stehen vor dem Verbindungsziel. Wurde nur ssh ausgeführt, erschien die Liste der verfügbaren Optionen als Verwendungshinweis.

ssh

usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address]
           [-c cipher_spec] [-D [bind_address:]port] [-E log_file]
           [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file]
           [-J destination] [-L address] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-P tag] [-p port] [-R address]
           [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
           destination [command [argument ...]]
       ssh [-Q query_option]

Gibt man eine Option an, die nicht im Verwendungshinweis steht, erscheint der Fehler [unknown option] zusammen mit demselben Verwendungshinweis.

-V gibt die installierte Version des OpenSSH-Clients aus. Unten steht das Ergebnis des verbindenden AlmaLinux-Servers; auf dem empfangenden Debian-12-Server erschien OpenSSH_9.2p1.

ssh -V

OpenSSH_9.9p1, OpenSSL 3.5.1 1 Jul 2025

-G verbindet sich nicht mit dem Server, sondern führt die angegebenen Optionen und die Konfigurationsdateien zusammen und gibt die Werte aus, die tatsächlich angewendet werden. Die vollständige Ausgabe hat 87 Zeilen, deshalb wählen wir mit grep nur die nötigen Zeilen aus.

ssh -G user@example.com | grep -E "^(user|hostname|port|identityfile|connecttimeout|stricthostkeychecking|serveraliveinterval) "

user user
hostname example.com
port 22
stricthostkeychecking ask
serveraliveinterval 0
identityfile ~/.ssh/id_rsa
identityfile ~/.ssh/id_ecdsa
identityfile ~/.ssh/id_ecdsa_sk
identityfile ~/.ssh/id_ed25519
identityfile ~/.ssh/id_ed25519_sk
identityfile ~/.ssh/id_xmss
identityfile ~/.ssh/id_dsa
connecttimeout none

Die sieben identityfile-Zeilen sind die Standard-Schlüsseldateien, nach denen ssh der Reihe nach sucht, wenn -i nicht angegeben ist. connecttimeout none bedeutet, dass keine eigene Wartezeit für den Verbindungsaufbau festgelegt ist.

3️⃣ Die Option ssh -l und Portweiterleitung mit -L

-l ist die Option, die den Kontonamen für die Verbindung angibt. ssh -l user 192.0.2.10 verband sich mit demselben Konto wie ssh user@192.0.2.10.

ssh -l user 192.0.2.10 whoami

user

Die Prüfung mit -G zeigte, dass das mit -l angegebene Konto im Eintrag user stand.

ssh -G -l admin example.com | grep -E "^(user|hostname|port) "

user admin
hostname example.com
port 22

Mit -G haben wir auch geprüft, was gilt, wenn man -l und Konto@Adresse zusammen angibt. Unter OpenSSH 9.9p1 wurde das mit -l angegebene admin angewendet.

ssh -G -l admin user@example.com | grep -E "^(user|hostname) "

user admin
hostname example.com

Das große -L hat einen ähnlichen Namen, ist aber eine Option für lokale Portweiterleitung, die nichts mit dem Konto zu tun hat. Sie leitet Verbindungen, die an einem Port des eigenen Servers ankommen, durch die SSH-Verbindung und verbindet sie mit einer Adresse und einem Port auf der Seite des entfernten Servers.

8080:localhost:80 bedeutet, dass Port 8080 des eigenen Servers mit Port 80 von localhost aus Sicht des entfernten Servers verbunden wird. Die Prüfung mit -G zeigte denselben Wert im Eintrag localforward.

ssh -G -L 8080:localhost:80 user@example.com | grep -E "^(hostname|localforward) "

hostname example.com
localforward 8080 [localhost]:80

Soll nur ein Tunnel offen bleiben, gibt man zusätzlich -N an, das die Verbindung ohne entfernten Befehl aufrechterhält.

4️⃣ SSH-Port und Schlüsseldatei angeben

Nimmt der SSH-Server Verbindungen auf einem anderen Port als 22 an, gibt man den Port mit -p an. -i gibt eine Datei mit privatem Schlüssel an, die keinen Standardnamen hat.

ssh -G -p 2222 -i ./mykey user@example.com | grep -E "^(user|hostname|port|identityfile) "

user user
hostname example.com
port 2222
identityfile ./mykey

Mit -i verschwanden die sieben Zeilen der Standard-Schlüsseldateien, und nur die angegebene Datei blieb übrig.

Schlüsseldateien erstellt man mit ssh-keygen. Wird bereits ein Schlüssel verwendet, gibt man mit -f einen neuen Dateinamen an. Unten steht das Ergebnis, als wir einen ed25519-Schlüssel mit dem neuen Namen mykey erstellt haben.

ssh-keygen -t ed25519 -f ./mykey -N "" -C "user@example.com"

Generating public/private ed25519 key pair.
Your identification has been saved in ./mykey
Your public key has been saved in ./mykey.pub
The key fingerprint is:
SHA256:XLbhLZHSNdMvUqhSIbzRNJi/zKKkNnWmy0mTeBoUfaY user@example.com
The key's randomart image is:
+--[ED25519 256]--+
|       ..=+.+o   |
|     .  =oo+.oo  |
|    . . +=B. . . |
|     . =o=o=. . .|
|    . E S++... . |
|   . .o.+ +.     |
|    o+== .       |
|    +*oo         |
|   ...+.         |
+----[SHA256]-----+

mykey ist der private Schlüssel und mykey.pub der öffentliche Schlüssel. Laut OpenSSH-Handbuch gehört der öffentliche Schlüssel in ~/.ssh/authorized_keys auf dem Server, mit dem man sich verbindet. Das erledigt ssh-copy-id, etwa mit [ssh-copy-id -i ./mykey.pub user@192.0.2.10].

Wer sich oft mit demselben Server verbindet, trägt in ~/.ssh/config einen Alias ein und gibt nur noch ssh und den Alias ein. Die Zeile Host ist der Alias, die Zeilen darunter sind die Werte, die bei einer Verbindung über diesen Alias gelten.

Host myserver
    HostName 192.0.2.10
    User user
    Port 2222
    IdentityFile ~/.ssh/mykey

Als wir diese Einstellungen in eine Datei ./config schrieben und mit -F einlasen, wurden Adresse, Konto, Port und Schlüsseldatei alle über einen einzigen Alias angewendet.

ssh -F ./config -G myserver | grep -E "^(user|hostname|port|identityfile) "

user user
hostname 192.0.2.10
port 2222
identityfile ~/.ssh/mykey

Optionen in der Befehlszeile haben Vorrang vor der Konfigurationsdatei. Als wir beim selben Alias zusätzlich -p 22 angaben, wechselte port auf 22.

ssh -F ./config -G -p 22 myserver | grep -E "^(hostname|port) "

hostname 192.0.2.10
port 22

hostname blieb beim Wert 192.0.2.10 aus der Konfigurationsdatei, nur port wechselte auf den in der Befehlszeile angegebenen Wert.

5️⃣ Entfernte Befehle mit SSH ausführen

Schreibt man nach dem Verbindungsziel einen Befehl, führt ssh ohne Anmeldebildschirm nur diesen Befehl aus und trennt dann die Verbindung. Bei mehreren Befehlen oder Shell-Zeichen wie dem Semikolon setzt man das Ganze in einfache Anführungszeichen.

ssh user@192.0.2.10 'whoami; hostname'

user
server2

Der Exit-Code des entfernten Befehls kam unverändert als Exit-Code von ssh zurück. In Skripten erkennt man an diesem Wert, ob der entfernte Befehl erfolgreich war.

ssh user@192.0.2.10 'exit 3'; echo $?

3

Wird ein Befehl auf diese Weise ausgeführt, wird kein Pseudoterminal zugewiesen. Das mit -T ausgeführte tty gab [not a tty] aus.

ssh -T user@192.0.2.10 tty

not a tty

Das ssh-Handbuch beschreibt -t als Option für bildschirmorientierte Programme auf dem entfernten Server. Mit -t erschien /dev/pts/0, und am Ende kam zusätzlich die Meldung, dass die Verbindung geschlossen wurde.

ssh -t user@192.0.2.10 tty

/dev/pts/0
Connection to 192.0.2.10 closed.

Mit zusätzlichem -q erschien diese Meldung nicht.

ssh -t -q user@192.0.2.10 tty

/dev/pts/0

-n leitet die Standardeingabe von ssh auf /dev/null um. Ohne -n gab das entfernte cat das über die Pipe übergebene hello unverändert aus.

echo hello | ssh user@192.0.2.10 cat

hello

echo hello | ssh -n user@192.0.2.10 cat

Mit -n beim selben Befehl kam hello nicht beim entfernten cat an, und es wurde nichts ausgegeben.

6️⃣ SSH-Verbindungsfehler und Debugging mit ssh -v

Klappt die Verbindung nicht, prüft man zuerst anhand der Fehlermeldung, an welcher Stelle sie hängen blieb. Wurde die Serveradresse nicht gefunden, erschien [Could not resolve hostname].

ssh user@nosuchhost.invalid

ssh: Could not resolve hostname nosuchhost.invalid: Name or service not known

Stimmt die Adresse, aber auf dem Port antwortet nichts, erscheint [Connection timed out]. Mit -o ConnectTimeout=5 endete der Versuch nach 5 Sekunden mit diesem Fehler.

ssh -o ConnectTimeout=5 -p 2222 user@192.0.2.10

ssh: connect to host 192.0.2.10 port 2222: Connection timed out

Als wir uns mit -o BatchMode=yes mit einem Server verbanden, der nicht in known_hosts stand, endete ssh ohne Nachfrage zum Host-Key mit [Host key verification failed.]. Damit die erste Verbindung in einem Skript nicht an der Frage hängen bleibt, nutzt man StrictHostKeyChecking=accept-new.

ssh -o BatchMode=yes user@192.0.2.10 true

Host key verification failed.

Laut ssh_config-Handbuch speichert accept-new nur den Host-Key von bisher unbekannten Servern ohne Nachfrage. Kommt ein anderer Schlüssel als der bereits gespeicherte, wird die Verbindung abgelehnt.

ssh -o StrictHostKeyChecking=accept-new user@192.0.2.10 whoami

Warning: Permanently added '192.0.2.10' (ED25519) to the list of known hosts.
user

Ist für das Konto kein Schlüssel hinterlegt, erscheint [Permission denied (publickey)]. Wiederholte Fehlanmeldungen können dazu führen, dass der Server die verbindende IP sperrt.

-v gibt den Verbindungsablauf als debug1-Zeilen aus. Die vollständige Ausgabe hat über 70 Zeilen, deshalb stehen unten nur die mit grep ausgewählten Zeilen der Verbindungs- und Authentifizierungsphase.

ssh -v -i ~/.ssh/id_ed25519 user@192.0.2.10 true 2>&1 | grep -E 'Connecting to|Connection established|remote software version|Server host key|is known and matches|can continue|Offering public key|Authenticated to|Exit status'

debug1: Connecting to 192.0.2.10 [192.0.2.10] port 22.
debug1: Connection established.
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u10
debug1: Server host key: ssh-ed25519 SHA256:9fT2kL0qX8vN4cR1yB6sW3mZ7aH5dE0uJ2pG8oK1iVc
debug1: Host '192.0.2.10' is known and matches the ED25519 host key.
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /root/.ssh/id_ed25519 ED25519 SHA256:4bN7qT1xW9cK3mR6yH0sD2fL8vZ5aJ1eP7uG3oX4iQs explicit
Authenticated to 192.0.2.10 ([192.0.2.10]:22) using "publickey".
debug1: Exit status 0

Die Zeile Connecting to ist der Verbindungsversuch, die Zeilen Server host key und is known and matches sind die Host-Key-Prüfung. In der Zeile Offering public key wurde der Schlüssel angeboten, in der Zeile Authenticated to war die Schlüssel-Authentifizierung abgeschlossen. Bleibt es bei der Authentifizierung hängen, prüft man zuerst, ob in der Zeile Offering public key die gewünschte Schlüsseldatei erscheint.

Mit zusätzlichem -C wechselte der Wert compression in der Zeile kex von none auf zlib@openssh.com.

ssh -v -C user@192.0.2.10 true 2>&1 | grep -E 'compression'

debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: Enabling compression at level 6.

-X ist die Option, die die Fenster von GUI-Programmen des entfernten Servers auf den eigenen Computer holt. Auf einem AlmaLinux-Server ohne Bildschirm ausgeführt, erschien eine debug1-Zeile, dass kein DISPLAY vorhanden ist.

ssh -v -X user@192.0.2.10 true 2>&1 | grep DISPLAY

debug1: X11 forwarding requested but DISPLAY not set

DISPLAY ist die Umgebungsvariable, die festlegt, wo GUI-Fenster angezeigt werden. Deshalb nutzt man -X, wenn man sich von einem Computer mit Desktop-Oberfläche aus verbindet.

🔲 SSH-Befehlssimulator

Im Simulator unten kann man sich mit ssh zu einem virtuellen Server verbinden und Optionen, entfernte Befehle und ssh -G selbst eingeben und ausprobieren.

🔢 FAQ & empfohlene Inhalte

🔗 Empfohlene Artikel

SSH-Schlüssel ssh-keygen: SSH-Schlüssel erzeugen, öffentlichen Schlüssel hinterlegen und ssh-copy-id nutzen Ein Artikel darüber, wie man mit ssh-keygen ein Schlüsselpaar für SSH-Verbindungen erstellt, den Fingerprint prüft und den öffentlichen Schlüssel mit ssh-copy-id in authorized_keys auf dem Server einträgt. Artikel lesen →

SSH SSH unter Linux: Definition und Grundeinstellungen Ein Artikel über die Entstehung von SSH als Ersatz für das unverschlüsselte Telnet, den Standardport 22, die Schlüssel-Authentifizierung und die Installation. Sicherheit OpenSSH-Sicherheitslücke CVE-2024-6387: vorübergehende Blockierung und Patch einspielen Ein Artikel darüber, wie die OpenSSH-Schwachstelle regreSSHion das Alarmsignal der Login-Wartezeit ausnutzt, und in welcher Reihenfolge wir erst eine vorläufige Sperre und dann den Patch eingespielt haben. Cloudways Per SFTP & SSH zu Cloudways verbinden: FileZilla einrichten, SSH-Schlüssel hinterlegen, IP-Whitelist Ein Artikel darüber, wie wir auf einem verwalteten Cloud-Server einen SSH-Schlüssel hinterlegt, die verbindende IP auf die Whitelist gesetzt und uns dann mit ssh und FileZilla verbunden haben.

ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt^{(bei Aktionsrabatten sinkt er ↓)}, steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.