SSH - Alles was du wissen musst - nicht nur für den Rasperry Pi

Zuletzt aktualisiert am 2. Mai 2026 von Lars

SSH. Hier erfährst du das wichtigste rund um den SSH-Zugang nicht nur für den Raspberry Pi.

Bestseller Nr. 1

db-tronic Raspberry Pi 5 8GB Starter Set | 128GB Edition | Netzteil 27W...

234,99 EUR

Bestseller Nr. 2

db-tronic Raspberry Pi 4 4GB Starter Set | 64GB Black Edition | Netzteil 15W...

149,99 EUR

Einrichten des SSH-Zugangs auf dem Raspberry Pi

Die Einrichtung erfolgt hier am einfachsten über das Tool raspi-config

$ sudo raspi-config

• Interface Options
• SSH
• Bestätigen

SSH-Zugang absichern

Zugriff per Benutzername und Passwort sperren

So ist der Zugang auch noch per Benutzername / Passwort möglich und anfällig für Brutforce-Attacken. Daher sollten wir den Zugang absichern. Dazu editieren wir die Datei /etc/ssh/sshd_config

$ sudo vim /etc/ssh/sshd_config

Hier die folgenden Zeilen anpassen bzw. ergänzen

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Zusätzlich noch sinnvoll...

LoginGraceTime 1m
StrictModes yes
MaxAuthTries 4
MaxSessions 4

• LoginGraceTime – Gibt an, wie lange ein Client nach Verbindungsaufbau Zeit hat, sich zu authentifizieren (Standard 2 Min.). Empfehlung: Auf 30 s – 1 min verkürzen, um Brute‑Force‑Versuche zu erschweren.

• StrictModes – Prüft, ob Dateiberechtigungen im Home‑Verzeichnis und in ~/.ssh/authorized_keys sicher sind (Standard yes). Empfehlung: Immer yes lassen – Deaktivierung reduziert die Sicherheit.

• MaxAuthTries – Maximale Anzahl fehlgeschlagener Authentifizierungsversuche pro Verbindung (Standard 6). Empfehlung: Auf 3 – 4 reduzieren, um Angriffe zu begrenzen.

• MaxSessions – Maximale gleichzeitige Sitzungen pro SSH‑Verbindung (Standard 10). Empfehlung: Standardwert beibehalten, nur bei Ressourcen‑Engpässen erhöhen oder bei striktem Hardening auf 2 – 3 senken.

Das bedeutet: Root-Login ist erlaubt nur mit SSH-Schlüsseln, nicht mit Passwort.

$ sudo systemctl restart sshd

fail2ban

Jetzt können wir noch fail2ban installieren. Das ist ein Tool, dass den Zugriff von einer IP-Adresse sperrt, wenn diese mehrmals versucht, mit ungültigem Benutzernamen und Passwort zuzugreifen.

$ sudo apt install fail2ban -y

Jetzt konfigurieren wir fail2ban noch

$ sudo vim /etc/fail2ban/jail.local

[sshd]
enabled = true
port = 22,2222
maxretry = 5
bantime = 600
findtime = 600
logpath = /var/log/auth.log
backend = auto

Die Werte kannst du nach deinen Bedürfnissen noch anpassen.

fail2ban starten

$ sudo systemctl restart fail2ban

Die log-Datei dazu /var/log/auth.log dürfte jetzt noch fehlen. Um das zu beheben, gehe so vor:

$ sudo apt update

$ sudo apt install rsyslog

$ sudo systemctl enable rsyslog

$ sudo systemctl start rsyslog

SSH-Schlüsselpaar generieren

$ ssh-keygen -o -a 100 -t ed25519

Die Parameter bedeuten:

