SSH-Key erstellen und einrichten: So funktioniert SSH ohne Passwort

Ein SSH-Key ist eine sichere Art, dich mit einem Server zu verbinden. Zum Beispiel mit einem Linux-Server, einem Raspberry Pi, GitHub, GitLab oder einem Cloud-Server.

Der Vorteil: Du musst kein normales Passwort mehr eintippen. Dein Rechner weist sich mit einem digitalen Schlüssel aus.

Das klingt technischer, als es ist. Stell es dir wie ein Vorhängeschloss vor:

Du gibst dem Server ein Schloss. Den passenden Schlüssel behältst du auf deinem Rechner. Wenn du dich später verbindest, prüft der Server: „Hat dieser Rechner wirklich den passenden Schlüssel?“ Wenn ja, kommst du rein.

Genau so funktioniert ein SSH-Key.

Was ist ein SSH-Key?

Ein SSH-Key besteht immer aus zwei Teilen:

DateiBedeutungWohin damit?
id_ed25519Private KeyBleibt nur auf deinem Rechner
id_ed25519.pubPublic KeyKommt auf den Server

Der Public Key ist der öffentliche Teil. Den darfst du auf Server kopieren oder bei Diensten wie GitHub hinterlegen.

Der Private Key ist der geheime Teil. Den solltest du nie weitergeben. Keine E-Mail. Kein Chat. Kein Screenshot. Keine Cloud-Ablage ohne Schutz.

Wenn jemand deinen Private Key besitzt, kann diese Person sich möglicherweise als du ausgeben.

SSH-Key erstellen und einrichten: So funktioniert SSH ohne Passwort

Wofür braucht man SSH-Keys?

SSH-Keys brauchst du, wenn du dich sicher mit einem entfernten System verbinden möchtest.

Typische Beispiele:

  • Zugriff auf einen Linux-Server
  • Zugriff auf einen Raspberry Pi
  • Verbindung zu GitHub oder GitLab
  • Verwaltung eines Webservers
  • Anmeldung bei einem Cloud-Server
  • Automatische Deployments
  • Backups oder Skripte ohne Passwortabfrage

Kurz gesagt: SSH-Keys sind praktisch, wenn dein Rechner regelmäßig mit einem Server sprechen soll.

Wie bei einem Haustürschlüssel: Du willst nicht jedes Mal deine komplette Identität erklären. Du willst einfach mit dem richtigen Schlüssel rein.

Public Key und Private Key einfach erklärt

Der Unterschied ist wichtig:

Public Key

Der Public Key ist wie ein Schloss.

Du kannst ihn auf mehrere Server legen. Jeder Server, auf dem dein Public Key gespeichert ist, kann später prüfen, ob dein Rechner den passenden Private Key besitzt.

Beispiel-Datei:

id_ed25519.pub

Diese Datei darfst du weitergeben.


Private Key

Der Private Key ist wie dein echter Schlüssel. Er bleibt auf deinem Rechner.

Beispiel-Datei:

id_ed25519

Diese Datei darfst du niemals weitergeben. Nicht an Kollegen, auch nicht an Support-Mitarbeiter, nicht „nur kurz zum Testen“.

Wenn mehrere Personen auf einen Server sollen, bekommt jede Person ein eigenes Schlüsselpaar.

Wo liegen SSH-Keys?

Nach dem Erstellen liegen die Dateien meistens hier:

Mac und Linux (Bash)

~/.ssh/

Typische Dateien:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub
~/.ssh/config
~/.ssh/known_hosts

Windows (PowerShell)

C:\Users\DeinName\.ssh\

Typische Dateien:

C:\Users\DeinName\.ssh\id_ed25519
C:\Users\DeinName\.ssh\id_ed25519.pub
C:\Users\DeinName\.ssh\config

Was bedeutet authorized_keys?

Auf dem Server gibt es ebenfalls einen .ssh-Ordner.

Darin liegt oft diese Datei:

~/.ssh/authorized_keys

In dieser Datei stehen die Public Keys, die sich anmelden dürfen.

Jeder Public Key steht in einer eigenen Zeile.

Beispiel:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... simon@laptop
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... admin@desktop

Wenn du dich per SSH verbindest, prüft der Server diese Datei. Findet er deinen Public Key und passt dein Private Key dazu, klappt der Login.

