19.04.2023

OpenSSH Server / Client

Navigation:

OpenSSH Befehls- Übersicht
SSH Server-Zertifikate erstellen
SSH mit Zertifikat nutzen
SSH-Agent
Port Weiterleitung einrichten
SFTP Dateiaustausch
sonstiges

Links:
OpenSSH Projekt
OpenSSH Handbuch
OpenSSH Public Key Authentifizierung

Mosh eine Mobile Shell für SSH Verbindungen, die UDP anstelle TCP einsetzt, für Verbindungen mit hohen Latenzen, die auch mal zusammenbrechen kann unterstützt Roaming, wechselnde IPs u.a.

OpenSSH Befehls- Übersicht

SSH unter Debian installieren

apt-get install ssh

SSH Befehle
ssh-keygen -t das -b 1024 -C user@domain.tld	erstellt einen DSA Schlüssel (-t dsa) mit 1024 Bit (-b 1024) und als Kommentar die eMail adresse angehängt (-C user@domain.tld).
ssh-keygen -t rsa -b 4096 -C user@domain.tld	1024 Bit RSA Key erstellen
ssh-copy-id -i ~/.ssh/id_rsa.pub user@ssh-server	kopiert den öffentlichen Schlüssel id_rsa.pub auf den Remote Host und hängt ihn an die Datei authorized_keys an.
ssh-keygen -t rsa -l	Fingerprint eines Keys anzeigen (-l)
scp -P 1234 /Verz./Quelldatei user@remote.host:/Verz./Zieldatei	vom lokalen Rechner auf einen Remote-Host kopieren, mit -P den SSH-Port des RemotHost angeben
scp user@remote.host:/Verz./Quelldatei /Verz./Zieldatei	vom Remote-Host auf den lokalen Rechner kopieren
scp -r /home/user User@RemoteHost:/home	kopiert ganze Verzeichnisbäume (-r) vom Client zum RemoteHost
scp -p Datei User@RemoteHost:/tmp/archiv	kopiert eine Datei (-p) vom Client zum RemoteHost, Rechte und Besitzer/Gruppen für die Datei bleiben erhalten
ssh user@remote.host -1	Protokoll Version 1 (RSA) verwenden
ssh user@remote.host -2	Protokoll Version 2 (RSA-DSA) verwenden
ssh -i .ssh/id_rsa-server1 mmuster@ssh.domain.tld	SSH Verbindung mit Angabe der PrivateKey Datei
ssh user@remote.host "Befehl"	führt nach dem Anmelden einen Befehl aus
ssh user@remote.host -t "Befehl"	führt nach dem Anmelden einen Befehl aus in einem "Pseudo Terminal"
ssh -f user@remote.host -L 2222:remote.host:110 sleep 600	leitet den "remote.host" Port 110 (POP3) auf den lokalen Port 2222 um, SSH wartet 10min im Hintergrund (sleep 600) bevor es sich automatisch beendet (-f).
ssh-keyscan -t rsa,dsa remote.host	SSH-Keys für einen Remote-Host anzeigen
sftp	Interaktiver Client zum Dateiaustausch, ähnlich FTP mit Verschlüsselung
X-Befehl &	im Terminal eine X-Anwendung ausgeführen und in denn Hintergrund stellen, das Terminal ist gleich für die nächsten Befehl frei (z.B. mozilla &)
das Zeichen (~) zu Beginn einer Zeile, leitet in einer SSH Sitzung die Escape-Sequenz ein
ssh -e Zeichen	definiert das Zeichen für die Escape-Sequenz (Standard: ~)
~?	listet alle möglichen Befehle auf
~#	zeigt alle SSH Verbindungen an
~.	beendet eine Verbindung
~C	Kommand Line öffnen