• -o → Neues, sicheres Format für private Schlüssel (OpenSSH-Format).
• -a 100 → Anzahl der KDF-Runden (Key Derivation Function) für das Verschlüsseln des privaten Schlüssels. Erhöht Sicherheit gegen Offline-Angriffe. 100 ist Standard, kann höher gewählt werden für mehr Schutz.
• -t ed25519 → Schlüsseltyp. Hier ed25519 (schnell, klein, sicher) statt z.B. RSA.

Hiermit wird ein Schlüsselpaar in zwei Dateien generiert. Die Datei mit der Endung .pub ist der öffentliche Schlüssel.

Um die Sicherheit zu erhöhen, kann man beim Erstellen des SSH-Keys zusätzlich ein Passwort vergeben.

Zugang per SSH-Schlüsselpaar einrichten

Auf dem zu erreichenden Server muss der öffentliche Schlüssel in die Datei authorized_keys im Unterverzeichnis .ssh ergänzt werden.

Alternativ geht das auch via...

$ ssh-copy-id user@server

config anpassen

Der SSH-Client probiert mehrere Schlüssel im Verzeichnis .ssh automatisch aus, aber nicht unbegrenzt.
Standardmässig probiert ssh nur eine bestimmte Anzahl (meist 5) privater Schlüssel aus, bevor der Server die Verbindung verweigert.

Daher legt man am Besten eine config an. Sie definiert, welcher Benutzername und Schlüssel bei welcher Serververbindung benutzt wird.

Dazu legt man im Verzeichnis .ssh eine Datei config an bzw. editiert diese, falls diese schon existiert.

Aufbau (Beispiel)

Host rasp_backup
  IdentitiesOnly yes
  HostName 192.168.0.204
  User lars
  IdentityFile ~/.ssh/rasp_backup
  AddKeysToAgent yes
:
:

IdentitiesOnly yes: ...sorgt dafür, dass SSH dem Server nur den explizit per IdentityFile angegebenen Key anbietet, statt alle im Agent geladenen Keys durchzuprobieren.

AddKeysToAgent yes: ...bewirkt, dass der Key nach einmaliger Passphrase-Eingabe automatisch im ssh-agent hinterlegt wird, sodass du die Passphrase bei weiteren Verbindungen nicht erneut eingeben musst.

Was du noch ergänzen könntest

Ein paar sinnvolle Optionen, die oft fehlen:

ServerAliveInterval 60 – Sendet alle 60 Sekunden ein Keep-Alive-Paket. Verhindert, dass die Verbindung bei Inaktivität abbricht (besonders nützlich bei Raspberry Pis hinter NAT/Routern).

ServerAliveCountMax 3 – Nach 3 unbeantworteten Keep-Alives wird die Verbindung sauber beendet, statt ewig zu hängen.

Port 22 – Falls du den SSH-Port mal änderst (Sicherheitshärtung), hast du ihn direkt in der Config.

ForwardAgent no – Explizit setzen, damit nicht versehentlich dein Agent an den Remote-Host weitergereicht wird. Agent-Forwarding ist ein Sicherheitsrisiko, wenn der Remote-Host kompromittiert ist.

Wenn ich hier mit ...

$ ssh rasp-backup

... versuche eine Verbindung aufzubauen, dann wird der Host 192.168.0.204 kontaktiert und die Verbindung mit dem Private Key ~/.ssh/rasp_backup und dem User lars versucht.

In der Datei config definiert man für jeden Rechner, auf dem man sich verbinden will, die passenden Einträge

Nun sollte man mit ...

$ ssh rasp-backup

... eine Verbindung aufbauen können.

Hat man ein Password für den Schlüssel generiert, muss man das allerdings jedes Mal eingeben.

Alternative -i

Alternativ zur config-Datei kann man bei der Verbindung den Key auch mit dem Parameter -i angeben. Damit weisst man ssh an, welcher Key verwendet werden soll.

$ ssh -i ~/.ssh/rasp_backup rasp-backup

SSH-Key Passwort dauerhaft speichern

macOS

Unter macOS kannst du so das SSH-Passwort dauerhaft speichern:

