Sonstige SSH-Zugriff ohne Passwort einrichten

[prisrak]

SSH-Zugriff ohne Passwort einrichten (Login per SSH-Key)

Wenn du regelmäßig mit Servern, VPS oder Cloud-Systemen arbeitest, lohnt sich SSH-Zugriff per Schlüssel. Nach einmaliger Einrichtung kannst du dich anmelden, ohne jedes Mal ein Passwort einzugeben. Das ist schneller, sicherer und ideal für Automatisierung.

Warum SSH-Keys verwenden

• Kein ständiges Tippen von Passwörtern
• Deutlich sicherer als Passwort-Login
• Perfekt für Skripte, Deployments und Backups
• Standard in professionellen Linux-Umgebungen

Was ist SSH-Zugriff per Schlüssel

Statt eines Passworts nutzt SSH ein Schlüsselpaar:

• Privater Schlüssel liegt auf deinem Rechner
• Öffentlicher Schlüssel liegt auf dem Server
• Beim Verbinden wird geprüft, ob beide zusammenpassen

Stimmt der Schlüssel, wirst du automatisch eingeloggt.

Voraussetzungen

• Linux oder macOS (unter Windows z.B. mit OpenSSH oder WSL)
• SSH-Zugriff auf den Server
• Benutzerkonto auf dem Server

Schritt 1: SSH-Schlüssel erzeugen

Auf deinem lokalen Rechner:

ssh-keygen -t rsa -b 4096

Erklärung:

• rsa ist der Schlüsseltyp
• 4096 ist die Schlüssellänge (sehr sicher)

Du kannst den Speicherort bestätigen (Standard ist empfohlen)
Optional kannst du eine Passphrase setzen

Standardpfade:

• Privater Schlüssel: ~/.ssh/id_rsa
• Öffentlicher Schlüssel: ~/.ssh/id_rsa.pub

Schritt 2: Prüfen, ob der Schlüssel existiert

ls ~/.ssh/id_rsa.pub

Wenn die Datei angezeigt wird, war die Erstellung erfolgreich.

Schritt 3: Öffentlichen Schlüssel auf den Server kopieren

Empfohlene Methode:

ssh-copy-id benutzer@server_ip

Du gibst das Passwort ein letztes Mal ein. Danach ist es nicht mehr nötig.

Alternative ohne ssh-copy-id:

cat ~/.ssh/id_rsa.pub | ssh benutzer@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Oder:

• Inhalt von id_rsa.pub kopieren
• Auf dem Server in ~/.ssh/authorized_keys einfügen

Schritt 4: Verbindung testen

ssh benutzer@server_ip

Wenn kein Passwort abgefragt wird, ist alles korrekt eingerichtet.

Wichtige Dateirechte auf dem Server

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Falsche Rechte sind eine häufige Fehlerquelle.

Optional: Passwort-Login komplett deaktivieren

Achtung: Erst machen, wenn SSH-Key-Zugriff sicher funktioniert.

Datei öffnen:

sudo nano /etc/ssh/sshd_config

Folgende Optionen setzen oder ändern:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

SSH-Dienst neu starten:

sudo systemctl restart ssh

Ab jetzt ist ein Login nur noch per SSH-Key möglich.

Rückgängig machen

Falls nötig:

• PasswordAuthentication wieder auf yes setzen
• SSH-Dienst neu starten

Wann SSH-Keys sinnvoll sind

• Verwaltung von VPS oder Cloud-Servern
• Automatisierte Deployments oder Backups
• Arbeit mit mehreren Servern
• Generell für sichere Linux-Setups

Fazit

SSH-Keys sind ein Standardwerkzeug unter Linux. Einmal eingerichtet, sparst du Zeit, erhöhst die Sicherheit und vereinfachst deine Arbeit dauerhaft.

Einrichten, testen, fertig.

 

[DEB ChatGPT]

Dein Ablauf passt im Großen und Ganzen. Ein paar Punkte würde ich technisch sauberer bzw. zeitgemäßer formulieren, damit sich niemand später selbst ein Bein stellt:

- Besser ed25519 statt RSA
RSA 4096 ist ok, aber heutzutage ist meist das Standardrezept:

bash
  ssh-keygen -t ed25519 -a 64

Optional mit Kommentar:

bash
  ssh-keygen -t ed25519 -a 64 -C "laptop-2026-02"

- Passphrase nicht weglassen (aber komfortabel machen)
„Ohne Passwort“ heißt idealerweise: keine Server-Passwörter tippen, aber der Key hat eine Passphrase. Dann nutzt man ssh-agent/Keychain. Das ist in der Praxis der bessere Kompromiss.

- Rechte: auch das Home-Verzeichnis beachten
Nicht nur ~/.ssh und authorized_keys – wenn das Home oder .ssh group-writable ist, verweigert sshd gern den Login. Faustregel:

bash
  chmod go-w ~
  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/authorized_keys

- sshd_config: UsePAM nicht pauschal ausknipsen
PasswordAuthentication no reicht für „keine Passwörter“. UsePAM no kann Nebenwirkungen haben (2FA, Session-Setup, Logging). Eher so:

conf
  PasswordAuthentication no
  KbdInteractiveAuthentication no   # statt ChallengeResponse..., je nach Distro
  PubkeyAuthentication yes

Danach: sudo systemctl reload sshd (reload reicht meist).

- Empfehlung: Root-Login härten

conf
  PermitRootLogin no

Wenn du willst, sag kurz welche Zielumgebung (Ubuntu/Debian/CentOS, OpenSSH-Version, Windows/macOS/Linux als Client). Dann kann man die Config-Zeilen exakt passend machen.