Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Sicherheit & Datenschutz 13.06.2026 · 9 min Lesezeit

SSH-Keys im netcup SCP hinterlegen und bei Image-Installationen automatisch einbinden

Wer bei netcup regelmäßig Images neu aufsetzt, kennt den Frust: Nach jedem Reinstall muss der SSH-Key manuell übertragen werden. Das netcup SCP löst das elegant – du hinterlegst deinen Public-Key einmalig unter „Option > SSH Keys" und wählst ihn beim nächsten Install aus dem Dropdown.

Server-Rack mit Festplatten für Backup-Sicherung

Wer bei netcup regelmäßig Server neu aufsetzt – sei es für Tests, saubere Deployments oder nach einem Sicherheitsvorfall – kennt den Zyklus: Image installieren, per VNC oder Passwort einloggen, SSH-Key übertragen, Passwort-Login deaktivieren. Das netcup Server Control Panel (SCP) bietet eine Abkürzung: Unter „Option > SSH Keys" lässt sich ein öffentlicher SSH-Schlüssel einmalig hinterlegen. Bei jeder künftigen Image-Installation wählst du ihn im Installer-Dialog aus, und das Installationssystem trägt ihn automatisch in /root/.ssh/authorized_keys ein. Dieser Artikel zeigt den vollständigen Workflow – von der Schlüsselgenerierung über die SCP-Konfiguration bis zum abgesicherten Server ohne Passwort-Login.

Voraussetzungen

  • Aktiver netcup-Account mit mindestens einem Root-Server oder VPS
  • Zugang zum netcup SCP unter servercontrolpanel.de
  • Lokales System mit OpenSSH: unter Linux und macOS vorinstalliert; unter Windows 10/11 als eingebautes Feature verfügbar (PowerShell oder Windows Terminal)
  • Grundkenntnisse im Umgang mit dem Terminal bzw. der PowerShell
  • Ca. 15 Minuten Zeit

Schritt 1: ed25519-Schlüsselpaar lokal generieren

Der erste Schritt passiert ausschließlich auf deinem lokalen Rechner – der private Schlüssel verlässt ihn dabei nie. Öffne ein Terminal (Linux/macOS) oder die PowerShell (Windows) und führe folgenden Befehl aus:

# Ed25519-Schlüsselpaar generieren
ssh-keygen -t ed25519 -C "mein-netcup-server"

# Standardpfad bestätigen:
#   Linux/macOS: ~/.ssh/id_ed25519
#   Windows:     C:\Users\<Nutzer>\.ssh\id_ed25519

# Passphrase setzen (dringend empfohlen – schützt den Schlüssel bei Geräteverlust)

Das Tool legt zwei Dateien an: id_ed25519 (privater Schlüssel, niemals weitergeben) und id_ed25519.pub (öffentlicher Schlüssel, dieser kommt ins SCP).

Zeige den Inhalt der Public-Key-Datei an – diesen Text benötigst du im nächsten Schritt:

# Linux/macOS
cat ~/.ssh/id_ed25519.pub

# Windows PowerShell
type $env:USERPROFILE\.ssh\id_ed25519.pub

Die Ausgabe sieht in etwa so aus:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGx... mein-netcup-server

Wichtig: Kopiere die gesamte Zeile – sie muss als eine einzige Zeile ohne Zeilenumbruch in das SCP eingefügt werden. Zeilenumbrüche beim Kopieren aus manchen Texteditoren machen den Key ungültig.

Verifizieren: Die Dateien id_ed25519 und id_ed25519.pub existieren im .ssh-Verzeichnis. Der Public-Key beginnt mit ssh-ed25519, gefolgt von einem langen Base64-String.

Schritt 2: Public Key im netcup SCP hinterlegen

Logge dich unter servercontrolpanel.de ein. Der SSH-Key-Bereich ist kontoweit – du musst den Key nur einmal hinterlegen, er steht dann für alle deine Server zur Verfügung.

  1. Klicke oben rechts auf Option (oder den gleichnamigen Menüpunkt in der Navigation)
  2. Wähle im Untermenü SSH Keys
  3. Klicke auf Create a SSH Key
  4. Füge den vollständigen Inhalt deiner .pub-Datei in das Textfeld ein
  5. Vergib einen sprechenden Namen (z. B. „Laptop-2026" oder „Büro-Desktop") – das hilft, wenn du später mehrere Keys verwaltest
  6. Speichere mit Save

Das SCP zeigt dir nach dem Speichern den Fingerprint des Keys an – dieser dient später zur Verifizierung. Du kannst beliebig viele Keys hinterlegen, etwa einen pro Gerät oder pro Mitarbeiter. Beim Löschen eines Keys aus dem SCP sind bereits installierte Server nicht betroffen; der Key bleibt in deren authorized_keys, bis du ihn dort manuell entfernst.

Verifizieren: In der SSH-Keys-Liste im SCP erscheint dein Key mit Name und Fingerprint. Das Format des Fingerprints lautet z. B. SHA256:abc123....

Schritt 3: Image installieren und Key automatisch einbinden

