HOWTO zu SSH (Secure Shell)
(C) 2007-2026 T.Birnthaler/H.Gottschalk <howtos(at)ostc.de>
OSTC Open Source Training and Consulting GmbH
www.ostc.de
$Id: ssh-HOWTO.txt,v 1.63 2026/06/09 17:17:47 tsbirn Exp $
Dieses Dokument beschreibt Grundlagen und Einsatz von SSH (Secure Shell)
unter UNIX/Linux (sicheres telnet, rcp, rsh, rlogin, ftp + "VPN für Arme").
1) Einführung
2) Übersicht Konfigurations- und Schlüsseldateien
3) Prinzipielle Arten von Verschlüsselung
4) SSH installieren, aktivieren und testen
4.1) SSH-Daemon "sshd"
4.2) SSH-Protokoll
4.3) SSH-Client "ssh"
5) Einsatz von SSH
5.1) Anmelden per SSH-Client
5.1.1) Wichtige Optionen von "ssh"
5.2) Server/Host-Authentifizierung (Fingerprint)
5.3) Kommando per SSH remote ausführen
5.4) Dateien per SSH zwischen Rechnern kopieren
5.4.1) Wichtige Optionen von "scp"
5.5) X Window-Protokoll tunneln
5.6) Schlüsselbasierte Client-Authentifizierung einrichten (kein Passwort)
5.6.1) Wichtige Optionen von "ssh-keygen"
5.6.2) Grafik zum Ablauf einer Client-Authentifizierung
5.7) Privaten Schlüssel mit Passphrase sichern
5.8) SSH-Agent zum Schlüssel verwalten
5.9) Bei SSH-Anmeldung Kommando ausführen/Optionen setzen
6) Port-Forwarding (Tunneling von Protokollen)
6.1) Verbindung CLIENT (lokal) --> SERVER (remote) öffnen
6.2) Verbindung SERVER (remote) --> CLIENT (lokal) öffnen
6.3) Beispiele
6.3.1) HTTP-Protokoll lokal von Port 8080 auf remote SERVER Port 80 tunneln
6.3.2) POP3-Protokoll lokal von Port 5000 auf remote SERVER Port 110 tunneln
6.3.3) Telnet-Verbindung lokal von Port 5000 auf remote SERVER Port 23 aufbauen
6.3.4) Von Port 3306 lokal auf Port 3306 remote tunneln (MySQL-Server)
6.3.5) Portweiterleitung über Zwischenrechner
6.3.6) Putty-Sitzung über Zwischen-Rechner
7) Übersicht
7.1) Kommandos
7.2) Server-Konfigurations-Dateien
7.3) Client-Konfigurations-Dateien
7.4) Login-Shell Konfigurations-Dateien
8) Tipps
9) Links
SSH (Secure Shell) stellt mit "ssh", "scp" und "sftp" (Clients) + "sshd"
(Server) eine gesicherte (verschlüsselte) Kommunikation über unsichere Netze
zur Verfügung, und bildet einen sicheren Ersatz für die Standard-UNIX-Tools
"telnet", "ftp", "rlogin", "rcp", "rsh", "rcmd", ... (Remote Login, Remote
Kommando-Ausführung, Dateitransfer) mit folgenden Eigenschaften:
* Leistungsfähige Authentifizierung von Client UND Server
* Sichere Verschlüsselung der übertragenen Daten (und Anmeldung)
* Integritätssicherung (Verifizierung) der übertragenen Daten
(verhindert "Man-in-the-middle" Attacken)
SSH sollte daher aus Sicherheitsgründen alle oben aufgezählten veralteten
Standard-UNIX/LINUX-Remote-Kommandos ersetzen. Auf allen LINUX/UNIX-Versionen
ist SSH inzwischen Standard, auf telnet/ftp wird von vornherein verzichtet:
Weiterhin unterstützt SSH den Schutz von X11-Verbindungen (X Window System)
und die Weiterleitung ("Port-Forwarding") von beliebigen TCP-Verbindungen
über einen kryptografisch gesicherten Kanal und bietet somit VPN-Funktionalität
("VPN für Arme"). Kurzer Funktionsumfang:
* Login auf Remote-Host
* Ausführen von Kommandos auf Remote-Host (interaktiv / nicht-interaktiv)
* Kopieren von Dateien zwischen Hosts
* Port-Forwarding/Tunneling (VPN)
* Komprimierung der Daten während Transfer
Eigenschaften:
* Automatische und transparente Verschlüsselung der gesamten Kommunikation
* Sechs Verfahren der Client-Authentifizierung gegenüber dem Server möglich
* RSA-basierte Authentifizierung (IP-, Routing-, DNS-Spoofing nicht möglich)
* Systemweite + benutzerbezogene Konfigurations-Dateien
* Übertragen von Binärdaten (+ Komprimierung) möglich
* Arbeitet gut mit anderen Tools zusammen
(z.B. "rsync", "X", "cvs", "svn", "unison").
* Port 22 (SSH-Port) für Kommunikation verwendet
Bekannte Implementierungen:
* OpenSSH: Kommt ohne patentierte Algorithmen aus (--> www.openssh.com)
* Windows-Client: Putty (--> www.chiark.greenend.org.uk/~sgtatham/putty)
Es gibt zentrale (rechnerspezifische) Konfigurations-Dateien im Verz.
"/etc/ssh" und benutzerspezifische im Verz. "~/.ssh" jedes Benutzers. Wird eine
Einstellung in beiden Konfigurations-Dateien getroffen, dann überschreibt die
benutzerspezifische Einstellung die zentrale. Existiert die benutzerspezifische
Konfigurations-Datei nicht, dann gilt die zentrale vollständig.
Vorrang SSH-Client-Konfiguration (von oben nach unten absteigend):
+---------------------+-------------------------------------------------------+
| -o OPT=VAL ... | Kommandozeilen-Option (mehrfach angebbar) |
| -F FILE | Konf.datei (zentrale + benutzerspez. ignoriert) |
| ~/.ssh/config | Benutzerspez. Konfiguration (Std falls -f FILE fehlt) |
| /etc/ssh/ssh_config | Zentrale Konfiguration (Std falls -f FILE fehlt) |
+---------------------+-------------------------------------------------------+
Vorrang SSH-Server-Konfiguration (von oben nach unten absteigend):
+----------------------+--------------------------------------------------+
| -o OPT=VAL ... | Kommandozeilen-Option (mehrfach angebbar) |
| -f FILE | Zentrale Konf.datei explizit angeben |
| /etc/ssh/sshd_config | Zentrale Konfiguration (Std falls -f FILE fehlt) |
+----------------------+--------------------------------------------------+
Zur Verschlüsselung der Kommunikation gibt es mind. ein Schlüsselpaar pro
Rechner und mind. eines pro Benutzer. Da es mehrere Verschlüsselungsverfahren
gibt (RSA/DSA/ECDSA/ED25519 --> veraltet/modern, unsicher/sicher,
patentbehaftet/patentfrei), können auch mehrere Schlüsselpaare existieren,
von denen pro Authentifizierungsvorgang eines ausgewählt wird.
* Schlüsselpaare für Rechner werden bei der Installation des Rechners
bzw. des SSH-Paketes AUTOMATISCH angelegt (per "ssh-keygen").
* Schlüsselpaare für Benutzer müssen MANUELL pro Benutzer per Kommando
"ssh-keygen" angelegt werden.
Ein zusammengehörendes Schlüsselpaar wird in 2 Dateien abgelegt:
XXX # Privater Teil (bleibt auf Rechner, nur für Eigentümer lesbar)
XXX.pub # Öffentlicher Teil ("pub"=public, darf beliebig verteilt werden)
Konfigurations-Dateien der beiden SSH-Kommunikations-Partner:
Lokal (Client) Remote (Server)
+--------------------------+ +----------------------------------+
| Client: ssh, scp, sftp |<===========>| Server-Daemon: sshd |
| Putty, ... |Kommunikation| Firewall mit offenem SSH-Port 22 |
+--------------------------+ +----------------------------------+
| /etc/ssh/ssh_config | | /etc/ssh/moduli |
| ~/.ssh/config |Konfiguration| /etc/ssh/sshd_config |
| (ACHTUNG: OHNE d=daemon) | | (ACHTUNG: MIT d=daemon) |
+--------------------------+ +----------------------------------+
| ~/.ssh/id_rsa (P2) |============>| ~/.ssh/authorized_keys |
| ~/.ssh/id_rsa.pub | Client- | |
| ~/.ssh/id_dsa | Authentifiz.| |
| ~/.ssh/id_dsa.pub | | |
| ~/.ssh/id_ecdsa | | |
| ~/.ssh/id_ecdsa.pub | | |
| ~/.ssh/id_ed25519 | | |
| ~/.ssh/id_ed25519.pub | | |
| ~/.ssh/identity (P1) | | |
| ~/.ssh/identity.pub | | |
+--------------------------+ +----------------------------------+
| /etc/ssh/ssh_known_hosts |<============| /etc/ssh/ssh_host_rsa_key (P2) |
| ~/.ssh/known_hosts | Server- | /etc/ssh/ssh_host_rsa_key.pub |
| | Authentifiz.| /etc/ssh/ssh_host_dsa_key |
| | | /etc/ssh/ssh_host_dsa_key.pub |
| | | /etc/ssh/ssh_host_ecdsa_key |
| | | /etc/ssh/ssh_host_ecdsa_key.pub |
| | | /etc/ssh/ssh_host_ed25519_key |
| | | /etc/ssh/ssh_host_ed25519_key.pub|
| | | /etc/ssh/ssh_host_key (P1) |
| | | /etc/ssh/ssh_host_key.pub |
+--------------------------+ +----------------------------------+
| |============>| /etc/ssh/sshrc |
| |Login-Shell | ~/.ssh/rc |
| |Konfiguration| ~/.ssh/environment |
+--------------------------+ +----------------------------------+
| |============>| /etc/motd |
| | Login- | /etc/nologin |
| | verhalten | ~/.hushlogin |
+--------------------------+ +----------------------------------+
| |============>| /etc/hosts.equiv |
| | Host-based | /etc/shosts.equiv |
| | Login | ~/.rhosts |
| | | ~/.shosts |
+--------------------------+ +----------------------------------+
| |============>| /etc/hosts.allow |
| | TCP-Wrapper | /etc/hosts.deny |
+--------------------------+ +----------------------------------+
HINWEISE:
* SERVER-Konfigurations-Datei "sshd_config" (MIT d=daemon!) und
CLIENT-Konfigurations-Datei "ssh_config" (OHNE d=daemon!) NICHT verwechseln!
* Besitzverhältnisse und Zugriffsrechte sämtlicher Konfigurations-Dateien
und ihrer Verz.pfade müssen einige Bedingungen erfüllen, damit SSH eine
schlüsselbasierte Anmeldung erlaubt --> 8) Tipps
a) SYMMETRISCH: Gleicher Schlüssel zum Ver- und zum Entschlüsseln:
- Schlüsselaustausch schwierig (muss über geheimen Kanal erfolgen)
- Schlüssel muss geheim gehalten werden
+ Schlüssel kurz (128-256 Bit)
+ Schnell (Schlüsselgenerierung und Verschlüsselung)
b) ASYMMETRISCH: Ein Schlüsselpaar bestehend aus einem öffentlichen
(public key) und einem privaten (private key) Teil:
+ Schlüsselaustausch einfach (den public key darf JEDER kennen!)
+ Nur privater Schlüssel muss geheim gehalten werden
- Schlüssel lang (1024-16384 Bit)
- Langsam (Schlüsselgenerierung und Verschlüsselung)
c) HYBRID: Verbindung der Vorteile beider Verfahren.
Beim Verbindungsaufbau wird über eine asymmetrische Verschlüsselung ein
symmetrischer "Sitzungsschlüssel" vereinbart und darüber die eigentliche
Kommunikation durchgeführt.
SSH verwendet hybride Verschlüsselung: Eines der asymmetrischen Verfahren RSA
(Rivest, Shamir, Adelman), DSA (Digital Signature Algorithm), ECDSA (Elliptic
Curve Digital Signature Algorithm) oder ED25519 (Edwards Kurve) wird zur
Authentifizierung gegenüber der Gegenstelle verwendet. Danach tauscht SSH einen
symmetrischen Schlüssel aus, der die Sitzungsdaten verschlüsselt. Dieser
Schlüssel wird in bestimmten Zeitabständen (etwa alle 60 Minuten) erneuert.
Grund für den ständigen Wechsel des Sitzungsschlüssels: Eine aufgezeichnete
SSH-Sitzung könnte, falls der zugehörige private Schlüssel später irgendwie
bekannt wird, nachträglich entschlüsselt werden. Aufgrund des Wechsels und
"Vergessen" des alten Sitzungsschlüssels ist eine nachträgliche Entschlüsselung
der Sitzung nicht oder nur für kleine Abschnitte der Sitzung möglich
("Replay"-Angriff).
Prüfen, ob SSH installiert ist:
rpm -qa | grep "ssh" # --> z.B. "openssh-3.0p1-33 + openssh-askpass-3.0p1-33"
dpkg -l | grep "ssh" # --> z.B. "openssh-server"
Auf dem eigenen Rechner muss der SSH-Client "ssh" (oder "Putty") installiert
sein, auf dem Remote-Rechner muss ein SSH-Server "sshd" laufen (lauscht auf
Port 22). Evtl. Firewalls müssen Verbindungen auf Port 22 erlauben bzw.
durchlassen.
SSH-Daemon auf Remote-Rechner (Server) aktivieren:
/etc/init.d/sshd start # Temporär (SysV)
initctl sshd start # Temporär (Upstart)
systemd start sshd # Temporär (Systemd)
service sshd start # Temporär (Allgemein)
rcsshd start # Temporär (Suse)
chkconfig -a sshd # Permanent (-a=add)
SSH-Daemon auf Remote-Rechner (Server) deaktivieren:
/etc/init.d/sshd stop # Temporär (SysV)
initctl sshd stop # Temporär (Upstart)
systemctl stop sshd # Temporär (Systemd)
service sshd stop # Temporär (Allgemein)
rcsshd stop # Temporär (Suse)
chkconfig -d sshd # Permanent (-d=delete)
Überprüfen ob SSH-Daemon "sshd" aktiv ist:
/etc/init.d/ssh status # (SysV)
initctl sshd status # (Upstart)
systemctl status sshd # (Systemd)
service sshd status # (Allgemein)
rcsshd status # (Suse)
ps -auxwww | grep "sshd" # w=wide
Bei Änderungen an der SSH-Server-Konfigurations-Datei "/etc/ssh/sshd_config"
MUSS der SSH-Server NEU gestartet und SOLLTEN vorhandene Verbindungen NEU
aufgebaut werden (bleiben sonst mit den alten Einstellungen bestehen):
/etc/init.d/sshd restart # (SysV)
initctl sshd restart # (Upstart)
systemctl restart sshd # (Systemd)
service sshd restart # (Allgemein)
rcsshd restart # (Suse)
Alternativ kann auch nur die Konfiguration des SSH-Servers neu geladen werden:
/etc/init.d/sshd reload # (SysV)
initctl sshd reload # (Upstart)
systemctl reload sshd # (Systemd)
service sshd reload # (Allgemein)
rcsshd reload # (Suse)
Zum Testen des SSH-Daemons das Debugging einschalten (verschiedene Stufen),
er startet dann nicht als Daemon und nur 1x. Seine Fehlermeldungen werden auf
dem Fehlerkanal "stderr" ausgegeben:
sshd -d # Debug-Meldungen
sshd -dd # Mehr Debug-Meldungen
sshd -ddd # Noch mehr Debug-Meldungen (mit sshd_config-Parametern!)
Neben BENUTZER-SPEZIFISCHEN Schlüsseln gibt es auch RECHNER-SPEZIFISCHE
Schlüssel, diese werden in der Regel bei der System-Installation erzeugt. Durch
sie kann bestimmt werden, zu welchen Rechnern überhaupt eine SSH-Verbindung
erlaubt ist:
+-----------------------------------+-------------------------------------+
| Schlüssel-Datei | Protokoll-Version |
+-----------------------------------+-------------------------------------+
| /etc/ssh/ssh_host_key_rsa | P2 (privater RSA2-Schlüssel) |
| /etc/ssh/ssh_host_key_rsa.pub | P2 (öffentlicher RSA2-Schlüssel) |
| /etc/ssh/ssh_host_key_dsa | P2 (privater DSA-Schlüssel) |
| /etc/ssh/ssh_host_key_dsa.pub | P2 (öffentlicher DSA-Schlüssel) |
| /etc/ssh/ssh_host_key_ecdsa | P2 (privater ECDSA-Schlüssel) |
| /etc/ssh/ssh_host_key_ecdsa.pub | P2 (öffentlicher ECDSA-Schlüssel) |
| /etc/ssh/ssh_host_key_ed25519 | P2 (privater ED25519-Schlüssel) |
| /etc/ssh/ssh_host_key_ed25519.pub | P2 (öffentlicher ED25519-Schlüssel) |
+-----------------------------------+-------------------------------------+
| /etc/ssh/ssh_host_key | P1 (privater RSA1-Schlüssel) |
| /etc/ssh/ssh_host_key.pub | P1 (öffentlicher RSA1-Schlüssel) |
+-----------------------------------+-------------------------------------+
Sämtliche Schlüssel sollten unbedingt an einer vertraulichen Stelle GESICHERT
(z.B. ausgedruckt und in einem verschlossenen Umschlag hinterlegt) werden,
damit sie bei einem Systemfehler oder einer Neuinstallation durch Eintippen
wieder hergestellt werden können!
Es gibt 2 Protokoll-Versionen von SSH:
+---------+--------------------------+-------------------+
| Version | Verschlüsselung | Protokoll-Version |
+---------+--------------------------+-------------------+
| SSHv1 | RSA | P1 |
| SSHv2 | RSA, DSA, ECDSA, ED25519 | P2 |
+---------+--------------------------+-------------------+
Sie unterscheiden sich in der Aushandlung des symmetrischen Schlüssels
(sicherheitstechnische und patentrechtliche Gründe) und im Protokollablauf
(Kommunikation zwischen Client und Server). ACHTUNG: Die Version "SSHv1" sollte
aus Sicherheitsgründen nicht mehr verwendet werden:
1) Protokoll Version 1 (SSH1)
* Client baut Verbindung zum Server auf Port 22 auf
* Verständigung auf Protokollversion und sonstige Kommunikations-Parameter
* Transfer: Langlebiger Host-Key + kurzleb. Session-Key (1x pro h geändert)
* 256-Bit-Session-Key erzeugt, verschlüsselt und an Server übermittelt
* Server entschlüsselt Session-Key
* Session-Key wird für symmetrischen Verschlüsselung benutzt
2) Protokoll Version 2 (SSH2)
* Client baut Verbindung zum Server auf Port 22 auf
* Verständigung auf Protokollversion und sonstige Kommunikations-Parameter
* Transfer: Langlebiger Host-Key
* Diffie-Hellman Schlüssel-Vereinbarung --> geheimer Session-Key
* Session-Key wird für symmetrischen Verschlüsselung benutzt
Welche Protokolle ein SSH-Server spricht, ist seiner Antwort auf den Befehl
"telnet HOST 22" zu entnehmen (Protokoll-Version + Implementierung-Version z.B.
"SSH-2.0-OpenSSH_6.9"):
"SSH-1.5-OpenSSH_..." # --> Nur SSHv1
"SSH-1.99-OpenSSH_..." # --> SSHv1 und SSHv2
"SSH-2.0-OpenSSH_..." # --> Nur SSHv2
Die wichtigsten Server-Einstellungen in "sshd_config":
+-----------------------+--------------------------------------------------+
| Port 22 | Standard-Port (für interne Anwendung änderbar) |
| Protocol 2 | Probier-Reihenfolge Protokoll-Vers. (nicht 2,1!) |
| ListenAddress 0.0.0.0 | STD: Auf allen NW-Karten lauschen |
| ForwardX11 yes | X11-Forwarding aktiv |
+-----------------------+--------------------------------------------------+
Welche Protokoll-Version für die SSH-Verbindung verwendet wird (ein Server kann
beide anbieten), legt der Client beim Verbindungsaufbau fest:
ssh -1 ... # Protokoll Version 1
ssh -2 ... # Protokoll Version 2
Testen ob ein HOST eine SSH-Verbindung prinzipiell annimmt:
telnet HOST 22 # Antwort z.B. "SSH-1.99-OpenSSH_3.0p1"
# oder "SSH-2.0-OpenSSH_5.1"
Während einer SSH-Anmeldung an einem Remote-Rechner können Kommandos an den
SSH-Client abgesetzt werden, die durch das Sonderzeichen "~" eingeleitet werden
müssen. Diese "Escape-Sequenzen" dienen zur interaktiven Bedienung der Sitzung
und sind nur am Zeilenanfang eingebbar (ansonsten hat "~" normale Bedeutung):
+-----+--------------------------------------------------------------------+
| ~. | Verbindung abbrechen (alle darüber gemultiplexten Sitzungen) |
| ~B | BREAK an Remote-Rechner senden |
| ~C | Kommandozeile öffnen (SSH-Optionen angeben) |
| ~R | Neuen Sitzungsschlüssel anfordern (nur SSH2) |
| ~^Z | Anhalten (^Z=Strg-Z, mit "fg" weiterlaufen lassen) |
| ~# | Weitergeleitete Verbindungen auflisten (forwarded) |
| ~& | In Hintergrund stellen (auf Verb.Ende warten, Tunnel noch genutzt) |
| ~? | Hilfe zu Escape-Sequenzen anzeigen (diese Liste) |
| ~~ | Tilde-Zeichen selbst eingeben (2x tippen notwendig) |
+-----+--------------------------------------------------------------------+
Die wichtigsten Client-Einstellungen in "ssh_config":
+-------------------------+--------------------------------------------------+
| Port 22 | Standard-Port (für interne Anwendung änderbar) |
| Protocol 2 | Probier-Reihenfolge Protokoll-Vers. (nicht 2,1!) |
| ForwardX11 yes | X11-Forwarding aktiv |
| TCPKeepAlive yes | TCP Keep alive Meldungen senden |
| ServerAliveInterval 300 | SSH-Keep alive Meldungen alle 5 Minuten senden |
| EscapeChar ~ | Escape-Zeichen |
+-------------------------+--------------------------------------------------+
Per SSH-Client an Remote-Rechner anmelden (aktueller oder anderer Benutzer):
ssh localhost # Auf eigenem Rechner als akt. Benutzer
ssh 172.23.19.56 # Als akt. Benutzer auf Remote-Rechner
ssh -l tom 172.23.10.56 # Als anderer Benutzer "tom" (-l=login)
ssh tom@172.23.10.56 # Als anderer Benutzer "tom" (@=at)
ssh -p 2222 tom@172.23.10.26 # Auf anderem Port (-p=port)
Test des Verbindungs-Aufbaus (-v=verbose, auch mehrfach -vv, -vvv, ...):
ssh -v tom@172.23.10.56 # Meldungen zum Verbindungsaufbau
ssh -vv tom@172.23.10.56 # Mehr Meldungen zum Verbindungsaufbau
ssh -vvv tom@172.23.10.56 # Noch mehr Meldungen zum Verbindungsaufbau
Beim ERSTEN Verbindungsaufbau zu einem neuen Server (hier mit IP 192.168.0.1),
dessen Host-Schlüssel auf der Client-Seite daher unbekannt ist (nicht in
"~/.ssh/known_hosts" enthalten), erscheint folgende Meldung:
The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
RSA key fingerprint is 8a:58:19:a1:27:95:2b:e4:e2:3e:5f:41:c7:58:2a:d2.
Are you sure you want to continue connecting (yes/no)?
Durch Eintippen von "yes" (3 Buchstaben GENAU SO und mit <RETURN> abschließen)
wird der Host-Schlüssel akzeptiert und in "~/.ssh/known_hosts" eingetragen
sowie die Verbindung zum (bisher unbekannten) Server aufgebaut.
Zur VERIFIZIERUNG des Host-Schlüssels (und damit des Servers) sollte der
angezeigte Fingerprint mit dem Fingerprint des lokal auf dem Server
gespeicherten HOST-Schlüssels (über einen anderen Kanal, z.B. am Telefon
vorlesen oder per Ausdruck) verglichen werden. Die Fingerprint-Anzeige
des lokalen Host-Schlüssels erfolgt per:
ssh-keygen -l /etc/ssh/ssh_host_rsa_key.pub # P2 RSA
ssh-keygen -l /etc/ssh/ssh_host_dsa_key.pub # P2 DSA
ssh-keygen -l /etc/ssh/ssh_host_ecdsa_key.pub # P2 ECDSA
ssh-keygen -l /etc/ssh/ssh_host_ed25519_key.pub # P2 ED25519
ssh-keygen -l /etc/ssh/ssh_host_key.pub # P1 RSA
+----------------------+---------------------------------------------------+
| Option | Bedeutung |
+----------------------+---------------------------------------------------+
| -l USER | Login-Name [login] |
| -p PORT | SSH-Port (STD: 22) [port] |
| -i IDENTITY_FILE | Schlüsseldatei (STD: "~/.ssh/id_...") [identity] |
+----------------------+---------------------------------------------------+
| -o OPTION=VALUE ... | SSH-Option setzen (mehrfach erlaubt) [option] |
| -F CONFIG_FILE | Konfig.-Datei (STD: "~/.ssh/config") [File] |
| -e CHAR | Escape-Zeichen festlegen (STD: "~") [escape] |
+----------------------+---------------------------------------------------+
| -L LPORT:RHOST:RPORT | Lokalen LPORT auf remote RPORT von RHOST abbilden |
| -R RPORT:RHOST:LPORT | Remote RPORT von RHOST auf lokalen LPORT abbilden |
+----------------------+---------------------------------------------------+
| -C | Komprimierung der übertragenen Daten [Compress] |
| -4 | Nur IPv4 nutzen [ipv4] |
| -6 | Nur IPv6 nutzen [ipv6] |
+----------------------+---------------------------------------------------+
| -X | X11-Forwarding aktivieren [X11] |
| -x | X11-Forwarding deaktivieren [x11] |
| -Y | Trusted X11-Forwarding aktivieren [Y11] |
+----------------------+---------------------------------------------------+
| -q | Weniger Meldungen (Fortschrittanzeige) [quiet] |
| -v | Ablaufmeldungen [verbose] |
| -vv | Mehr Ablaufmeldungen |
| -vvv | Noch mehr Ablaufmeldungen |
+----------------------+---------------------------------------------------+
Wird die ERSTE VERBINDUNG zu einem Server/Host mit "yes" (3 Buchstaben!)
akzeptiert, dann wird in der lokalen Datei "~/.ssh/known_hosts" des aktuellen
Benutzers der rechnerspezifische ÖFFENTLICHE Schlüssel dieses Servers/Hosts
eingetragen (mit Zuordnung zu seiner IP):
+-----------------------------------+-----------------------------+
| Schlüsseldatei | Protokoll-Version |
+-----------------------------------+-----------------------------+
| /etc/ssh/ssh_host_rsa_key.pub | P2 (öffentlicher Schlüssel) |
| /etc/ssh/ssh_host_dsa_key.pub | P2 (öffentlicher Schlüssel) |
| /etc/ssh/ssh_host_ecdsa_key.pub | P2 (öffentlicher Schlüssel) |
| /etc/ssh/ssh_host_ed25519_key.pub | P2 (öffentlicher Schlüssel) |
| /etc/ssh/ssh_host_key.pub | P1 (öffentlicher Schlüssel) |
+-----------------------------------+-----------------------------+
Das ist unsinnig für Rechner, die ständig ihre IP-Adressen ändern. In der
Konfigurations-Datei "/etc/ssh/ssh_config" bzw. "~/.ssh/config" kann daher das
Verhalten eingestellt werden:
StrictHostKeyChecking Ask # "Yes" oder "No" möglich (neben "Ask")
Die Einstellung "Ask" ist bequem, aber auch GEFÄHRLICH, da der Host-Schlüssel
KOMPROMITTIERT sein könnte ("man-in-the-middle"-Angriff), indem ein anderer
Rechner so tut, als wäre er der gewünschte Zielrechner. Daher sollte er über
einen anderen Kanal transportiert werden (z.B. USB-Stick, Diskette, Ausdruck).
Zumindest sollte der in obiger Meldung angezeigte FINGERPRINT (16 Byte langer
Hashwert der Form "8a:58:19:a1:27:95:2b:e4:e2:3e:5f:41:c7:58:2a:d2" aus dem
übertragenen Host-Schlüssel mit dem Fingerprint des Original-Schlüssels auf dem
Host-Rechner verglichen werden (z.B. am Telefon vorlesen oder von einem
Ausdruck ablesen).
ssh-keygen -l -f KEYFILE # -l=list, -f=file (STD: sha256-Hash)
ssh-keygen -E sha256 -l -f KEYFILE # -l=list, -f=file (sha256-Hash)
ssh-keygen -E md5 -l -f KEYFILE # -l=list, -f=file (md5-Hash)
Der FINGERPRINT wird von "ssh-keygen" bei Erstellung eines neuen Schlüssels
bzw. von SSH bei der ERSTEN Verbindungsaufnahme angezeigt (md5- bzw.
sha256-Hash):
2048 MD5:da:0a:08:7a:ee:31:40:20:b6:f6:82:df:f3:94:78:84 tsbirn@exeter (RSA)
2048 SHA256:LQu4Q/uhWpU/hrjztIJNdLQu+jnHdqKTmQmxsExaP6M tsbirn@exeter (RSA)
Eine ebenfalls verfügbare Darstellung als ASCII-Grafik eignet sich zur groben
optischen Kontrolle, ob man mit dem richtigen Host-Rechner verbunden ist. Sie
wird bei Angabe von "-v" (verbose) zum Fingerprint mit ausgegeben:
ssh-keygen -l -v -f KEYFILE # -v=verbose
ssh-keygen -E sha256 -l -v -f KEYFILE # -v=verbose
ssh-keygen -E md5 -l -v -f KEYFILE # -v=verbose
+--[ RSA 2048]----+
|o. |
|+ . |
| + |
|+ . . |
|+. .E . S |
|.+.o o + |
|. * = = . |
| o o * . |
| .o o |
+-----------------+
Ein Kommando an eine SSH-Verbindung übergeben und remote ausführen lassen:
ssh USER@HOST "CMD" # Kommando "CMD"
ssh USER@HOST "ls -l" # Kommando "ls -l"
ACHTUNG: Aufpassen bei Metazeichen (resultierenden Befehl ansehen mit "echo"):
+---------------------------+--------------------------+
| Befehl | "*" ausgewertet... |
+---------------------------+--------------------------+
| ssh USER@HOST ls -l * | ...auf lokalem Rechner |
+---------------------------+--------------------------+
| ssh USER@HOST ls -l \* | ...auf Remote-Rechner |
| ssh USER@HOST ls -l "*" | ...auf Remote-Rechner |
| ssh USER@HOST ls -l '*' | ...auf Remote-Rechner |
| ssh USER@HOST "ls -l *" | ...auf Remote-Rechner |
| ssh USER@HOST 'ls -l *' | ...auf Remote-Rechner |
+---------------------------+--------------------------+
| ssh USER@HOST ls -l "'*'" | ...weder/noch |
| ssh USER@HOST ls -l '"*"' | ...weder/noch |
| ssh USER@HOST ls -l "\\*" | ...weder/noch |
| ssh USER@HOST ls -l '\*' | ...weder/noch |
+---------------------------+--------------------------+
* ACHTUNG: ":" nicht vergessen, sonst erzeugt man eine LOKALE Kopie!
* Standard-Benutzer ist der aktuell angemeldete Benutzer
* Standard-Verzeichnisse:
+ Lokal: Aktuelles Verz. "." des aktuell angemeldeten Benutzers
+ Remote: Heimat-Verz. "~" des Anmeldebenutzers "USER"
* Passwort wird verlangt, falls kein Schlüsselaustausch stattgefunden hat
* Die Struktur des Filesystems auf dem Remote-Rechner muss bekannt sein,
damit man dort mit korrekten Pfaden zugreifen kann
* Zugriffsrechte auf Remote-Rechner müssen Zugriff gemäß Anmeldung erlauben
scp FILE HOST: # Remote-Ziel: Heimat-Verz. des aktuellen Users
scp FILE HOST:/tmp # Remote-Ziel: Verz. "/tmp"
scp FILE USER@HOST: # Remote-Ziel: Heimat-Verz. von USER ("-l" unmöglich!)
scp HOST:FILE . # Remote-Quelle: "FILE" im Heimat-Verz.
# Lokales Ziel: Akt. Verz. (Angabe von "." notwendig!)
scp HOST:FILE ~ # Remote-Quelle: "FILE" im Heimat-Verz.
# Lokales Ziel: Home-Verz. (Angabe von "~" notwendig!)
scp HOST:FILE /tmp # Remote-Quelle: "FILE" im Heimat-Verz.
# Lokales Ziel: Verz. "/tmp"
Man kann sogar zwischen zwei Remote-Rechnern kopieren:
scp USER1@HOST1:FILE USER2@HOST2:FILE2 # 2x Schlüsseltausch bzw. anmelden!
Der Transfer erfolgt standardmäßig über den LOKALEN Rechner als
ZWISCHENSTATION. Um den Transfer DIREKT zwischen den beiden Remote-Rechnern
durchzuführen, die Option "-R" (Remote) angeben. "scp" wird dann auf dem
Quellhost ausgeführt und nimmt von dort aus Verbindung mit dem Zielhost auf
(daher muss sich der Quellhost gegenüber dem Zielhost authentifizieren können).
+---------------------+--------------------------------------------------+
| Option | Bedeutung |
+---------------------+--------------------------------------------------+
| -P NR | Port NR statt 22 (GROSS!) [Port] |
| -i IDENTITY_FILE | Schlüsseldatei (STD: "~/.ssh/id_...") [identity] |
+---------------------+--------------------------------------------------+
| -o OPTION=VALUE ... | SSH-Option setzen (mehrfach erlaubt) [option] |
| -F CONFIG_FILE | Konfig.-Datei (STD: "~/.ssh/config") [File] |
+---------------------+--------------------------------------------------+
| -r | Rekursiv (alle Verz. + ihre Inhalte) [recursive] |
| -p | Zugriffsrechte + -zeiten erhalten [preserve] |
| -l LIMIT | Max. Bandbreite in Kbit/s [limit] |
+---------------------+--------------------------------------------------+
| -C | Komprimierung der übertragenen Daten [Compress] |
| -4 | Nur IPv4 nutzen [ipv4] |
| -6 | Nur IPv6 nutzen [ipv6] |
+---------------------+--------------------------------------------------+
| -q | Weniger Meldungen (Fortschrittanzeige) [quiet] |
| -v | Ablaufmeldungen [verbose] |
| -vv | Mehr Ablaufmeldungen |
| -vvv | Noch mehr Ablaufmeldungen |
+---------------------+--------------------------------------------------+
Die Angabe eines Zielbenutzers per Option "-l USER" (login) ist bei "scp" nicht
möglich. Der Zielbenutzer muss über die Syntax "USER@HOST" angegeben werden,
falls er vom lokalen Benutzer abweicht.
X Window-Protokoll vom Server zum Client durchtunneln
(Variable "DISPLAY" anschließend gesetzt):
ssh -X 172.23.10.56 # Erlauben (-X=enable)
ssh -x 172.23.10.56 # Verbieten (-x=disable)
ssh -Y 172.23.10.56 # Erlauben (-Y=enable)
Um X Window-Anwendungen remote auf dem Remote-Server zu starten und dann lokal
auf dem Client anzuzeigen, müssen verschiedene Bedingungen erfüllt sein:
* Remote-Server muss das unterstützen
(Eintrag "X11Forwarding" in "/etc/ssh/sshd_config", Std. meist "no").
* Lokaler Client muss das unterstützen (Var. DISPLAY muss gesetzt sein,
Eintrag "ForwardX11" bzw. "ForwardX11Trusted" in "/etc/ssh/ssh_config"
bzw. "~/.ssh/config", Std. meist "no"; oder Schalter "-X" (enable)
bzw. "-Y" (enable trusted) beim ssh-Aufruf mitgeben).
* Evtl. "xhost +HOST" auf lokalem Rechner (macht eigentlich "xauth")
BISHER: Bei Verbindungsaufnahme authentifiziert sich der Server gegenüber dem
Client durch seinen Host-Schlüssel und der Client authentifiziert sich
gegenüber dem Host durch Eingabe seines Passworts (diese Kommunikation wird
bereits verschlüsselt).
NEU: Die Authentifizierung des Clients soll OHNE Passworteingabe erfolgen,
sondern über einen Client-Schlüssel erfolgen.
Dazu muss per "ssh-keygen" für den sich anmeldenden Benutzer ein Schlüssel
generiert werden, dessen öffentlicher Teil auf dem Remote-Rechner (Server) in
die Datei "~/.ssh/authorized_keys" einzutragen ist (in seinem Heimatverz.).
Ein Benutzer hat zunächst kein Verz. "~/.ssh/" in seinem Heimat-Verz. Dieses
wird erzeugt, wenn für ihn ein Schlüsselpaar generiert wird (ohne PASSPHRASE
= leere Passphrase, -t=type, "*.pub" = öffentlicher Schlüssel):
+-----------------------+-------------------------------------------+
| Aufruf | Erzeugte Schlüsseldateien |
+-----------------------+-------------------------------------------+
| ssh-keygen -t rsa | ~/.ssh/id_rsa + ~/.ssh/id_rsa.pub |
| ssh-keygen -t dsa | ~/.ssh/id_dsa + ~/.ssh/id_dsa.pub |
| ssh-keygen -t ecdsa | ~/.ssh/id_ecdsa + ~/.ssh/id_ecdsa.pub |
| ssh-keygen -t ed25519 | ~/.ssh/id_ed25519 + ~/.ssh/id_ed25519.pub |
+-----------------------+-------------------------------------------+
| ssh-keygen -t rsa1 | ~/.ssh/identity + ~/.ssh/identity.pub |
| ssh-keygen | (analog) |
+-----------------------+-------------------------------------------+
Man erhält einen FINGERPRINT (16-stellige Hexadezimalzahl) des generierten
Schlüssels ausgegeben, den man z.B. auf seiner Web-Seite veröffentlicht oder
auf seiner Visitenkarte einträgt. Andere können damit verifizierten, ob der
Verbindungspartner wirklich der richtige ist.
2048 MD5:da:0a:08:7a:ee:31:40:20:b6:f6:82:df:f3:94:78:84 tsbirn@exeter (RSA)
2048 SHA256:LQu4Q/uhWpU/hrjztIJNdLQu+jnHdqKTmQmxsExaP6M tsbirn@exeter (RSA)
Der Fingerprint kann optisch durch eine ASCII-Grafik (ASCII art) dargestellt
werden, die sich zur groben Kontrolle eignet, ob man mit dem richtigen Rechner
verbunden ist (wird bei Angabe von "-v" (verbose) mit ausgegeben):
+--[ RSA 2048]----+
|o. |
|+ . |
| + |
|+ . . |
|+. .E . S |
|.+.o o + |
|. * = = . |
| o o * . |
| .o o |
+-----------------+
Nachträglich Fingerprint bzw. ASCII-Grafik zu einem Schlüssel anzeigen:
ssh-keygen -l -f KEYFILE # -l=list, -f=file (STD: sha256-Hash)
ssh-keygen -l -v -f KEYFILE # -v=verbose --> ASCII-Grafik zusätzlich!
ssh-keygen -l -E md5 -f KEYFILE # -E=hash (md5-Hash)
ssh-keygen -l -E sha256 -f KEYFILE # -E=hash (sha256-Hash)
Der Weg, auf dem der öffentliche Schlüsselteil anschließend zum jeweiligen
Remote-Rechner transportiert wird, darf nicht manipulierbar sein (z.B. per
Hand, Telefon, Diskette, USB-Stick, NICHT per eMail!). Eine weitere (unsichere)
Möglichkeiten wäre Transport über die Zwischenablage in einer SSH-Anmeldung.
cat ~/.ssh/id_rsa.pub # Öffentlichen Client Schlüssel anzeig.
ssh USER@HOST # Remote-Anmeldung per Passwort
mkdir ~/.ssh # Unterverz. für SSH-Keys anlegen
vi ~/.ssh/authorized_keys # Datei mit Client-Schlüsseln anzeigen
... angezeigten Schlüssel per Maus als oberste Zeile einfügen ...
:wq # Datei speichern (w=write, q=quit)
exit # Remote-Abmeldung
ssh USER@HOST # Anmeldung per Schlüsselaustausch
Oder mit "scp":
scp ~/.ssh/id_rsa.pub USER@HOST:/tmp # Anmeldung per Passwort
ssh USER@HOST # Anmeldung per Passwort
mkdir ~/.ssh # Unterverz. für SSH-Keys anlegen
cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys # Öffentl. Client-Key anhängen
exit # Remote-Abmeldung
ssh USER@HOST # Anmeldung per Schlüsselaustausch
Oder alles auf einen Schlag:
ssh USER@HOST "mkdir ~/.ssh; # Anmeldung per Passwort
cat >> ~/.ssh/authorized_keys" < ~/.ssh/id_rsa.pub
Oder per Skript:
ssh-copy-id USER@HOST # ~/.ssh/id_rsa.pub (Std)
ssh-copy-id -i USER@HOST # ~/.ssh/identity.pub
ssh-copy-id -i KEYFILE USER@HOST # KEYFILE
ACHTUNG: Kein Anfangs/Endstück des öffentlichen Schlüssels weglassen,
er muss aus EINER Zeile bestehen (keine Zeilenumbrüche).
Nun sollte ein Anmeldung per "ssh" OHNE Passworteingabe möglich sein! Nach der
Verifizierung der schlüsselbasierten Anmeldung kann die Erlaubnis zur
passwortbasierte Anmeldung an einen SSH-Server aus Sicherheitsgründen
abgeschalten werden:
PasswordAuthentication No
+-------------+--------------------------------------------------------+
| Option | Bedeutung |
+-------------+--------------------------------------------------------+
| -A | ALLE Keytypen generieren [All] |
| -t TYPE | Keytyp generieren (dsa, ecdsa, ed25519, rsa) [type] |
| -b BITS | Anzahl zu generierender Bits [bits] |
| -f FILE | Key-Dateiname (statt Standardname) [file] |
+-------------+--------------------------------------------------------+
| -E HASH_ALG | Hash-Alg. für Fingerprint (STD: sha256, md5) [Emit] |
| -l | Fingerprint von Pubkey-Datei anzeigen [list] |
+-------------+--------------------------------------------------------+
| -p | Passphrase ändern [passphrase] |
+-------------+--------------------------------------------------------+
| -q | Weniger Meldungen [quiet] |
| -v | Ablaufmeldungen [verbose] |
| -vv | Mehr Ablaufmeldungen |
| -vvv | Noch mehr Ablaufmeldungen |
+-------------+--------------------------------------------------------+
Letzten Endes hat folgender Austausch des öffentlichen Schlüsselteils der
jeweiligen Gegenstelle "über Kreuz" stattgefunden:
USER1 USER2
ANMELDUNG
ssh USER2@HOST =============================> sshd
+-----------+ SSH-Protokoll +---------------+
| Client | | Server (HOST) |
| (local) | | (remote) |
+-----+-----+ +-------+-------+
| |
(MANUELL erzeugt: ssh-keygen -t rsa) (bei Installation AUTOMAT. erzeugt)
/home/USER1/.ssh/id_rsa.pub /etc/ssh/ssh_host_rsa_key.pub
| |
| (AUTOMATISCH bei 1. SSH-Verb. + "yes") |
+-----|----------------------------------------+
| |
| +----------------------------------------+
| (MANUELL pro Benutzer) |
v v
/home/USER1/.ssh/known_hosts # oder /home/USER2/.ssh/authorized_keys
/etc/ssh/ssh_known_hosts (/etc/ssh/authorized_keys NICHT!)
TIPP: Sammeln der bei allen Benutzern (inkl. "root") vorh. "~/.ssh/known_hosts"
in zentraler Datei "ssh_known_hosts" (doppelte Einträge nur 1x):
cat /home/*/.ssh/known_hosts > /tmp/uuu # Umlenken + sudo nicht glz.
sudo cp /root/known_hosts /tmp/rrr #
cat /tmp/uuu /tmp/rrr | sort | uniq > /tmp/hhh # Umlenken + sudo nicht glz.
sudo cp /tmp/hhh /etc/ssh/ssh_known_hosts #
HINWEIS: Ob das eine gute Idee ist, sei dahingestellt! Die zentralen Schlüssel
in "/etc/ssh/ssh_known_hosts" sollten VERIFIZIERT sein. Benutzerspezifische
Schlüssel in "~/.ssh/known_hosts" könnten durch Eingabe von "yes" bei der
ERSTEN Verbindungsaufnahme akzeptiert sein und sind dann NICHT verifiziert.
NACH dem Austausch der öffentlichen Schlüssel wird häufig in
"/etc/ssh/sshd_config" die Authentifizierung via Passwort deaktiviert
(Std = vordefinierte Defaultwerte, Sec = sichere Werte):
+------------------------+---+---+-------------------------------------------+
| Konfigurationsvariable |Std|Sec| Bedeutung |
+------------------------+---+---+-------------------------------------------+
| RSAAuthentication |yes|yes| Reine RSA-Authentifiz. erlaubt (nur P1) |
| PubkeyAuthentication |yes|yes| Public-Key Authentifiz. erlaubt (nur P2) |
| PasswordAuthentication |yes|no | SSH fragt selber nach dem Passwort |
| UsePAM |no |no | Sonst wird Passwort von PAM verlangt |
+------------------------+---+---+-------------------------------------------+
Sicherheitstechnisch wichtig Einstellungen in "/etc/ssh/sshd_config":
+------------------------+---+---+-------------------------------------------+
| Konfigurationsvariable |Std|Sec| Bedeutung |
+------------------------+---+---+-------------------------------------------+
| PermitRootLogin |yes| no| Direkte root-SSH-Anmeldung nicht möglich |
| PermitEmptyPasswords | no| no| Leere Passworte verboten |
| IgnoreRhosts |yes|yes| "~/.rhosts" "~/.shosts" nicht benutzen |
| IgnoreUserKnownHosts | no|yes| Userspez. "~/.ssh/known_hosts" verboten, |
| | | | Systemspez. "/etc/ssh/known_hosts" nötig |
+------------------------+---+---+-------------------------------------------+
Weitere sinnvolle Einstellungen in "/etc/ssh/sshd_config":
+------------------------+---+---+-------------------------------------------+
| Konfigurationsvariable |Std|Sec| Bedeutung |
+------------------------+---+---+-------------------------------------------+
| StrictModes |yes|yes| Zugriffsrechte auf Dateien prüfen |
| X11Forwarding | no| no| X11-Protokoll tunneln |
| X11DisplayOffset | 10| 10| X11-Display Startnummer |
| TCPKeepAlive |yes|yes| TCP-Keepalive Meldungen schicken |
+------------------------+---+---+-------------------------------------------+
| Port | 22|122| Port 22 --> 122 (gegen Bot-Attacken) |
| Protocol |2,1| 2| Protokoll 1 ist unsicher |
| ChallengeResponse- |yes| no| CR-Authentifizierung erlaubt (PAM) |
| Authentication | | | |
+------------------------+---+---+-------------------------------------------+
Der private Schlüssel sollte durch eine PASSPHRASE (das ist ein längerer Text
ähnlich einem Passwort) gesichert werden, mit der er "überschlüsselt" wird,
damit er nicht im Klartext gespeichert ist. Diebstahl oder Kompromittierung des
Rechners führt dann nicht zur Kompromittierung des privaten Schlüssels.
Beim Remote-Login per SSH wird dann nach der Passphrase des Schlüssels gefragt
(damit dieser entschlüsselt werden kann) statt nach dem Passwort.
$ ssh-keygen -p -f ~/.ssh/id_dsa # -p=passphrase, -f=file
$ ssh-keygen -p # Automatisch Datei ~/.ssh/id_rsa
Enter file in which the key is (/home/tsbirn/.ssh/id_rsa):
Enter old passphrase: XXXXXXXXX
Key has comment '/home/tsbirn/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase): YYYYYYYYY
Enter same passphrase again: YYYYYYYYY
Your identification has been saved with the new passphrase.
Die Passphrase ist jedesmal einzugeben, wenn ein Zugriff auf den privaten
Schlüssel notwendig ist (für automatischen Verbindungs-Aufbau ist das unsinnig,
man kann aber auch mehr als ein Schlüsselpaar erzeugen, um dies zu umgehen).
Soll die Passphrase wieder entfernt werden, den privaten Schlüssel analog mit
einer LEEREN Passphrase überschlüsseln.
Alternativ kann die Passphrase über einen SSH-AGENTEN zur Verfügung gestellt
werden, so dass sie nur 1x eingegeben werden muss, anschließend im Speicher
steht und bei jedem SSH-Kommando automatisch zur Verfügung gestellt wird:
ssh-agent # Linux
Pageant # Windows (Putty Agent)
Er dient als "Wrapper" für beliebige andere Prozesse (z.B. die Shell oder den
X-Server) und hält für sie "entsperrte" private Schlüssel im Speicher vor.
ssh-agent # SSH-Agenten starten --> ergibt Shell-Befehle
eval `ssh-agent -c` # -c=C-Shell Befehle erzeugen (C-Shell Syntax)
eval `ssh-agent -s` # -s=Bourne-Shell Befehle erzeugen (Bourne-Syntax)
eval $(ssh-agent -s) # -s=Bourne-Shell Befehle erzeugen (Bash-Syntax)
Der Agent produziert als Ausgabe Shell-Befehle, die zwei Umgebungs-Variablen
SSH_AUTH_SOCK und SSH_AGENT_PID setzen, mit deren Hilfe andere Prozesse den
Agenten finden und mit ihm kommunizieren können:
SSH_AUTH_SOCK=/tmp/ssh-qsiis28019/agent.28019; export SSH_AUTH_SOCK;
SSH_AGENT_PID=28020; export SSH_AGENT_PID;
echo Agent pid 28020;
Diese Ausgabe muss abgefangen und als Befehl ausgeführt werden, daher die
Kommando-Substitution $(...) bzw. `...` und die Auswertung per "eval".
Nach dem Start des SSH-Agenten werden SSH-Schlüssel an ihn übergeben durch:
Pageant-Icon # Windows, Passphrase 1x eingeben (in graf. Dialog)
ssh-add # Linux, Passphrase 1x eingeben (auf Kommandozeile)
ssh-add < /dev/null # Linux, Passphrase 1x eingeben (in graf. Dialog)
Dabei wird, falls notwendig, 1x die Passphrase zum Entschlüsseln abgerufen:
ssh-add # Alle verfügbaren Schlüssel merken (max. 3)
ssh-add ~/.ssh/id_rsa # Einen RSA-Schlüssel merken
ssh-add ~/.ssh/id_dsa # Einen DSA-Schlüssel merken
ssh-add ~/.ssh/id_ecdsa # Einen ECDSA-Schlüssel merken
ssh-add ~/.ssh/id_ed25519 # Einen ED25519-Schlüssel merken
ssh-add ~/.ssh/identity # Einen RSA-Schlüssel merken
TIPP: Folgenden Alias "sshadd" definieren, der die beiden notwendigen
Befehle kombiniert und ihre etwas komplexe Syntax verpackt:
alias sshadd="eval $(ssh-agent -s); ssh-add" # oder
alias sshadd="eval $(ssh-agent -s); ssh-add < /dev/null" #
In Datei "~/.ssh/authorized_keys" können am Zeilenanfang jedes Schlüssels VOR
dem Schlüssel-Typ "ssh-rsa/ssh-dsa/ssh-ecdsa/ssh-ed25519/ssh" folgende Optionen
angegeben werden, die dann bei einer Anmeldung über diesen Schlüssel gelten:
+-------------------------+------------------------------------------------+
| Option | Bedeutung |
+-------------------------+------------------------------------------------+
| command="CMD...;..." | Kommando ausführen (mehrere durch ";" trennen) |
| environment="VAR=VALUE" | Umgebungsvariable setzen (durch "," trennen) |
| from="HOSTLIST" | Auf bestimmte Remote-Rechner beschränken (",") |
| no-agent-forwarding | SSH-Agenten NICHT weitergeben |
| no-port-forwarding | Ports NICHT weiterleiten (-L/-R) |
| no-pty | Kein Terminal zuweisen |
| no-user-rc | "~/.ssh/rc" NICHT ausführen |
| no-X11-forwarding | X11 NICHT weiterleiten |
| permitopen="HOST:PORT" | Lokale Weiterleitung beschränken |
| tunnel="N" | Tunnel N erzwingen (sonst nächstes freies) |
+-------------------------+------------------------------------------------+
ACHTUNG: Alle Optionen in eine Zeile schreiben, Werte mit Leerzeichen in "..."
oder '...' einschließen, mehrere Angaben durch "," trennen (keine Leerzeichen
zur Trennung verwenden), mehrere Kommandos durch ";" trennen".
Beispiele:
command="/bin/ls > /tmp/ls.txt" ssh-rsa KEY... # Nur Kmdo ausführen + sofort wieder abmelden
command="/usr/bin/ssh tom@192.168.1.1" ssh-dsa KEY... # Auf weiteren Rechner springen
from="192.168.1.1" ssh-ecdsa KEY... # Nur von diesem Rechner Anmeldung erlaubt
from="192.168.1.1",command="/usr/bin/ssh tom@192.168.1.1" ssh KEY... # Auf weiteren Rechner springen
Der Eintrag "command=CMD..." sorgt dafür, dass kein echter Login mehr erfolgt,
sondern das Kommando "CMD..." ausgeführt und danach die SSH-Verbindung wieder
beendet wird (sofern eine schlüsselbasierte Anmeldung erfolgreich stattfindet).
Bei einer passwortbasierten Anmeldung wird kein Kommando ausgeführt. Sinn:
* Kommando/Skript per reiner Anmeldung ausführen (freischalten)
* SSH-Verbindung nach außen über Proxy-Server (keine End-zu-End-Verbindung)
* SSH-Datenfluss überwachen
HINWEIS: Die Dokumentation dazu findet man in "man sshd" (Daemon!)
Durchschleusen von anderen Protokollen durch einen SSH-Tunnel. Insbesondere
KLARTEXT-Protokolle (z.B. TELNET, FTP, POP3, IMAP, SMTP, SNMP, ...) können auf
diese Weise nachträglich per verschlüsselten "Tunnel" abgesichert werden.
Dazu muss folgende "sshd"-Einstellung in "/etc/ssh/sshd_config" gelten:
AllowTcpForwarding yes
Es gibt zwei "Richtungen" des "Tunneling" gesteuert durch das SSH-Kommando auf
dem CLIENT, je nachdem ob anschließend eine Verbindung durch den Tunnel
1) ausgehend vom lokalen Rechner CLIENT (-L/-D) oder
2) ausgehend vom remote Rechner SERVER (-R)
aufgebaut werden soll:
lokal remote
+----------+ +----------+
| CLIENT | <==========> | SERVER |
+----------+ +----------+
1111 99 # Ports
* Lokal am CLIENT auf Port 1111 lauschen
* Daten weitergeben an SERVER auf Port 99
(d.h. CLIENT ist Client, SERVER ist Server).
* ERGEBNIS: Tunnel von CLIENT:1111 --> SERVER:99 aufgebaut
* ACHTUNG: "localhost" oder "127.0.0.1" statt CLIENT-IP nach -L!
CLIENT: ssh -L 1111:localhost:99 SERVER # Tunnel aufbauen (-L=local)
CLIENT: telnet localhost 1111 # Tunnel CLIENT --> SERVER nutzen
* Remote am SERVER auf Port 99 lauschen,
* Daten weitergeben an CLIENT auf Port 1111
(d.h. SERVER ist Client, CLIENT ist Server!).
* ERGEBNIS: Tunnel von SERVER:99 --> CLIENT:1111 aufgebaut
* ACHTUNG: CLIENT-IP statt "localhost" oder "127.0.0.1" nach -R!
CLIENT: ssh -R 99:CLIENT:1111 SERVER # Tunnel aufbauen (-R=remote)
SERVER: telnet localhost 99 # Tunnel SERVER --> CLIENT nutzen
Keiner kann die Kommunikation mitlesen (-L=lokal, sleep=lange laufendes
Kommando starten, das keine Rechenzeit verbraucht und es in den Hintergrund
schieben):
ssh -L 8080:localhost:80 USER@SERVER "sleep 100000" & # Nur falls ohne Passw. mögl.
ssh -L 8080:localhost:80 USER@SERVER "sleep 100000" # Auch mit Passwortabfrage
Strg-Z # Anhalten
bg # In Hintergrund schalten (background)
lokal remote
+----------+ +----------+
| CLIENT | <==========> | SERVER |
+----------+ +----------+
8080 80
Im Browser auf dem CLIENT den lokalen Rechner auf Port 8080 ansprechen,
die HTTP-Daten werden verschlüsselt an/vom SERVER Port 80 übertragen:
localhost:8080 # <-> SERVER:80
Keiner kann die Kommunikation mitlesen:
ssh -L 5000:localhost:110 SERVER # Tunnel aufbauen
fetchmail # Gültige ".fetchmailrc" muss existieren
# und auf localhost:5000 zugreifen
Keiner kann die Kommunikation mitlesen (telnet "verschlüsselt"!). Vorher
telnet-Daemon/Server auf SERVER installieren und aktivieren sowie "xinetd"
rekonfigurieren und neu starten:
ssh -L 5000:localhost:23 SERVER "sleep 100000" # Tunnel aufbauen
telnet localhost 5000 # Telnet-Verb. aufbauen
lokal remote
+----------+ +----------+
| CLIENT | <==========> | SERVER |
+----------+ +----------+
5000 23
Keiner kann Kommunikation mitlesen:
ssh -L 3306:localhost:3306 SERVER # Tunnel aufbauen
mysql -uUSER -p --protocol tcp localhost # TCP-Verbindung erzwingen!
lokal remote
+----------+ +----------+
| CLIENT | <==========> | SERVER |
+----------+ +----------+
3306 3306
Port 10080 lokal über Port 3080 auf Zw.rechner ZWHOST mit Port 80 auf
Zielrechner SERVER verbinden (2 Tunnels!) und somit HTTP-Protokoll (Port 80)
vom SERVER zum Port 10080 auf dem CLIENT über eine Zwischenstation ZWHOST (z.B.
Firewall) tunneln:
+----------+ +----------+ +----------+
| CLIENT | <==========> | ZWHOST | <==========> | SERVER |
+----------+ +----------+ +----------+
10080 3080 80
Variante 1):
ssh -l root -L 10080:SERVER:80 CLIENT # Auf ZWHOST ausgeführt
Variante 2):
ssh -l root -L 10080:localhost:3080 ZWHOST \ # Auf CLIENT ausgeführt
"ssh -L 3080:localhost:80 SERVER" # Auf ZWHOST ausgeführt
Ablauf:
* Anmelden am SSH-Port von Rechner ZWHOST
* Tunneln von Port 10080 am eigene Rechner CLIENT
zu Port 3080 auf mittlerem Rechner ZWHOST (-L = "localhost" = dort)
* Anmelden am SSH-Port von Rechner SERVER
* Tunneln von Port 3080 am Rechner ZWHOST
zu Port 80 auf Endrechner SERVER (-L = "localhost" = dort)
HINWEIS: Damit obiger Befehl nicht ständig einzutippen ist, sollte er per
Alias oder Funktion in einer der persönlichen Shell-Konfigurations-Dateien
oder per Shell-Skript im persönlichen Binär-Verz. realisiert werden:
# Alias
alias srvhttp='ssh -l root -L 10080:localhost:3080 ZWHOST "ssh -L 3080:localhost:80 SERVER"'
# Funktion
srvhttp()
{
ssh -l root -L 10080:localhost:3080 ZWHOST "ssh -L 3080:localhost:80 SERVER"
}
# Shell-Skript "srvhttp.sh" (ausführbar machen: chmod a+x srvhttp.sh):
+--------------------------------------------+
|#!/bin/sh |
|ssh -l root -L 10080:localhost:3080 ZWHOST \|
| "ssh -L 3080:localhost:80 SERVER" |
+--------------------------------------------+
Konfiguration einer "Putty-Session" am Windows-Client 192.168.0.200, die über
den Zwischenrechner 192.168.0.201 auf den Web-Server 192.168.0.250 Web-Zugriff
durchführen soll:
192.168.0.200 192.168.0.201 192.168.0.250
User: Admin User: schulung User: kurs1
+----------+ +----------+ +----------+
| WIN | <==========> | ZWHOST | <==========> | SERVER |
+----------+ +----------+ +----------+
80 3080 80
In "Putty-Session" vorzunehmende Einstellungen:
Session --> Host Name (or IP address): # Passwort/Passphrase
schulung@192.168.0.201
Connection --> SSH --> Tunnels --> Forwarded Ports: # Source port: 80
L80 localhost:3080 # Destination: localhost:3080
Connection --> SSH --> Remote Command:
ssh -l kurs1 -L 3080:localhost:80 192.168.0.250 # Passwort für "kurs1"!
ssh -L 3080:localhost:80 kurs1@192.168.0.250 # (analog)
Achtung: Wahrscheinlich ist 2x Passwort/Passphrase einzugeben:
ssh, slogin Verbindung zu fremdem Rechner aufnehmen
(sicherer Ersatz von "telnet", "rsh", "rlogin")
scp Dateien von/zu fremden Rechner transferieren
(sicherer Ersatz von "rcp")
sftp Dateien von/zu fremden Rechner transferieren
(sicherer Ersatz von "ftp")
ssh-keygen Schlüsselpaar erzeugen
ssh-keyscan Öffentlichen Schlüssel von Rechnern holen
ssh-add Privaten Schlüssel beim "ssh-agent" registrieren
ssh-agent Privaten Schlüssel verwalten
(automatische Beantwortung von "challenges")
ssh-copy-id Öffentlichen Schlüssel auf Zielrechner transferieren
(für schlüsselbasierte Anmeldung)
/etc/ssh/sshd_config Zentrale Server-Konfiguration
(es gibt keine benutzerspezifische!)
/etc/ssh/ssh_host_rsa_key Server Identity (Private Key, Protocol V2 = RSA)
/etc/ssh/ssh_host_rsa_key.pub Server Identity (Public Key, Protocol V2 = RSA)
/etc/ssh/ssh_host_dsa_key Server Identity (Private Key, Protocol V2 = DSA)
/etc/ssh/ssh_host_dsa_key.pub Server Identity (Public Key, Protocol V2 = DSA)
/etc/ssh/ssh_host_ecdsa_key Server Identity (Private Key, Protocol V2 = ECDSA)
/etc/ssh/ssh_host_ecdsa_key.pub Server Identity (Public Key, Protocol V2 = ECDSA)
/etc/ssh/ssh_host_ed25519 Server Identity (Private Key, Protocol V2 = ED25519)
/etc/ssh/ssh_host_ed25519_key.pub Server Identity (Public Key, Protocol V2 = ED25519)
/etc/ssh/ssh_host_key Server Identity (Private Key, Protocol V1 = RSA)
/etc/ssh/ssh_host_key.pub Server Identity (Public Key, Protocol V1 = RSA)
/etc/ssh/ssh_known_hosts Public Keys der bekannten Remote-Server (fest)
/etc/ssh/ssh_config Zentrale Client-Konfiguration
~/.ssh/config Benutzerspezifische Client-Konfiguration
~/.ssh/id_rsa User Identity (Private Key, Protocol 2 = RSA)
~/.ssh/id_rsa.pub User Identity (Public Key, Protocol 2 = RSA)
~/.ssh/id_dsa User Identity (Private Key, Protocol 2 = DSA)
~/.ssh/id_dsa.pub User Identity (Public Key, Protocol 2 = DSA)
~/.ssh/id_ecdsa User Identity (Private Key, Protocol 2 = ECDSA)
~/.ssh/id_ecdsa.pub User Identity (Public Key, Protocol 2 = ECDSA)
~/.ssh/id_ed25519 User Identity (Private Key, Protocol 2 = EC25519)
~/.ssh/id_ed25519.pub User Identity (Public Key, Protocol 2 = EC25519)
~/.ssh/identity User Identity (Private Key, Protocol 1 = RSA)
~/.ssh/identity.pub User Identity (Public Key, Protocol 1 = RSA)
~/.ssh/known_hosts Public Keys der bekannten Remote-Server (updatebar)
~/.ssh/authorized_keys Public Keys der bekannten Remote-Benutzer (updatebar)
/etc/ssh/sshrc Zentrale Kommandos für Login-Shells
~/.ssh/rc Benutzerabh. Kommandos für Login-Shell
~/.ssh/environment Environment-Variablen für Login-Shell
* Öffentlichen Schlüssel per Kommandoaufruf vom Remote-Rechner holen:
ssh-keyscan -t rsa HOST # V2: RSA-Schlüssel von HOST holen
ssh-keyscan -t dsa HOST # V2: DSA-Schlüssel von HOST holen
ssh-keyscan -t ecdsa HOST # V2: ECDSA-Schlüssel von HOST holen
ssh-keyscan -t ed25519 HOST # V2: ED25519-Schlüssel von HOST holen
ssh-keyscan HOST # ALLE Schlüssel von HOST holen
* Alle Rechner in Datei "SSH_HOSTS" finden, die einen neuen oder anderen
öffentlichen RSA/DSA/ECDSA/ED25519-Schlüssel haben als in "~/.ssh/known_hosts"
hinterlegt (beide Dateien müssen nicht sortiert sein):
ssh-keyscan -t rsa,dsa,ecdsa,ed25519 -f SSH_HOSTS |
sort -u |
diff - <(sort -u ~/.ssh/known_hosts)
* Änderungen an der SSH-Server-Konfigurations-Datei "/etc/ssh/sshd_config"
wirken sich erst dann aus, wenn der SSH-Daemon neu gestartet wird.
* Änderungen an der SSH-Client-Konfigurations-Datei "/etc/ssh/ssh_config"
bzw. "~/.ssh/config" wirken sich automatisch auf DANACH neu hergestellte
Verbindungen aus, NICHT aber auf bereits aktive Verbindungen.
* Der eigene Benutzername ist Standard bei der SSH-Anmeldung, sofern man keinen
anderen angibt (per -l USER oder USER@HOST). D.h. man kann sich mit einem
anderen Benutzernamen auf dem Remote-Rechner anmelden, sofern man dessen
Passwort weiß oder dessen privaten Key besitzt.
* Besitzverhältnisse + Zugriffsrechte der SSH-Konfigurations-Dateien und
ihrer Verz.pfade müssen einige Bedingungen erfüllen, damit SSH eine
schlüsselbasierte Anmeldung als USER erlaubt (nur falls "StrictModes yes"
in "/etc/ssh/sshd_config" gesetzt ist):
+ Benutzer USER der SSH-Anmeldung MUSS Besitzer folgender Verz./Dateien sein:
"/home/USER"
"/home/USER/.ssh"
"/home/USER/.ssh/authorized_keys"
+ Für obige Verz./Dateien darf NICHT gesetzt sein:
"w" für "Besitzer-Gruppe" + "Andere" --> drwxr-xr-x -rwxr--r--
+ Für priv. Schlüsseldateien darf NICHT gesetzt sein:
"rw" für "Besitzer-Gruppe" + "Andere" --> -rw-------
Typische Fehlermeldungen in "/var/log/auth.log" (bzw. "/var/log/messages")
auf der Server-Seite bei falschen Zugriffsrechten auf Konfigurations-Dateien:
Authentication refused: bad ownership or modes for directory /home/USER1
Authentication refused: bad ownership or modes for directory /home/USER1/.ssh
* Der "ssh-agent" legt die Passphrase bzw. den privaten Schlüssel NIE auf Datei
ab, sondern behält sie im Speicher, bis der Benutzer sich wieder abmeldet.
* Der "ssh-agent" ist nur für Programme aktiv, die im gleichen Terminal wie er
gestartet werden (die gleiche Shell als Elternprozess haben).
* Standardmäßig erfolgt keine X11-Umlenkung mehr. Dazu ist die Option "-X/-Y"
beim Aufruf von "ssh" anzugeben oder "ForwardX11" und "TrustedForwardX11" in
"/etc/ssh/ssh_config" bzw. "~/.ssh/config" auf "yes" zu setzen.
* Zum testen von Verbindungsproblemen:
ssh -v # Meldungen zum Verbindungsaufbau
ssh -vv # Mehr Meldungen zum Verbindungsaufbau
ssh -vvv # Noch mehr Meldungen zum Verbindungsaufbau
* Woher stammt der HOST-Key unter "/etc/ssh"?
Wird beim Installieren eines Rechners automatisch eingerichtet.
--> Kopien eines Rechners als virtuelle Maschine haben gleichen HOST-Key!
* Unbedingt Passphrase != Passwort(e) wählen
(höhere Sicherheit; weniger Verwirrung: was mache ich eigentlich?).
* Privater Schlüssel:
+ DIREKT auf Rechner erzeugen, wo er eingesetzt werden soll
+ NIE weitergeben/kopieren/...
+ ÜBERSCHLÜSSELN mit Passphrase falls Rechner allgemein zugänglich ist
+ SICHER verwahren: Bei Verlust sind alle mit dem öffentlichen Schlüssel
verschlüsselten Daten verloren (z.B. ausgedruckt in Safe legen)
* Typischer FEHLER: Neues Schlüsselpaar erzeugen, dabei wird altes überschrieben
--> Schlüsselpaar ausdrucken und sicher verwahren
* In Datei "authorized_keys" gilt:
+ Jedes einzelne Zeichen wichtig
+ Anzahl der Leerzeichen wichtig
+ Vorne Einschränkungen für die Verbindung eintragbar (bis 1. Leerzeichen)
+ Text hinten (USER@HOST) ist irrelevant (bel. Kommentar nach letztem Leerz.)
--> Für Kommentar nutzen der User+Rechner identifiziert
+ Pro Zeile ein vollständiger (langer) Eintrag
+ Leerzeilen werden ignoriert
* SSH (original)
* SSH (original)
* OpenSSH
* OpenSSH
* OpenSSH
* Putty (Windows SSH)
* Zlib
* OpenBSD
* OpenSSL
* WinSCP
* MobaXterm (X-Terminal für Windows)
* MobaXterm Plugins
* FileZilla
* KiTTY (Putty-Ersatz)
* Öffentlicher Keyserver