$ ssh-add --apple-use-keychain ~/.ssh/rasp_backup
Enter passphrase for /Users/lars/.ssh/rasp_backup: 
Identity added: /Users/lars/.ssh/rasp_backup (lars@rasp-work)

In deiner ssh-config musst du aber die folgenden zwei Zeilen ergänzen.

   AddKeysToAgent yes
   UseKeychain yes

Linux

Um SSH-Passwörter dauerhaft unter Linux speichern zu können, kann man den SSH-Agenten verwenden.

Dazu ergänzt du zum Beispiel deine .bash_profile um die folgenden Zeilen.

# SSH-Agent
SSH_ENV="$HOME/.ssh/environment"

    function start_agent {
        echo "Initialising new SSH agent..."
        /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
        echo succeeded
        chmod 600 "${SSH_ENV}"
        . "${SSH_ENV}" > /dev/null
        /usr/bin/ssh-add;
    }

    # Source SSH settings, if applicable

    if [ -f "${SSH_ENV}" ]; then​​
        . "${SSH_ENV}" > /dev/null
        #ps ${SSH_AGENT_PID} doesn't work under cywgin
        ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
            start_agent;
        }
    else
        start_agent;
    fi

Mit

$ source ~/.bash_profile

lädst du den Inhalt der .bash_profile neu und startest hiermit auch den Agenten.

Wenn die Datei ${SSH_ENV} nicht existiert (d.h., es gibt noch keinen gespeicherten SSH-Agenten), wird die Funktion start_agent aufgerufen, um einen neuen SSH-Agenten zu starten und die Umgebungsvariablen zu speichern.

Das funktioniert aber nicht in allen Umgebungen. Alternativ kannst du in die .bashrc auch zum Beispiel schreiben:

eval $(keychain --eval --agents ssh \
  id_rasp-1        \
  id_rasp-2        \
  id_rasp-3        \
)

Die IDs musst du mit denen von dir genutzten austauschen.

Die Datei known_hosts

Die Datei known_hosts dokumentiert alle Server, mit denen du bereits eine SSH-Verbindung aufgebaut hast. Sie speichert die öffentlichen Schlüssel (Fingerprints) dieser Server, um bei zukünftigen Verbindungen sicherzustellen, dass du dich tatsächlich mit dem richtigen System verbindest – und nicht mit einem gefälschten. So schützt dich SSH vor sogenannten "Man-in-the-Middle"-Angriffen.

Du findest die Datei im versteckten Ordner ~/.ssh/ in deinem Benutzerverzeichnis auf dem Quell-System.

Die Datei authorized_keys

Die Datei authorized_keys enthält die öffentlichen Schlüssel aller Geräte oder Benutzer, die sich per SSH auf deinem (Ziel-)System anmelden dürfen. Wenn du also einem anderen Benutzer oder Gerät Zugriff auf dein System gewähren möchtest, musst du dessen öffentlichen Schlüssel in diese Datei eintragen. So wird sichergestellt, dass nur autorisierte Personen Zugriff erhalten.

Du findest die Datei im versteckten Ordner ~/.ssh/ in deinem Benutzerverzeichnis auf dem Ziel-System.

Troubleshooting

Servereintrag in der Datei known_hosts löschen

Um einen Eintrag aus der authorized_keys zu löschen, weil sich die Schlüssel zum Beispiel geändert haben, kannst du das entweder mit dem Editor deiner Wahl machen oder einfacher mit...

$ ssh-keygen -R hostname

ssh -o UserKnownHostsFile=/dev/null servername

$ ssh -o UserKnownHostsFile=/dev/null servername

bewirkt, dass SSH die known_hosts-Datei ignoriert und stattdessen /dev/null als leere Datei für die Host-Schlüsselprüfung verwendet.

Was bedeutet das konkret?