Jetzt kommt der zentrale Vorteil: Bei jeder Image-Neuinstallation wählst du deinen hinterlegten Key aus einem Dropdown aus, und das netcup-Installationssystem übernimmt den Rest.

  1. Navigiere im SCP zu deinem Server
  2. Öffne den Tab Media
  3. Klicke auf Images
  4. Wähle dein gewünschtes Betriebssystem-Image (z. B. Debian 12 oder Ubuntu 24.04)
  5. Im Installations-Dialog erscheint ein Dropdown SSH Key – wähle den vorhin hinterlegten Key aus
  6. Starte die Installation

Nach Abschluss der Installation hat das netcup-Installationssystem den ausgewählten Public Key automatisch in /root/.ssh/authorized_keys auf dem neuen Server eingetragen. Du kannst dich sofort per Key einloggen – kein ssh-copy-id, kein VNC-Umweg.

Wichtig: Der Key muss aktiv im Installations-Dialog ausgewählt werden. Auch wenn er im SCP gespeichert ist, wird er nur eingebunden, wenn du ihn im Dropdown auswählst. Diesen Schritt zu vergessen ist der häufigste Fallstrick.

Verifizieren: Teste den SSH-Zugang unmittelbar nach der Installation:

ssh -i ~/.ssh/id_ed25519 root@DEINE-SERVER-IP

Du solltest ohne Passwortabfrage eingeloggt werden. Erscheint eine Passwortabfrage, ist etwas beim Key-Einbinden schiefgelaufen – siehe Abschnitt „Troubleshooting".

Schritt 4: Passwort-Login auf dem Server deaktivieren

Erst wenn der Key-Login einwandfrei funktioniert, deaktivierst du den Passwort-Login. Diese Reihenfolge ist entscheidend – wer sich vorher aussperrt, muss über die VNC-Konsole im SCP eingreifen.

Öffne eine zweite SSH-Session im Hintergrund, bevor du die sshd_config änderst. So bist du abgesichert, falls etwas schiefläuft.

# sshd_config bearbeiten
sudo nano /etc/ssh/sshd_config

Setze oder ändere folgende Zeilen:

PubkeyAuthentication yes
PasswordAuthentication no

# Optional: Root-Login nur noch per Key erlauben (Passwort-Root blockieren)
PermitRootLogin prohibit-password

Starte den SSH-Dienst neu, damit die Änderungen wirksam werden:

# Aktuelle Systeme (Debian 12, Ubuntu 22.04+)
sudo systemctl restart ssh

# Ältere Systeme (falls der Dienst 'sshd' heißt)
sudo systemctl restart sshd

Verifizieren: Öffne ein neues Terminal und versuche, dich mit Passwort anzumelden:

ssh -o PubkeyAuthentication=no root@DEINE-SERVER-IP

Die Verbindung muss mit Permission denied (publickey) abgelehnt werden. Anschließend prüfst du, ob der Key-Login weiterhin funktioniert – er sollte problemlos klappen.

Schritt 5: Dateiberechtigungen prüfen (falls Key manuell kopiert wurde)

Wenn du den Key nicht über den SCP-Installer eingebunden hast, sondern manuell in authorized_keys eingetragen hast, müssen die Berechtigungen exakt stimmen. OpenSSH ignoriert Keys bei falschen Permissions kommentarlos – der Key-Login schlägt dann still fehl.

# Berechtigungen für .ssh-Verzeichnis und authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Besitzer prüfen (muss root sein, wenn als root eingeloggt)
ls -la ~/.ssh/

Verifizieren: Die Ausgabe von ls -la ~/.ssh/ zeigt drwx------ für das Verzeichnis und -rw------- für authorized_keys.

SSH-Key-Typen im Vergleich

Key-TypBefehlSchlüssellängeSicherheitsniveauEmpfehlung
ed25519ssh-keygen -t ed25519256 Bit (Elliptic Curve)Sehr hochEmpfohlen (netcup)
RSAssh-keygen -t rsa -b 40964096 BitHochAlternativ, breite Kompatibilität
RSA (veraltet)ssh-keygen -t rsa -b 20482048 BitMittelNicht mehr empfohlen
ECDSAssh-keygen -t ecdsa -b 521521 BitHochMöglich, selten genutzt
DSA1024 BitSchwachNicht verwenden (veraltet)

Workflow-Vergleich: Mit und ohne SCP-SSH-Key-Feature

SchrittOhne SCP-Key-HinterlegungMit SCP-Key-Hinterlegung
Key generierenEinmalig lokalEinmalig lokal
Key im SCP hinterlegenNicht nötigEinmalig unter „Option > SSH Keys"
Image installierenNormalNormal, Key im Dropdown auswählen
Key auf Server kopierenJedes Mal: ssh-copy-id oder VNCEntfällt – automatisch in authorized_keys
Passwort-Login deaktivierenManuell nach jeder InstallationManuell nach jeder Installation
Aufwand bei ReinstallMittelGering (Key-Auswahl im Installer reicht)

Troubleshooting / Typische Fehler

SSH-Verbindung fragt trotzdem nach Passwort