wichtige Dateien und deren Bedeutung
/etc/ssh	Konfigurationsverzeichnis ( Global )
/etc/ssh/ssh_config	SSH Client Konfig Datei ( Global )
/etc/ssh/sshd_config	SSH Server Konfig Datei
/etc/ssh/ssh_known_hosts	Liste und Keys der Remote-Hosts ( Global )
~/.ssh	Benutzer SSH-Verzeichnis (Public und Privat Key-Files, Clientkonfiguration)
~/.ssh/config	SSH Client Konfigurations Datei des User
$HOME/.ssh/identity	Private-Key für ein SSH-Protokoll 1 Version RSA Key
$HOME/.ssh/identity.pub	Public-Key für ein SSH-Protokoll 1 Version RSA Key
$HOME/.ssh/id-rsa.pub	Public-Key für ein SSH-Protokoll 2 Version RSA Key
$HOME/.ssh/id-rsa	Private-Key für ein SSH-Protokoll 2 Version RSA Key
$HOME/.ssh/id-dsa.pub	Public-Key für ein SSH-Protokoll 2 Version DSA Key
$HOME/.ssh/id-dsa	Private-Key für ein SSH-Protokoll 2 Version DSA Key
$HOME/.ssh/known_hosts	Liste und Keys der Remote-Hosts
~/.ssh/authorized_keys	Autorisierungsdatei auf dem Server

Optionen für sshd_config

Parameter	Beschreibung
Protocol 1	stellt auf RSA V1 Verschlüsselung um
Protocol 2	stellt auf RSA-DSA V2 Verschlüsselung um
Port 1-65535	SSH - Server TCP Port (Default=22), man kann in einer Konf auch meherere Port - Einträge drin haben, wenn der Server auf mehreren Ports lauschen soll
PermitRootLogin yes/no/without-password	Root-Login akzeptieren ja/nein/nur wenn die Authentifizierung nicht über ein Passwort erfolg, als z.B. über Zertifikat
PermitEmptyPasswords yes/no	Benutzerkonten mit leerem Passwort können sich anmelden ja/nein (Default=no)
PasswordAuthentication yes/no	Login via Password ja/nein (wenn "no" gesetzt ist kann man sich nur über ein Zertifikat anmelden)
PubkeyAuthentication yes/no	Login via Public Key ja/nein (wenn "yes" gesetzt ist kann man sich mit ein Zertifikat anmelden)
UsePAM yes/no	Login via Password ja/nein (wenn "no" gesetzt ist kann man sich nur über ein Zertifikat anmelden)
X11Forwarding yes	ermöglicht das ausführen von X-Anwendungen auf dem Client (ssh muss dann mit der Option -X gestartet werden)
ClientAliveInterval 60	wenn ein NAT Router zwischen der Verbindung hängt, sorgt die Option dafür das der Server die Verbindung alle 60 Sekunden auffrischt, so das diese nicht vom Router getrennt wird. Man kann auch z.B. in Putty unter Connection \| Keepalives setzen.
UseDNS yes/no	(Standard: yes) DNS Abfrage der Client IP beim Login, wenn DNS nicht richtig funktioniert, kann die Reverse Lookup DNS Abfrage bis zu 10 Sekunden dauern. Das erkennt man an der Wartezeit, zwischen Benutzernamen Abfrage und Passwort Abfrage.
StrictMode yes/no	wird geprüft, ob bestimmte Dateien die erforderlichen Rechte besitzen. z.B. minimale Rechte auf authorized_keys
MaxAuthTries 6	max. Anzahl der Anmeldeversuche

Die Optionen PasswordAuthentication, PubkeyAuthentication, UsePAM machen nur in Verbindung miteinander Sinn. Mit diesem Beispiel kann man den Login mit Passwörtern unterbinden.

PubkeyAuthentication yes
UsePAM no
PasswordAuthentication no

Optionen für ssh_config

Compression yes/no	Kompression ja/nein (je nach verfügbarer Bandbreite)
ForwardX11 yes	ermöglicht das ausführen von X-Anwendungen auf dem Client (ssh -X ist nicht mehr notwendig)
ForwardAgent yes	ssh-agent Anfragen weiterleiten
ServerAliveInterval 60	verhindert bei NAT Routern das einfrieren der Verbindung, durch Auffrischung in der angegebenen Zeit.

SSH Server-Zertifikate erstellen

SSH Server Fingerprint anzeigen

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

alle SSH Schlüssel des Systems prüfen

sudo ssh-vulnkey -a

SSH Server Key erneuern

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

SSH mit Zertifikat nutzen

1. Schlüsselpaar erzeugen Option -C fügt ein Kommentar an.

ssh-keygen -t rsa -C "<hostname oder eMail Adresse u.a.>"

