SSH – Grundlagen & Schlüsselverwaltung

Was ist SSH – und warum ist es so wichtig?

SSH steht für Secure Shell und ist das Standardprotokoll für verschlüsselten Remote-Zugriff auf Linux- und Unix-Systeme. Bevor SSH existierte, wurden Protokolle wie Telnet oder rsh genutzt – beide übertragen alles im Klartext, inklusive Passwörter. SSH verschlüsselt die gesamte Verbindung mit modernen kryptografischen Verfahren, authentifiziert beide Seiten und schützt so vor Man-in-the-Middle-Angriffen.

Für jeden IT-Allrounder im KMU-Umfeld ist SSH unverzichtbar: Ob du einen Linux-Server administrierst, eine NAS konfigurierst, Docker-Container verwaltest oder Git-Commits signierst – SSH ist überall.

Technische Grunddaten:

• Standard-Port: 22 TCP
• Protokollversion: SSH-2 (SSH-1 ist veraltet und unsicher)
• Implementierung: OpenSSH (de facto Standard, vorinstalliert auf fast allen Linux-Distros)
• Seit Windows 10 Version 1809 auch als optionales Feature in Windows verfügbar

Erste Verbindung aufbauen

Der grundlegendste Anwendungsfall: du verbindest dich per SSH auf einen Server.

# Grundlegende Verbindung
ssh username@192.168.1.10

# Mit einem anderen Port (falls der Admin den Standard-Port geändert hat)
ssh -p 2222 username@server.firma.ch

# Mit explizit angegebenem Schlüssel
ssh -i ~/.ssh/id_ed25519 username@server

# Verbose-Modus für Fehlerdiagnose (sehr nützlich!)
ssh -v username@192.168.1.10

Beim ersten Verbindungsaufbau zu einem neuen Server erscheint diese Meldung:

The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Tippe yes, um den Host-Fingerabdruck in ~/.ssh/known_hosts zu speichern. Bei zukünftigen Verbindungen prüft SSH automatisch, ob der Fingerabdruck übereinstimmt.

SSH-Schlüsselpaar erstellen

Passwort-Authentifizierung ist bequem, aber unsicher – Passwörter können erraten, geleakt oder durch Brute-Force geknackt werden. Die deutlich sicherere Alternative: Public-Key-Authentifizierung.

Das Prinzip ist einfach:

1. Du erzeugst ein Schlüsselpaar: einen privaten Schlüssel (bleibt geheim auf deinem Rechner) und einen öffentlichen Schlüssel (kommt auf den Server)
2. Der Server kennt deinen öffentlichen Schlüssel und prüft damit, ob du den passenden privaten Schlüssel besitzt
3. Du beweist den Besitz des privaten Schlüssels, ohne ihn jemals zu übertragen

Schlüsselpaar generieren

# Ed25519 – empfohlener Algorithmus (modern, kompakt, sehr sicher)
ssh-keygen -t ed25519 -C "seya@firma.ch"

# RSA mit 4096 Bit – für ältere Systeme die kein Ed25519 unterstützen
ssh-keygen -t rsa -b 4096 -C "seya@firma.ch"

Der Parameter -C ist ein Kommentar – er wird im öffentlichen Schlüssel gespeichert und hilft dir, den Schlüssel später zuzuordnen (z.B. nach User oder Gerät).

Was passiert danach:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/seya/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Für den Pfad einfach Enter drücken (Standardpfad ist gut). Die Passphrase ist ein optionales Passwort, das den privaten Schlüssel verschlüsselt – bei Verlust des Schlüssels kann der Angreifer ihn dann nicht sofort verwenden.

Resultat:

Öffentlichen Schlüssel auf dem Server hinterlegen

Damit der Server dich per Schlüssel einloggt, muss dein öffentlicher Schlüssel in der Datei ~/.ssh/authorized_keys des jeweiligen Users auf dem Zielserver stehen.

Methode 1: ssh-copy-id (einfachste Variante)

# Kopiert den Standard-Public-Key auf den Server
ssh-copy-id username@192.168.1.10

# Mit spezifischem Schlüssel
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server.firma.ch

Danach wirst du noch einmal nach dem Passwort gefragt – das ist das letzte Mal, danach geht es per Schlüssel.

Methode 2: Manuell

# Public Key ausgeben
cat ~/.ssh/id_ed25519.pub