RSA oder ed25519?

Für neue SSH-Keys ist ed25519 meist die beste Wahl.

Der Befehl sieht so aus:

ssh-keygen -t ed25519

ed25519 ist kurz, schnell und modern. RSA funktioniert ebenfalls, wird aber vor allem für ältere Systeme genutzt. Für normale Server, Raspberry Pis, GitHub, GitLab und aktuelle Linux-Systeme passt ed25519 in der Regel sehr gut.

RSA würde ich nur nutzen, wenn ein altes System ed25519 nicht unterstützt.

SSH-Key erstellen auf Mac

Öffne das Terminal und gib ein:

ssh-keygen -t ed25519

Danach fragt dich das System nach einem Speicherort.

Drücke einfach Enter, wenn du den Standard nutzen möchtest:

/Users/DeinName/.ssh/id_ed25519

Danach fragt dich das System nach einer Passphrase.

Du kannst eine Passphrase vergeben. Das ist ein Zusatzpasswort für deinen Private Key.

Empfehlung:

  • Für private Geräte: Passphrase nutzen
  • Für Testsysteme: je nach Risiko entscheiden
  • Für produktive Systeme: Passphrase oder sauberer SSH-Agent

Am Ende hast du zwei Dateien:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

SSH-Key erstellen unter Windows

Öffne PowerShell und gib ein:

ssh-keygen -t ed25519

Auch hier kannst du den vorgeschlagenen Speicherort mit Enter bestätigen.

Die Dateien liegen danach meistens hier:

C:\Users\DeinName\.ssh\id_ed25519
C:\Users\DeinName\.ssh\id_ed25519.pub

Den Public Key kannst du dir so anzeigen lassen:

type $env:USERPROFILE\.ssh\id_ed25519.pub

Diesen Inhalt kopierst du später auf den Server.

SSH-Key erstellen unter Linux

Unter Linux funktioniert es wie auf dem Mac:

ssh-keygen -t ed25519

Die Dateien landen hier:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

Den Public Key zeigst du so an:

cat ~/.ssh/id_ed25519.pub

Public Key auf den Server kopieren

Jetzt muss dein Public Key auf den Server. Dafür gibt es mehrere Wege.

Variante 1: Public Key mit ssh-copy-id kopieren

Auf Mac und Linux ist das meist der einfachste Weg:

ssh-copy-id benutzer@server-ip

Beispiel:

ssh-copy-id pi@192.168.178.50

Der Befehl macht mehrere Dinge automatisch:

  • Er verbindet sich mit dem Server.
  • Er erstellt bei Bedarf den .ssh-Ordner.
  • Er trägt deinen Public Key in authorized_keys ein.
  • Er setzt passende Berechtigungen.

Wichtig: Dafür musst du dich einmal per Passwort anmelden können.

Danach kannst du dich meist ohne Server-Passwort verbinden:

ssh benutzer@server-ip

Variante 2: Public Key manuell auf den Server kopieren

Wenn ssh-copy-id nicht verfügbar ist, kannst du den Key manuell übertragen.

Auf Mac oder Linux:

cat ~/.ssh/id_ed25519.pub

Auf Windows:

type $env:USERPROFILE\.ssh\id_ed25519.pub

Kopiere die komplette Zeile.

Sie beginnt meistens mit:

ssh-ed25519

Dann loggst du dich auf dem Server ein und öffnest oder erstellst die Datei:

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

Füge den Public Key als neue Zeile ein.

Danach setzt du die Berechtigungen:

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

Variante 3: Public Key per Pipe übertragen

Auf Mac oder Linux:

cat ~/.ssh/id_ed25519.pub | ssh benutzer@server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Auf Windows PowerShell:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh benutzer@server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Das wirkt lang, ist aber logisch:

  • links wird dein Public Key gelesen
  • rechts wird er auf dem Server in authorized_keys eingefügt
  • danach werden die Rechte gesetzt

Warum chmod 700 und chmod 600 wichtig sind

SSH ist streng bei Dateirechten.

Wenn der .ssh-Ordner oder die Datei authorized_keys zu offen gesetzt sind, kann der Server die Anmeldung verweigern.

Nutze deshalb:

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

Bedeutung:

BefehlWirkung
chmod 700 ~/.sshNur dein Benutzer darf den Ordner nutzen
chmod 600 ~/.ssh/authorized_keysNur dein Benutzer darf die Datei lesen und schreiben

