SSH für Einsteiger — Verbindung zu Raspberry Pi, NAS und Server
SSH steht fuer Secure Shell und ist das Standardwerkzeug, um sich verschluesselt und sicher auf einen entfernten Rechner einzuloggen. Ob Raspberry Pi im Heimnetz, NAS von Synology oder QNAP, ein gemieteter VPS in der Cloud oder der Rechner eines Bekannten — SSH verbindet dich mit einem einzelnen Befehl. Der gesamte Datenverkehr ist mit modernen Verfahren verschluesselt, Passwoerter wandern nie im Klartext ueber das Netz. Dieser Artikel zeigt dir alles, was du fuer den Einstieg brauchst: erste Verbindung, SSH-Schluessel einrichten, Konfiguration fuer mehrere Hosts und Dateitransfer.
Was ist SSH und wozu brauchst du es?
SSH (Secure Shell) ist ein Netzwerkprotokoll, das 1995 als sicherer Ersatz fuer Telnet entwickelt wurde. Als ich 2003 mit Linux angefangen habe, war Telnet noch hier und da im Einsatz. Unverschluesselt. Passwoerter im Klartext ueber das Netz. SSH hat das ein fuer alle Mal erledigt. Telnet uebertraegt alles — auch Passwoerter — im Klartext. SSH verschluesselt die gesamte Verbindung mit asymmetrischer Kryptografie: Beide Seiten einigen sich auf einen Sitzungsschluessel, ohne dass ein Angreifer, der den Datenverkehr mitschneidet, diesen Schluessel berechnen kann. Der Standardport ist 22.
SSH kann drei Dinge, die du im Alltag regelmaessig brauchst:
- Remote-Shell: Du arbeitest auf dem entfernten System genauso wie in deinem lokalen Terminal — Befehle ausfuehren, Dateien bearbeiten, Dienste starten.
- Dateitransfer: Mit
scp,rsyncodersftpDateien hin- und herkopieren — verschluesselt und zuverlaessig. - Tunnel und Port-Forwarding: Lokale Ports auf entfernte Dienste weiterleiten, z.B. um auf ein Web-Interface zuzugreifen, das nur lokal auf dem Zielrechner erreichbar ist.
SSH ist auf praktisch jedem Linux-System vorinstalliert — sowohl der Client (ssh) als auch der Server (openssh-server, den du auf dem Zielrechner brauchst). Auf dem Raspberry Pi OS ist der SSH-Server standardmaessig deaktiviert, kann aber per raspi-config oder durch Anlegen einer leeren Datei namens ssh auf der Boot-Partition aktiviert werden.
systemctl status ssh (Debian/Ubuntu/Raspberry Pi OS) oder systemctl status sshd (Fedora, Arch). Ein grünes „active (running)“ bedeutet, der Server ist bereit.Erste Verbindung aufbauen
Die Grundsyntax ist denkbar einfach: Benutzername, dann @, dann Hostname oder IP-Adresse.
$ ssh [email protected]
Beim allerersten Verbindungsaufbau zu einem neuen Host erscheint eine Warnung:
The authenticity of host '192.168.1.50 (192.168.1.50)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZdef456GHI789jkl012MNO345pqr678STU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.50' (ED25519) to the list of known hosts.
SSH fragt, ob du dem Host vertraust — und speichert seinen Fingerprint in ~/.ssh/known_hosts. Beim naechsten Verbindungsaufbau prueft SSH, ob der Fingerprint noch stimmt. Stimmt er nicht mehr (z.B. weil der Server neu aufgesetzt wurde), wirft SSH eine Warnung und bricht ab. Das schuetzt vor Man-in-the-Middle-Angriffen.
Mit yes bestaetigen, dann kommt die Passwort-Abfrage:
[email protected]'s password:
Linux raspberrypi 6.6.31+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64
The programs included with the Debian GNU/Linux system are free software;
...
pi@raspberrypi:~ $
Du bist jetzt eingeloggt und arbeitest direkt auf dem Pi. exit oder Strg+D trennt die Verbindung.
Laeuft SSH auf einem anderen Port als 22 (z.B. viele VPS-Anbieter verwenden Port 2222 oder 22022), gibst du ihn mit -p an:
# SSH auf Port 2222:
$ ssh -p 2222 [email protected]
Willst du einen einmaligen Befehl auf dem entfernten System ausfuehren, ohne eine interaktive Shell zu oeffnen, haengst du ihn einfach hinten an:
# Festplattenbelegung auf dem Pi abfragen, dann direkt wieder trennen:
$ ssh [email protected] "df -h /"
Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 6,2G 22G 22% /
ssh-keygen -R 192.168.1.50SSH-Schluessel einrichten: sicherer als Passwort
Passwort-Authentifizierung hat zwei Nachteile: Sie ist angreifbar durch Brute-Force (Skripte probieren tausende Passwoerter pro Stunde), und sie ist umstaendlich bei automatisierten Aufgaben wie Backups oder Deployment-Scripts. SSH-Schluessel loesen beide Probleme: Die Authentifizierung basiert auf Kryptografie statt auf einem Passwort, und sie laesst sich vollstaendig automatisieren.
Das Verfahren: Du erzeugst ein Schluesselpaar — einen privaten Schluessel (bleibt auf deinem Rechner) und einen oeffentlichen Schluessel (landet auf dem Zielrechner). Beim Verbindungsaufbau beweist dein privater Schluessel, dass du der rechtmaessige Besitzer bist — ohne dass er das Netz verlaesst.
Schluesselpaar anlegen mit Ed25519 (empfohlen seit OpenSSH 6.5, 2014, kompakter und schneller als RSA bei gleicher oder besserer Sicherheit):
$ ssh-keygen -t ed25519 -C "[email protected]"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/gunter/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase): [Passphrase eingeben]
Enter same passphrase again: [Passphrase wiederholen]
Your identification has been saved in /home/gunter/.ssh/id_ed25519
Your public key has been saved in /home/gunter/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:K7mPqR3xZnVf8yT2wL9oB1cE4uA6dJ0sG5hN/iY= [email protected]
The key's randomart image is:
+--[ED25519 256]--+
| . . |
| o o . |
...
+----[SHA256]-----+
Die Passphrase ist ein optionales zusaetzliches Passwort, das den privaten Schluessel verschluesselt. Ohne Passphrase kann jeder, der Zugriff auf deinen Rechner bekommt, den privaten Schluessel direkt nutzen. Mit Passphrase muss man beides kennen. Fuer interaktive Nutzung empfehle ich eine Passphrase und dann ssh-agent, der sie einmalig pro Sitzung abfragt.
Wenn der Zielrechner Ed25519 nicht unterstuetzt (sehr alte Systeme mit OpenSSH vor 6.5), nimm RSA mit 4096 Bit:
# RSA als Fallback fuer aeltere Systeme:
$ ssh-keygen -t rsa -b 4096 -C "[email protected]"
Oeffentlichen Schluessel auf den Zielrechner kopieren — ssh-copy-id macht das in einem Schritt:
$ ssh-copy-id [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/gunter/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)
[email protected]'s password: [einmalig Passwort eingeben]
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
ssh-copy-id haengt deinen oeffentlichen Schluessel an ~/.ssh/authorized_keys auf dem Zielrechner an und setzt die richtigen Berechtigungen. Danach loggst du dich ohne Passwort ein:
$ ssh [email protected]
Enter passphrase for key '/home/gunter/.ssh/id_ed25519': [nur wenn du Passphrase gesetzt hast]
pi@raspberrypi:~ $
Falls ssh-copy-id nicht verfuegbar ist (selten), geht es manuell:
# Oeffentlichen Schluessel anzeigen und kopieren:
$ cat ~/.ssh/id_ed25519.pub
# Auf dem Zielrechner einloggen und einfuegen:
$ ssh [email protected]
pi@raspberrypi:~ $ mkdir -p ~/.ssh && chmod 700 ~/.ssh
pi@raspberrypi:~ $ echo "HIER_DEN_PUB_KEY_EINFUEGEN" >> ~/.ssh/authorized_keys
pi@raspberrypi:~ $ chmod 600 ~/.ssh/authorized_keys
Die Berechtigungen 700 fuer ~/.ssh/ und 600 fuer authorized_keys sind nicht optional — SSH verweigert die Schluesseln-Authentifizierung, wenn die Dateiberechtigungen zu offen sind:
# Auf dem Zielrechner pruefen:
$ ls -la ~/.ssh/
drwx------ 2 pi pi 4096 Apr 18 10:00 .
-rw------- 1 pi pi 572 Apr 18 10:00 authorized_keys
ssh-agent merkt sich deine Passphrase fuer die aktuelle Sitzung. Starten mit eval "$(ssh-agent -s)", dann Schluessel hinzufuegen: ssh-add ~/.ssh/id_ed25519. Danach fragt SSH in dieser Sitzung nicht mehr nach der Passphrase.SSH-Config: mehrere Hosts komfortabel verwalten
Wenn du regelmaessig mehrere Hosts nutzt — Pi, NAS, VPS, Arbeitsserver — wird es muehsam, jedes Mal IP-Adresse, Port und Benutzernamen einzutippen. Die Datei ~/.ssh/config loest das: Du definierst Aliase fuer jeden Host und tippst danach nur noch ssh pi statt ssh -p 22 [email protected]. Meine SSH-Config hat mittlerweile 15 Eintraege. Ohne die Datei waere ich aufgeschmissen — kein Mensch merkt sich IP-Adressen und Port-Nummern fuer ein Dutzend Rechner.
# ~/.ssh/config anlegen oder bearbeiten:
$ mkdir -p ~/.ssh && chmod 700 ~/.ssh
$ nano ~/.ssh/config
Inhalt der Config:
# Raspberry Pi im Heimnetz
Host pi
HostName 192.168.1.50
User pi
IdentityFile ~/.ssh/id_ed25519
# Synology NAS (SSH auf Port 22)
Host nas
HostName 192.168.1.100
User gunter
IdentityFile ~/.ssh/id_ed25519
# VPS / Root-Server
Host vps
HostName meinserver.de
User root
Port 2222
IdentityFile ~/.ssh/id_ed25519
# Globale Einstellungen fuer alle Hosts
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
AddKeysToAgent yes
Jetzt reicht ein kurzes Alias:
$ ssh pi
pi@raspberrypi:~ $
$ ssh nas
gunter@DiskStation:~$
$ ssh vps
root@v123456:~#
Die wichtigsten Config-Direktiven im Ueberblick:
Host: Der Alias, den du in der Kommandozeile verwendest.HostName: Die echte IP-Adresse oder der Domain-Name.User: Der Benutzername auf dem Zielrechner.Port: SSH-Port, wenn nicht 22.IdentityFile: Pfad zum privaten Schluessel.ServerAliveInterval 60: Sendet alle 60 Sekunden ein Keep-Alive-Signal — verhindert, dass Verbindungen durch Router-Timeouts stumm sterben.AddKeysToAgent yes: Schluessel automatisch zum ssh-agent hinzufuegen, wenn sie das erste Mal verwendet werden.
Die Config-Datei darf keine zu offenen Berechtigungen haben:
$ chmod 600 ~/.ssh/config
ssh p und druecke Tab — dein System ergaenzt pi, wenn es der einzige Eintrag ist der mit „p“ beginnt. Das setzt eine Shell-Completion fuer SSH voraus, die auf den meisten Systemen standardmaessig aktiv ist.Dateien uebertragen: scp, sftp und rsync
SSH bringt drei Werkzeuge fuer den Dateitransfer mit — jedes hat seinen sinnvollen Einsatzbereich.
scp — schnelle Einzelkopie
scp (Secure Copy) funktioniert wie cp, aber ueber SSH. Syntax: Quelle und Ziel, wobei Remote-Adressen im Format alias:/pfad oder user@host:/pfad angegeben werden.
# Datei vom lokalen Rechner auf den Pi kopieren:
$ scp dokument.pdf pi:/home/pi/Dokumente/
# Datei vom Pi zum lokalen Rechner holen:
$ scp pi:/home/pi/logs/system.log ~/Downloads/
# Ganzen Ordner rekursiv kopieren (-r):
$ scp -r ~/Projekte/webseite pi:/var/www/html/
Fuer einmalige Kopieraufgaben ist scp schnell und unkompliziert. Fuer alles, was regelmaessig laeuft oder groessere Datenmengen betrifft, ist rsync die bessere Wahl.
rsync ueber SSH — inkrementell und zuverlaessig
rsync uebertraegt standardmaessig ueber SSH, wenn du ein Remote-Ziel angibst. Der Vorteil: rsync kopiert nur Dateien, die sich seit dem letzten Lauf geaendert haben — das macht es erheblich schneller bei wiederholten Uebertragungen.
# Home-Verzeichnis auf NAS sichern (inkrementell, komprimiert):
$ rsync -avzh --progress [email protected]:/home/pi/ ~/backup-pi/
# Mit SSH-Config-Alias:
$ rsync -avzh --progress pi:/home/pi/ ~/backup-pi/
Ausfuehrliche Erklaerung zu rsync-Flags, Excludes und automatisierten Backup-Scripts findest du im Artikel Backups mit rsync.
sftp — interaktiv und fuer FTP-Gewohnte
sftp (SSH File Transfer Protocol) bietet eine interaktive Sitzung mit FTP-aehnlichen Befehlen. Nuetzlich, wenn du nicht weisst, welche Dateien du brauchst und erst auf dem entfernten System stoeberst.
$ sftp nas
Connected to nas.
sftp> ls
Backups Dokumente Musik Videos
sftp> cd Dokumente
sftp> get steuern-2025.pdf
Fetching /volume1/homes/gunter/Dokumente/steuern-2025.pdf to steuern-2025.pdf
sftp> put bericht.pdf
Uploading bericht.pdf to /volume1/homes/gunter/Dokumente/bericht.pdf
sftp> exit
sftp-Befehle: ls (Verzeichnis auflisten), cd (Verzeichnis wechseln), get (herunterladen), put (hochladen), mkdir (Ordner anlegen), exit (beenden). Mit lls und lcd operierst du auf dem lokalen Dateisystem.
Praxisszenarien: Pi, NAS und VPS
Raspberry Pi einrichten
SSH auf dem Raspberry Pi aktivieren: Entweder in raspi-config unter „Interface Options → SSH“, oder durch Anlegen einer leeren Datei namens ssh (ohne Endung) auf der Boot-Partition. Letzteres funktioniert, bevor der Pi je gestartet wurde — praktisch fuer headlose Setups ohne Monitor.
# SSH auf dem Pi aktivieren (per raspi-config):
$ sudo raspi-config
# → Interface Options → SSH → Enable
# Oder: Boot-Partition mounten und Datei anlegen:
$ touch /media/gunter/bootfs/ssh
# IP-Adresse des Pi herausfinden (auf dem Pi selbst):
$ hostname -I
192.168.1.50
# Oder vom Router: ARP-Tabelle abfragen:
$ arp -a | grep -i "raspberry|b8:27:eb|dc:a6:32|e4:5f:01|d8:3a:dd"
Synology oder QNAP NAS
Bei Synology aktivierst du SSH unter „Systemsteuerung → Terminal & SNMP → SSH-Dienst aktivieren“. Der Standard-Port ist 22, der Benutzer ist dein DSM-Admin-Account. Auf aelteren Synology-Geraeten laeuft noch DSM 6 mit RSA-Schluesseln; DSM 7 unterstuetzt Ed25519 vollstaendig.
Bei QNAP: „Systemsteuerung → Netzwerkdienste → Telnet/SSH → SSH aktivieren“.
# Synology mit DSM 7, Benutzer admin:
$ ssh [email protected]
admin@DiskStation:~$
# Mit SSH-Config-Alias (nach config-Eintrag oben):
$ ssh nas
VPS oder Root-Server
VPS-Anbieter (Hetzner, DigitalOcean, IONOS etc.) ermöglichen meist, einen SSH-Key beim Server-Erstellen zu hinterlegen. Der erste Login ist dann passwortlos. Danach solltest du den Root-Login einschraenken und Passwort-Auth deaktivieren — dazu mehr im naechsten Abschnitt.
# Erstlogin auf frisch installierten VPS:
$ ssh [email protected]
# Neuen Benutzer anlegen und Sudo-Rechte geben:
$ adduser gunter
$ usermod -aG sudo gunter
# SSH-Key des neuen Benutzers einrichten:
$ mkdir -p /home/gunter/.ssh
$ cp /root/.ssh/authorized_keys /home/gunter/.ssh/authorized_keys
$ chown -R gunter:gunter /home/gunter/.ssh
$ chmod 700 /home/gunter/.ssh
$ chmod 600 /home/gunter/.ssh/authorized_keys
Sicherheit: Grundlegende Haertung des SSH-Servers
Standardkonfigurationen von OpenSSH sind konservativ und sicher, aber einige Einstellungen solltest du bei oeffentlich erreichbaren Servern (VPS, Port-Forwarding auf deinen Heimrouter) anpassen. Die Konfigurationsdatei liegt unter /etc/ssh/sshd_config — vor jeder Aenderung ein Backup anlegen.
# Backup der Original-Config:
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# Config bearbeiten:
$ sudo nano /etc/ssh/sshd_config
Die wichtigsten Sicherheitseinstellungen:
# Root-Login deaktivieren — niemals direkt als root einloggen:
PermitRootLogin no
# Passwort-Authentifizierung deaktivieren (nur noch SSH-Keys erlaubt):
# NUR aktivieren wenn du sicher weisst, dass dein SSH-Key funktioniert!
PasswordAuthentication no
# Leere Passwoerter verbieten (Standard, zur Sicherheit explizit setzen):
PermitEmptyPasswords no
# Maximale Anzahl Authentifizierungsversuche:
MaxAuthTries 3
# Nur bestimmte Benutzer einloggen lassen:
AllowUsers gunter pi
Nach jeder Aenderung den SSH-Daemon neu laden:
# Konfiguration pruefen (wichtig — ein Syntaxfehler sperrt dich aus!):
$ sudo sshd -t
# SSH-Dienst neu laden:
$ sudo systemctl reload ssh
fail2ban ist ein Daemon, der automatisch IP-Adressen blockiert, die zu viele fehlgeschlagene Login-Versuche produzieren. Auf oeffentlichen Servern schaut man in die SSH-Logs und sieht tausende Brute-Force-Versuche pro Tag — fail2ban stoppt das effektiv:
# fail2ban installieren (Debian/Ubuntu):
$ sudo apt install fail2ban
# Status pruefen:
$ sudo fail2ban-client status sshd
SSH-Port aendern ist eine viel diskutierte Massnahme. Der Vorteil: Automatisierte Bots, die ausschliesslich Port 22 scannen, tauchen nicht mehr in den Logs auf. Der Nachteil: Es ist „Security by Obscurity“ — wer aktiv nach SSH sucht, findet offene Ports durch einen Port-Scan in Sekunden. Wenn du den Port aenderst, musst du ihn ueberall in deiner ~/.ssh/config und in Firewall-Regeln anpassen. Auf Heimsystemen im lokalen Netz ist eine Port-Aenderung kaum sinnvoll. Auf oeffentlichen VPS kann sie in Kombination mit fail2ban die Log-Flut reduzieren.
Weiterlernen
Du kennst jetzt das Handwerkszeug fuer SSH: erste Verbindung, Schluessel einrichten, Config-Aliase, Dateitransfer und die wichtigsten Sicherheitseinstellungen. Von hier aus bauen viele weitere Konzepte auf — Backups, Scripting und der Shell-Alltag allgemein.
Prompt, .bashrc, Dateiberechtigungen und PATH — die Grundlagen die du brauchst, um dich auf einem frisch per SSH verbundenen System zurechtzufinden.
nano, vi und joe — wie du Dateien direkt auf dem entfernten System bearbeitest, ohne grafische Oberflaeche. Unverzichtbar nach dem SSH-Login.
Automatisierung beginnt mit Scripts: SSH-Befehle per Script auf mehrere Rechner ausfuehren, Backups schedulen, Deployment automatisieren.