# Inhalt manuell auf dem Server in authorized_keys eintragen
# Auf dem Zielserver einloggen und dann:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "dein-public-key-inhalt" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Methode 3: Per scp (wenn du schon SSH-Zugriff hast)

# Public Key auf den Server kopieren
scp ~/.ssh/id_ed25519.pub username@server:/tmp/

# Auf dem Server:
cat /tmp/id_ed25519.pub >> ~/.ssh/authorized_keys
rm /tmp/id_ed25519.pub

SSH-Config: Mehrere Server elegant verwalten

Wer regelmässig auf mehrere Server zugreift, kennt das: Verschiedene Ports, verschiedene Keys, verschiedene Usernamen – das tippt man nicht jedes Mal neu. Die Lösung ist die ~/.ssh/config-Datei.

# ~/.ssh/config

# Webserver im Firmennetz
Host webserver
    HostName 192.168.1.50
    User seya
    IdentityFile ~/.ssh/id_ed25519
    Port 22

# Externer Server mit geändertem Port
Host extern-server
    HostName server.firma.ch
    User admin
    IdentityFile ~/.ssh/id_ed25519
    Port 2222

# GitHub (für Git-Operationen)
Host github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_github
    IdentitiesOnly yes

# Wildcard für interne Server: alle Hosts im 192.168.x.x-Bereich
Host 192.168.*
    User seya
    IdentityFile ~/.ssh/id_ed25519
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Mit dieser Konfiguration reicht dann ein kurzes:

ssh webserver
ssh extern-server
git clone github:firma/repo

Nützliche Config-Optionen im Überblick:

SSH-Agent: Passphrase nur einmal eingeben

Wenn dein privater Schlüssel mit einer Passphrase geschützt ist, musst du sie bei jeder SSH-Verbindung eingeben. Der ssh-agent speichert den entschlüsselten Schlüssel im Speicher, sodass du die Passphrase nur einmal pro Session eingeben musst.

# Agent starten (falls nicht automatisch aktiv)
eval "$(ssh-agent -s)"

# Schlüssel hinzufügen (fragt nach Passphrase)
ssh-add ~/.ssh/id_ed25519

# Geladene Schlüssel anzeigen
ssh-add -l

# Schlüssel aus Agent entfernen
ssh-add -d ~/.ssh/id_ed25519

# Alle Schlüssel entfernen (z.B. beim Ausloggen)
ssh-add -D

Auf modernen Linux-Systemen mit GNOME oder KDE ist der SSH-Agent meist automatisch aktiv und fragt die Passphrase beim ersten Mal per grafischem Dialog.

SSH-Server absichern

Wenn du einen SSH-Server betreibst, ist Absicherung Pflicht. Die Konfiguration liegt in /etc/ssh/sshd_config.

# /etc/ssh/sshd_config – wichtige Sicherheitseinstellungen

# Root-Login direkt verbieten
PermitRootLogin no

# Passwort-Authentifizierung deaktivieren (nur Schlüssel!)
PasswordAuthentication no

# Leere Passwörter verbieten
PermitEmptyPasswords no

# Nur bestimmte User erlauben
AllowUsers seya admin backup-user

# Maximale Login-Versuche pro Verbindung
MaxAuthTries 3

# Maximale gleichzeitige unauthentifizierte Verbindungen
MaxStartups 10:30:60

# Timeout für inaktive Verbindungen (Sekunden)
ClientAliveInterval 300
ClientAliveCountMax 2

# SSH-Version einschränken (nur SSHv2)
Protocol 2

# Algorithmen einschränken (optional, für hochsichere Umgebungen)
KexAlgorithms curve25519-sha256,diffie-hellman-group14-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256,hmac-sha2-512

# Port ändern (reduziert automatisiertes Scanning, kein echter Sicherheitsgewinn)
# Port 2222

Nach jeder Änderung an sshd_config:

# Konfiguration auf Fehler prüfen (wichtig – nie blind neuladen!)
sshd -t

# Dienst neu laden (keine bestehenden Verbindungen unterbrechen)
systemctl reload sshd

# Status prüfen
systemctl status sshd

SSH-Tunnel: Port-Forwarding

SSH kann mehr als nur Shell-Zugriff: Mit Tunneling lassen sich Ports weiterleiten und Verbindungen durch SSH-Verbindungen routen.