Wenn hier etwas falsch ist, bekommst du oft nur:

Permission denied

Das ist frustrierend, weil die eigentliche Ursache nicht immer klar angezeigt wird.

SSH-Verbindung testen

Nach dem Kopieren des Public Keys testest du die Verbindung:

ssh benutzer@server-ip

Beispiel:

ssh pi@192.168.178.50

Beim ersten Login kann diese Meldung erscheinen:

The authenticity of host ... can't be established.

Das bedeutet: Dein Rechner kennt diesen Server noch nicht.

Wenn du sicher bist, dass die IP-Adresse stimmt, bestätigst du mit:

yes

Danach speichert dein Rechner den Server in:

~/.ssh/known_hosts

Diese Datei ist wie ein kleines Adressbuch mit Fingerabdrücken bekannter Server.

SSH-Config: Kürzere Befehle mit Alias

Wenn du dich oft mit demselben Server verbindest, lohnt sich eine SSH-Config.

Auf Mac oder Linux:

nano ~/.ssh/config

Auf Windows liegt die Datei hier:

C:\Users\DeinName\.ssh\config

Beispiel:

Host meinserver
HostName 192.168.178.50
User pi
IdentityFile ~/.ssh/id_ed25519

Danach reicht:

ssh meinserver

Statt:

ssh pi@192.168.178.50

Das spart Tipparbeit und vermeidet Fehler.

SSH-Key mit Raspberry Pi nutzen

Bei einem Raspberry Pi ist SSH besonders praktisch.

Du kannst dich damit vom Laptop aus verbinden, ohne Monitor und Tastatur am Pi zu nutzen.

Beispiel:

ssh pi@raspberrypi.local

Oder über die IP-Adresse:

ssh pi@192.168.178.50

Der Public Key muss auch hier in diese Datei:

~/.ssh/authorized_keys

Wenn du den Raspberry Pi frisch eingerichtet hast, prüfe vorher:

  • Ist SSH aktiviert?
  • Stimmt der Benutzername?
  • Stimmt die IP-Adresse?
  • Ist dein Public Key in authorized_keys eingetragen?
  • Stimmen die Berechtigungen?

Gerade bei Raspberry Pis entstehen viele Fehler durch falsche Benutzernamen, geänderte IP-Adressen oder doppelt kopierte Befehle.

Häufige Fehler bei SSH-Keys

Fehler 1: Der falsche Key wurde kopiert

Du brauchst den Inhalt der .pub-Datei.

Richtig:

id_ed25519.pub

Falsch:

id_ed25519

Die Datei ohne .pub ist dein Private Key.

Fehler 2: Der Public Key steht falsch in authorized_keys

Ein Public Key muss in einer einzigen Zeile stehen.

Er darf nicht mitten in der Zeile umbrechen.

So beginnt er meistens:

ssh-ed25519 AAAAC3...

Am Ende steht oft ein Kommentar, zum Beispiel:

deinname@laptop

Fehler 3: Die Rechte stimmen nicht

Setze auf dem Server:

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

Fehler 4: Der falsche Benutzer wird verwendet

Dieser Befehl:

ssh root@server-ip

ist nicht dasselbe wie:

ssh pi@server-ip

Jeder Benutzer hat eine eigene authorized_keys-Datei.

Der Key muss also beim richtigen Benutzer liegen.

Fehler 5: Der falsche Server wird angesprochen

Gerade im Heimnetz ändern sich IP-Adressen schnell.

Prüfe deshalb:

ping server-ip

Oder kontrolliere die IP-Adresse im Router.

Fehler 6: Der falsche Private Key wird genutzt

Wenn du mehrere SSH-Keys hast, kannst du den Key direkt angeben:

ssh -i ~/.ssh/id_ed25519 benutzer@server-ip

Oder du nutzt eine SSH Config.

Sollte man eine Passphrase nutzen?

Ja, meistens ist eine Passphrase sinnvoll. Die Passphrase schützt deinen Private Key zusätzlich.

Stell dir deinen Private Key wie einen Haustürschlüssel vor. Die Passphrase ist ein kleiner Safe um diesen Schlüssel. Wenn jemand deinen Laptop stiehlt, reicht der Key allein nicht aus. Die Person müsste zusätzlich die Passphrase kennen.