-b 4096 - RSA-Schlüssel mit einer Bitlänge von 4096 Bit erstellen
-f ~/.ssh/id_rsa.server - Name der Schlüsseldatei vorgeben

ssh-keygen fragt dann wo der Schlüssel erzeugt werden soll (Default ~/.ssh/id_rsa und id_rsa.pub), danach die Passphrase zwei mal eingeben (damit wird der Private-Key verschlüsselt)

- ZugriffsRechte setzen, Zugriff auf private Schlüsseldatei id_rsa muss verhindert werden

chmod 0655 ~/.ssh
chmod 0600 ~/.ssh/id_rsa

2. den öffentlichen Schlüssel zum SSH-Server übertragen und in die Datei ~/.ssh/authorized_keys speichern.

bei lokalem Zugriff

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

wenn das .ssh Verzeichnis des Users nicht existiert, muss es vorher angelegt werden. "mkdir ~/.ssh"

bei Fernzugriff

ssh user@ssh-server "mkdir ~/.ssh; chmod 0655 ~/.ssh"
scp ~/.ssh/id_rsa.pub ssh-server:~/.ssh/authorized_keys

oder

ssh-copy-id -i ~/.ssh/id_rsa.pub user@ssh-server

oder

cat ~/.ssh/*.pup | ssh user@ssh-server 'cat >> .ssh/authorized_keys'

Bei Problemen mit SSH kann man noch die Rechte der Dateiein prüfen.

Beim Einloggen auf dem Server, muss man jetzt die Passphrase (sofern man eine eingegeben hat) des Keys eingeben.

Das Einloggen auf dem Server automatisieren, wenn man sich z.B. von Rechner1 auf Rechner2 und dann auf Rechner3 verbinden möchte, muss man normalerweise auf allen diesen Rechnern seinen privaten Key (id_rsa oder id_dsa) hinterlegen was ein Sicherheitsproblem darstellt. Dies ist nicht nötig wenn man den ssh-agent verwendet.

- Bitrate des Schlüssels und Fingerprint anzeigen

ssh-keygen -f ~/.ssh/id_rsa -l

SSH Client für mehrere Server konfigurieren

- Keys für mehere Server erstellen

ssh-keygen -t rsa -f ~/.ssh/id_rsa.server1 -C "server1.domain.tld"
ssh-keygen -t rsa -f ~/.ssh/id_rsa.server2 -C "server2.domain.zz"
ssh-keygen -t rsa -f ~/.ssh/id_rsa.server3 -C "server2.domain.local"

- Datei ~/.ssh/config erstellen und Zugriffsrechte setzen

touch ~/.ssh/config
chmod 600 ~/.ssh/config

# ssh (secure shell) configuration file
# ~/.ssh/config
#

Host server1
  HostName server1.domain.tld
  User mmuster
  IdentityFile ~/.ssh/id_rsa.server1

Host server2
  HostName server2.domain.zz
  User alibaba
  Port 45678
  IdentityFile ~/.ssh/id_rsa.server2

Host server3
  HostName server3.domain.local
  User admin
  Port 8671
  IdentityFile ~/.ssh/id_rsa.server3

- Login zum Server, da die Einstellungen duch die config bekannt sind, bracht man nur noch den Alias anzugeben, den man mit "HOST" definiert hat.

ssh server1

SSH-Agent

1. Umgebungsvariablen für den ssh-agent setzen
eval `ssh-agent`

2. Nachsehen ob der Agent läuft, Anzeigen der Registrierten Keys
ssh-add -l
The agent has no identities.

3. Passphrase registrieren (untr ~/.ssh/ wird nach private Keys gesucht und registriert)
ssh-add

4. Konfiguration prüfen entweder in ~/.ssh/config oder /etc/ssh/ssh_config
ForwardAgent yes
oder auf der Kommandozeile die Option -A verwenden

Ab jetzt kann man sich (wenn die Variablen gesetzt sind) ohne Eingabe der Passphrase auf dem Remothost einloggen. (bis zum nächsten Abmelden)
Variablen: SSH_AGENT_PID, SSH_AUTH_SOCK
Die Autorisierung wird dann immer vom Rechner auf den der Agent läuft durchgeführt und zu den anderen weitergeleitet.

X mit SSH benutzen.
in der /etc/ssh/sshd_config eintragen
X11Forwarding yes

auf dem Client "ssh -X server xeyes" um das Programm xeyes zu starten, oder in der /etc/ssh_config oder ~/.ssh/config den Eintrag setzen, dann wird die Option (-X) nicht mehr benötigt.
ForwardX11 yes

Port Weiterleitung einrichten

SSH Syntax

ssh -L <bind-adresse>:<localport>:<targethost>:<targetport> <user>@<authhost>

Parameter für SSH während einer interaktiven Sitzung ändern.
1. Sitzung öffnen

ssh user@server.tld

2. zum SSH Prompt wechseln

~C

3. Portweiterleitung setzen

ssh> -L 8080:localhost:631

Forwarding port.

der Port 631 des SSH-Servers wird auf Port 8080 des SSH-Clients geleitet. So kann man durch Eingabe von http://localhost:8080 den Cups-Server des SSH-Server über eine Verschlüsselte Verbindung nutzen. Der Port 8080 des Clients darf aber nicht durch ein anderes Programm belegt sein. Das ist sehr hilfreich für Dienste die man nur über "localhost" erreichen und konfigurieren kann.

- das gleiche erreicht man mit

ssh -L 8080:localhost:631 server.tld

- mit der Option (-g) können sich auch andere Rechner mit den weitergeleiteten Port verbinden, -f bewirkt das SSH im Hintergrund ausgeführt wird und -N bewirkt das keine neue Shell geöffnet wird. Verbindung kann man mit ~. beenden.

ssh -g -f -N -L 8080:localhost:631 server.tld

- Mailserver über SSH abfragen, auf den Client kann man dann den Mailserver über localhost:110 und localhost:25 erreichen.

ssh -f -N -L 110:mailserver.tld:110 -L 25:mailserver.tld:25 -l user mailserver.tld

Tunnel für eine Anwendung anlegen. Alle Daten vom Port 5900 des Clients werden durch einen gesicherten Tunnel auf den Port 5900 des entfernten PCs geschickt.

ssh -L 5900:127.0.0.1:5900 server.tld
ssh -L 5900:127.0.0.1:5900 -L 5901:127.0.0.1:5901 -p 52200 user@server.tld

- ssh Server auf Port 52200 und VNC-Server auf Localhost umleiten.

- Zugriff auf Samba Freigaben von einem entfernten Server über SSH

ssh -L 100139:192.168.1.1:139 user@server.tld
smbclient -L -p 100139 \\127.0.0.1

der erste Befehl leitet den Port 139 (SMB) des Servers auf den Localen Port 100139, dann kann man eine Verbindung zum Localen Port 100139 mit dem smbclient herstellen, diese wird dann durch den SSH Tunnel zum Port 139 weitergeleitet und man hat die gewünschte Samba Freigabenverbindung.

Mit der Option -g erlaubt man auch anderen Rechnern den erstellten Tunnel zu nutzen.

ssh -gL 100139:192.168.1.1:139 user@server.tld

Wenn diese Verbindung öffter gebraucht wird kann man diese auch in die .ssh/config Datei eintragen, das spart dann die Eingabe der Tunneloptionen.

#~/.ssh/config
host name
	hostmane server.dyndns.org
	localforward 100139 192.168.1.1:139

MySQL über SSH Tunnel

ssh -l login-name -N -L <localport>:<targethost>:<targetport> remotServer
Optionen
-l	Nutzernamen
-L	Weiterleitung definieren
-N	keine LoginShell starten

z.B.

ssh -l ruser -N -L 12345:localhost:3306 remoteServer

MySQL Client starten

mysql --port=12345 -h 127.0.0.1 --user=dbuser --password=dbpass Datenbankname

Option -h 127.0.0.1 erzwing die Nutzung der TCP-Verbindung über den Port, MySQL nutzt lokal Standardmäßig immer den Socket.

Dump einer Datenbank anlegen

mysqldump --port=12345 -h 127.0.0.1 --user=dbuser --password=dbpass Datenbankname > backup.sql

SFTP Dateiaustausch

sftp user@remote.host
ls	Verzeichnisinhalt anzeigen
get quelldatei /home/user/zieldatei	kopiert eine Datei vom Remote-Host zum lokalen Rechner
put quelldatei /home/user/zieldatei	kopiert eine Datei vom lokalen Rechner zum Remote-Host
quit	beendet die Verbindung