Lokaler Port-Forward

Du erreichst einen Dienst auf dem Zielserver über einen lokalen Port:

# ssh -L [lokaler-port]:[ziel-host]:[ziel-port] [ssh-server]

# Zugriff auf Webserver hinter Firewall
ssh -L 8080:localhost:80 seya@server.firma.ch
# → http://localhost:8080 greift auf Port 80 des Servers zu

# Datenbankzugriff auf Remote-Server
ssh -L 5432:localhost:5432 seya@db-server.firma.ch
# → localhost:5432 verbindet sich mit PostgreSQL auf dem Server

# Zugriff auf internes System über Jump-Server
ssh -L 3389:192.168.1.20:3389 seya@jump.firma.ch
# → RDP zu localhost:3389 → über Jump-Server → PC mit IP 192.168.1.20

Remote Port-Forward

Ein Port auf dem Remote-Server wird auf deinen lokalen Rechner weitergeleitet:

# ssh -R [remote-port]:[lokal-host]:[lokal-port] [ssh-server]

# Dein lokaler Webserver auf Port 3000 wird auf dem Server öffentlich erreichbar
ssh -R 9090:localhost:3000 seya@server.firma.ch
# → Anfragen an server.firma.ch:9090 kommen auf deinen localhost:3000

Tunnel im Hintergrund

# -N = keine Shell starten, -f = in Hintergrund gehen
ssh -N -f -L 8080:localhost:80 seya@server.firma.ch

SSH unter Windows

Seit Windows 10/11 ist OpenSSH als optionales Feature dabei und funktioniert gleich wie auf Linux.

# OpenSSH-Client installieren (falls nicht vorhanden)
Get-WindowsCapability -Online -Name OpenSSH*
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

# SSH-Schlüssel generieren (im PowerShell-Terminal)
ssh-keygen -t ed25519 -C "seya@firma.ch"
# Schlüssel landen in C:\Users\seya\.ssh\

# SSH-Agent als Dienst aktivieren
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Die ~/.ssh/config-Datei funktioniert unter Windows genauso, der Pfad ist C:\Users\seya\.ssh\config.

PuTTY als Alternative: Wer PuTTY nutzt, braucht puttygen.exe zur Schlüsselerzeugung. Das Format ist proprietär (.ppk) – für OpenSSH muss der Schlüssel exportiert werden. Neuen Windows-Projekten empfehle ich OpenSSH direkt statt PuTTY.

Troubleshooting: Häufige SSH-Probleme

# Detaillierte Debug-Ausgabe – dein bester Freund bei SSH-Problemen
ssh -vvv username@server

# Auf dem Server: Authentifizierungslog prüfen
sudo journalctl -u sshd -f
sudo tail -f /var/log/auth.log   # Debian/Ubuntu
sudo tail -f /var/log/secure     # RHEL/CentOS

SSH-Schlüssel rotieren

SSH-Schlüssel sollten regelmässig erneuert werden (Empfehlung: einmal jährlich oder bei Verdacht auf Kompromittierung). So gehst du vor:

# 1. Neues Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -C "seya@firma.ch-2026" -f ~/.ssh/id_ed25519_2026

# 2. Neuen Public Key auf allen Servern hinterlegen
ssh-copy-id -i ~/.ssh/id_ed25519_2026.pub seya@server1.firma.ch
ssh-copy-id -i ~/.ssh/id_ed25519_2026.pub seya@server2.firma.ch

# 3. Verbindung mit neuem Schlüssel testen
ssh -i ~/.ssh/id_ed25519_2026 seya@server1.firma.ch

# 4. Alten Schlüssel aus authorized_keys entfernen (auf jedem Server)
# authorized_keys öffnen und die Zeile mit dem alten Schlüssel löschen

Weiterlernen

• OpenSSH Dokumentation – man.openbsd.org
• sshd_config Referenz – man.openbsd.org
• Key-Based Authentifizierung in OpenSSH für Windows – Microsoft Learn
• SSH Hardening Best Practices – Linuxize
• NIST IR 7966: Security of Interactive and Automated Access Management Using SSH – nist.gov

Verwandte Themen: Linux-Grundbefehle · VPN-Grundlagen · RDP-Grundlagen · IT-Security Grundlagen KMU

Videos

YouTube