Der Nachteil: Du musst die Passphrase eingeben.

Das lässt sich mit einem SSH-Agenten komfortabler lösen. Auf dem Mac hilft zusätzlich der Schlüsselbund. Unter Windows gibt es ebenfalls einen OpenSSH Authentication Agent.

Kann ich denselben SSH-Key auf mehreren Servern nutzen?

Ja, technisch geht das.

Du kannst denselben Public Key auf mehreren Servern hinterlegen.

Besser ist aber oft:

  • ein Key für private Systeme
  • ein Key für berufliche Systeme
  • ein Key für GitHub oder GitLab
  • ein Key pro Gerät

So bleibt es übersichtlich. Wenn ein Gerät verloren geht, musst du nur den passenden Public Key von den Servern entfernen.

Was mache ich bei einem neuen Rechner?

Erstelle auf dem neuen Rechner ein neues Schlüsselpaar:

ssh-keygen -t ed25519

Dann kopierst du den neuen Public Key auf alle Server, auf die du zugreifen möchtest.

Den alten Private Key solltest du nicht einfach kopieren, außer du hast einen sehr guten Grund und schützt ihn sauber.

Was mache ich, wenn ein Gerät verloren geht?

Dann entfernst du den Public Key dieses Geräts aus der Datei:

~/.ssh/authorized_keys

Auf jedem betroffenen Server.

Danach kann sich dieses Gerät nicht mehr mit seinem alten Key anmelden.

Zusammenfassung

  • Ein SSH-Key besteht aus Public Key und Private Key.
  • Der Public Key kommt auf den Server.
  • Der Private Key bleibt auf deinem Rechner.
  • Für neue Keys ist ed25519 meist die passende Wahl.
  • Der Public Key steht auf dem Server in ~/.ssh/authorized_keys.
  • Die Rechte sollten auf 700 für .ssh und 600 für authorized_keys gesetzt sein.
  • Mit einer SSH Config kannst du dir kurze Aliase bauen.
  • Eine Passphrase schützt deinen Private Key zusätzlich.

Wenn du nur einen Befehl aus diesem Artikel brauchst, dann diesen:

ssh-keygen -t ed25519

Und wenn du nur einen Merksatz brauchst:

Public Key auf den Server. Private Key bleibt bei dir.

Häufige Fragen zu SSH-Keys

Wie erstelle ich einen SSH-Key?

Mit diesem Befehl:

ssh-keygen -t ed25519

Danach entstehen zwei Dateien: ein Private Key und ein Public Key.

Wo finde ich meinen SSH Public Key?

Auf Mac und Linux:

cat ~/.ssh/id_ed25519.pub

Auf Windows:

type $env:USERPROFILE\.ssh\id_ed25519.pub

Wo muss der Public Key auf dem Server hin?

In diese Datei:

~/.ssh/authorized_keys

Jeder erlaubte Public Key steht dort in einer eigenen Zeile.

Was ist der Unterschied zwischen Public Key und Private Key?

Der Public Key darf auf den Server. Der Private Key bleibt geheim auf deinem Rechner.

Der Server nutzt den Public Key, um zu prüfen, ob dein Rechner den passenden Private Key besitzt.

Was bedeutet Permission denied bei SSH?

Meistens liegt es an einem dieser Punkte:

  • falscher Benutzer
  • falscher Server
  • Public Key nicht in authorized_keys
  • falsche Dateirechte
  • falscher Private Key
  • SSH-Zugriff auf dem Server deaktiviert

Welcher SSH Key ist besser: RSA oder ed25519?

Für neue Schlüssel ist ed25519 meist die bessere Wahl. RSA ist vor allem für ältere Systeme relevant.

Brauche ich unter Windows PuTTY?

In vielen Fällen nicht. Auf aktuellen Windows-Systemen kannst du SSH direkt über PowerShell nutzen. Für klassische grafische SSH-Verbindungen ist PuTTY weiterhin möglich.

Kann ich SSH ohne Passwort nutzen?

Ja. Genau dafür werden SSH-Keys oft eingesetzt.

Du meldest dich dann über dein Schlüsselpaar an. Wenn dein Private Key zusätzlich mit einer Passphrase geschützt ist, musst du eventuell diese Passphrase eingeben.