Ursachen: Der Key wurde im SCP gespeichert, aber bei der Installation nicht im Dropdown ausgewählt. Prüfe mit cat /root/.ssh/authorized_keys auf dem Server, ob der Key vorhanden ist. Wenn nicht, kopiere ihn manuell oder spiele das Image mit aktivem Key-Dropdown neu auf.

Permission denied (publickey) – Key ist vorhanden, aber Login schlägt fehl

Wahrscheinlichste Ursache: Falsche Dateiberechtigungen. Führe auf dem Server aus:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

Zweite Ursache: Der Key-Inhalt enthält einen Zeilenumbruch. Öffne authorized_keys mit nano und stelle sicher, dass der Key als eine einzige Zeile eingetragen ist.

Vom Server ausgesperrt nach Deaktivieren des Passwort-Logins

Öffne im netcup SCP die Screen-Funktion (VNC-Konsole) deines Servers. Du bekommst direkten Konsolenzugang ohne SSH. Dort kannst du die sshd_config korrigieren oder einen neuen Key eintragen.

Key-Passphrase vergessen

Der private Schlüssel ist dann nicht mehr verwendbar. Erzeuge ein neues Schlüsselpaar, hinterlege den neuen Public Key im SCP und trage ihn manuell (via VNC-Konsole) in authorized_keys ein. Den alten Key im SCP und auf dem Server aus authorized_keys entfernen.

PermitRootLogin no gesetzt, ohne Nicht-Root-User eingerichtet zu haben

Das führt zur vollständigen Aussperrung. Lösung: VNC-Konsole im SCP nutzen, PermitRootLogin temporär auf prohibit-password zurücksetzen, einen sudo-Benutzer anlegen, dann erneut härten.

Windows-Pfad: Falscher Public-Key-Inhalt kopiert

Unter Windows liegt der Key in C:\Users\<Nutzer>\.ssh\id_ed25519.pub. Beim Anzeigen mit type in der PowerShell keinen Zeilenumbruch am Ende mitkopieren. Im Zweifel den Key mit einem Texteditor öffnen und den Inhalt von dort kopieren.

Häufige Fragen

Muss ich den SSH-Key bei jedem Reinstall neu im SCP hinterlegen?

Nein. Der Key wird einmalig unter „Option > SSH Keys" gespeichert und steht dauerhaft für alle künftigen Image-Installationen zur Verfügung. Du wählst ihn bei jeder Installation lediglich im Dropdown aus.

Kann ich mehrere SSH-Keys im SCP hinterlegen?

Ja. Das netcup SCP erlaubt das Hinterlegen mehrerer öffentlicher Keys – praktisch etwa für Laptop und Desktop oder verschiedene Mitarbeiter. Bei der Installation können mehrere Keys ausgewählt werden; alle landen in authorized_keys.

Was passiert, wenn ich einen Key im SCP lösche?

Der Key wird aus dem SCP-Verwaltungsbereich entfernt und steht bei künftigen Installationen nicht mehr zur Auswahl. Bereits installierte Server sind davon nicht betroffen – der Key bleibt in deren authorized_keys, bis du ihn dort manuell entfernst.

Funktioniert das SSH-Key-Feature mit allen netcup-Images?

Ja, für alle offiziellen netcup-Images, die über den Media-Tab installiert werden (Debian, Ubuntu, CentOS, Rocky Linux usw.). Bei eigenen Custom-Images muss der Key manuell eingerichtet werden.

Wie logge ich mich ein, wenn ich meinen privaten Schlüssel verloren habe?

Über die VNC-Konsole (Funktion „Screen") im netcup SCP kannst du direkt auf den Server zugreifen. Dort legst du ein neues Schlüsselpaar an, trägst den neuen Public Key in authorized_keys ein und hinterlegst ihn anschließend im SCP. Den alten Key löschst du aus SCP und authorized_keys.

Lohnt sich eine Passphrase für den privaten Schlüssel?

Unbedingt – besonders auf Laptops. Die Passphrase verschlüsselt den privaten Schlüssel lokal; ein Angreifer, der an deine Schlüsseldatei gelangt, kann sie ohne Passphrase nicht nutzen. Der Komfortverlust lässt sich mit ssh-agent und ssh-add auf ein Minimum reduzieren: Die Passphrase wird einmalig pro Session abgefragt.

Fazit

Das SSH-Key-Feature im netcup SCP ist einer jener kleinen Workflow-Beschleuniger, die im Alltag viel Zeit sparen – besonders wenn du häufig Images neu aufsetzt oder mehrere Server verwaltest. Einmal eingerichtet, entfällt ssh-copy-id dauerhaft. In Kombination mit einem deaktivierten Passwort-Login und PermitRootLogin prohibit-password erreichst du ein solides Grundniveau an SSH-Sicherheit ohne nennenswerten Mehraufwand. Für tiefergehende SSH-Härtung – etwa mit Match-Blöcken, Rate-Limiting und ssh-audit – empfiehlt sich ein Blick in den SSH-Hardening Deep-Dive.

Weiterführende Anleitungen und Quellen