• Keine Host-Schlüsselprüfung: SSH überprüft nicht, ob der Schlüssel des Zielhosts bereits bekannt oder vertrauenswürdig ist.
• Keine Warnungen bei geänderten Host-Schlüsseln: Normalerweise warnt SSH, wenn sich der Schlüssel eines Hosts ändert (z. B. nach einer Neuinstallation). Mit dieser Option wird diese Warnung unterdrückt.
• Sicherheitsrisiko: Da keine Überprüfung stattfindet, bist du anfälliger für Man-in-the-Middle-Angriffe, weil SSH nicht mehr erkennt, ob der Host-Schlüssel manipuliert wurde.

Das kann aber nützlich sein, wenn man sich zum Beispiel auf das Rescue-System eines Systems verbindet.

Debugging

Nutze

$ ssh  -v hostname

um Debug-Informationen zu erhalten.

Falsche Berechtigungen

Für das SSH-Verzeichnis selbst darin solltest du die Rechte 700, für die Dateien im Verzeichnis 600 setzen. Bei zuvielen Rechten wird der Key in der Regel auch nicht verwendet.

Dienste über SSH tunneln

Dienste, wie zum Beispiel VNC, lassen sich über SSH tunneln. So kann ein Zugriff auch über andere Dienste erfolgen, auch wenn ein System nur über SSH erreichbar ist.

Zum Beispiel auch für VNC.

SSH‑Tunnel einrichten

Beispiel

$ ssh -L 5901:localhost:5900 <benutzer>@<ssh‑server>

-L = lokale Portweiterleitung
5901 = lokaler Port, den du später im VNC‑Client nutzt
5900 = Standard‑VNC‑Port auf dem Ziel‑Rechner (falls ein anderer verwendet wird, anpassen)
und  = Zugangsdaten zum Remote‑Host

Der Befehl öffnet eine SSH‑Session und leitet alles, was du lokal zu localhost:5901 schickst, sicher über SSH zu localhost:5900 auf dem Remote‑System weiter.

VNC‑Client verbinden

Starte deinen VNC‑Viewer (z. B. vinagre, remmina oder tigervnc) und verbinde zu:

localhost:5901

Der Client "denkt", er greift auf einen lokalen VNC‑Server zu, die Daten werden jedoch verschlüsselt durch den SSH‑Tunnel transportiert.

Optional: Hintergrund‑Tunnel

Wenn du die SSH‑Session nicht offen halten willst, kannst du sie in den Hintergrund schicken:

$ ssh -f -N -L 5901:localhost:5900 @

-f = nach Authentifizierung in den Hintergrund gehen
-N = keine Remote‑Kommandos ausführen (nur Tunnel)

Beenden des Tunnels

Finde die entsprechende SSH‑Prozess‑ID und kill sie, z. B.:

$ ps aux | grep "ssh -L 5901"
$ kill <id>

Zeit gespart? Dann unterstütze doch it-zeugs.de

Wenn dieser Tipp dir geholfen hat, Zeit zu sparen, überlege bitte, eine kleine Spende zu hinterlassen. Dein Beitrag hilft mir, weiterhin wertvolle Inhalte zu erstellen. Du kannst unter diesem Linke spenden: Spende it-zeugs.de

Falld du nicht spenden willst oder kannst, dann wäre es toll, wenn du deinen nächsten Amazon Einkauf mit diesem Link beginnen würdest: Amazon Link. Für dich wird es nicht teurer, ich bekomme aber einen kleinen Beitrag.

Vielen herzlichen Dank ❤️

Lars

Hallo, hier schreibt Lars. Dipl-Ing. Ingenieurinformatik (FH). Seit Jahrzehnten in der IT tätig. Geprüfter (und begeisterter) Webmaster. Ebenso begeisterter Windows-, Apple-, und Office-User. Ich schreibe über alle möglichen Themen rund um IT. Mehr über mich erfährst du hier: Über mich. Danke für deinen Besuch!