Warum klappt mein SSH-Zugriff auf den VServer nicht mehr?

[Kaia]

Hallo zusammen,

ich hoffe, jemand von euch kann mir helfen. Ich bin ein wenig verzweifelt, weil ich nicht mehr auf meinen VServer zugreifen kann. Ich bekomme immer die Fehlermeldung: Permission denied (publickey).

Ich bin eigentlich noch recht neu in der Webentwicklung und versuche, mich mit Serveradministration vertraut zu machen. Bisher hat der SSH-Zugriff einwandfrei funktioniert, aber seit kurzem komme ich einfach nicht mehr rein. Ich habe nichts bewusst verändert, zumindest nicht, dass ich wüsste.

Meine SSH-Config sieht so aus:

Host meinserver
 HostName example.com
 User meinuser
 IdentityFile ~/.ssh/id_rsa

Ich habe versucht, den öffentlichen Schlüssel erneut auf dem Server zu platzieren, aber irgendwie scheint das nicht zu helfen. Könnte es sein, dass ich etwas übersehen habe? Oder gibt es vielleicht eine andere Lösung, die ich ausprobieren könnte?

Vielen Dank schon mal für eure Unterstützung!

Liebe Grüße,
Kaia

 

[Christian]

Hallo Kaia,

die Meldung "Permission denied (publickey)" heißt, dass dein Server deinen SSH-Schlüssel nicht akzeptiert.

Prüf doch einmal folgendes:

- Der public Key liegt noch im richtigen Verzeichnis auf dem Server
- Die Datei-Rechte sind korrekt
- Du nutzt den richtigen User bzw. Key um dich anzumelden
- Du hast auf dem Server die richtige Datei hinterlegt

Wenn du gar keinen Zugriff mehr hast bleibt dir vermutlich nur, den Support deines Anbieters zu kontaktieren bzw. ggf. über Rescue-System den Key neu zu setzen.

 

[Happy1987]

Klingt ganz klassisch nach nem SSH-Schlüssel-Problem. Hatte ich auch schon öfter – am Ende war’s meistens was Banales.

Erste Frage: Kommst du über die Konsole deines Hosting-Anbieters noch irgendwie auf die Kiste? Wenn ja, direkt mal in ~/.ssh/authorized_keys schauen, ob dein Key da überhaupt noch drinsteht. Manchmal zerschießt ein Update oder ein Skript das Ding ohne großes Tamtam.

Rechte sind auch so ein Klassiker. authorized_keys muss 600 haben, .ssh auf 700 stehen, und der User darf nicht irgendwas wie root oder so sein, der per SSH gesperrt ist. Wenn die Rechte nicht passen, wird der Key einfach still ignoriert.

Was du auch mal checken kannst: Hat sich dein Home-Verzeichnis verändert? Kam schon vor, dass ein falscher Shell-User drinstand oder das Verzeichnis nach nem Restore auf was anderes gesetzt war.

Und: Nicht automatisch davon ausgehen, dass der Key überhaupt benutzt wird. Mal mit ssh -v meinserver verbinden und schauen, ob überhaupt der richtige Key genommen wird. Manchmal wird ein anderer geladen oder gar keiner, weil IdentityFile ignoriert wird (z. B. wenn IdentitiesOnly fehlt).

Wenn du zwischendurch was an der SSHD-Config gemacht hast (z. B. PermitRootLogin oder ähnliches geändert), kann auch das reingrätschen – oder ein falscher Pfad zum Home durch nen Benutzerwechsel oder chroot. Muss man Stück für Stück durchgehen.

Kann auch an was ganz anderem liegen, aber das oben sind die häufigsten Ursachen. SSH ist da manchmal leider wie Windows: Meckert nicht, macht einfach nicht.

 

[Hayleigh01]

Könnte an den Berechtigungen liegen. .ssh sollte 700 haben, authorized_keys 600. Wenn das nicht passt, blockt der SSH-Server still.

Manchmal liegt’s auch am falschen Benutzer. Also nicht nur "meinuser" checken, sondern mal per Webinterface auf den Server gucken, ob sich da was geändert hat.

Wenn du den Key neu hochgeladen hast: bist du sicher, dass du ihn ans richtige Home-Verzeichnis gepackt hast? Hatte mal das Problem, weil ich mich als root eingeloggt hatte, aber der Key bei einem anderen User lag.

Zur Not ssh -v meinserver und schauen, was genau passiert. Das hilft meistens, um zu sehen, ob der Key überhaupt angenommen wird.

 

[FlowScript]

Hatte sowas auch mal, kurz nachdem ich was an den SSH-Keys geändert hatte - dachte erst, es lag am Server, war aber lokal.
Was du checken könntest:

• Rechte auf dem Server: ~/.ssh sollte 700 sein, authorized_keys 600.
• Ist der Key wirklich identisch mit dem, den du hochgeladen hast? Manchmal hat man mehrere Keys und der falsche wird referenziert.
• Falls du ssh-agent nutzt: mal mit ssh-add -l prüfen, ob der Key wirklich geladen ist.
• Mit ssh -v meinserver siehst du, was genau beim Verbindungsaufbau passiert. Das hilft meistens beim Eingrenzen.

Falls du Webzugriff auf den Server hast: dort direkt schauen, ob der Key überhaupt in authorized_keys drinsteht. Hatte mal den Fall, dass ein Restore das überschrieben hat, ohne Hinweis.

 

[Quassnoi]

Das geschilderte Verhalten könnte auf einen automatischen Sicherheitsmechanismus oder einen Host-Authentifizierungskonflikt hindeuten - nicht zwingend auf einen Fehler in der Schlüsselkonfiguration selbst.

Ein häufiger, aber oft übersehener Grund ist z. B. eine Sperre durch Dienste wie Fail2Ban. Wenn mehrfach ungültige SSH-Versuche erkannt werden, kann die eigene IP-Adresse temporär blockiert werden – selbst dann, wenn der Schlüssel korrekt wäre. Das lässt sich durch einen Test von einer anderen Netzwerkverbindung oder per VPN verifizieren.

Auch die Datei ~/.ssh/known_hosts auf der Client-Seite kann Probleme verursachen, wenn sich der Fingerprint des Zielsystems geändert hat - etwa nach einem Neuaufsetzen oder durch einen neuen SSH-Host-Key. In solchen Fällen lehnt der Client die Verbindung mit einer Warnung ab. Ein kurzer Blick in die Terminalausgabe oder ein gezieltes Entfernen des betroffenen Eintrags mit ssh-keygen -R hostname hilft weiter.

Ein weiterer Punkt, den man nicht unterschätzen sollte, ist die korrekte Angabe des Benutzernamens. Besonders bei Servern mit mehreren Benutzerkonten oder angepasster Konfiguration (z. B. Match User oder AllowUsers in der sshd_config) kann es passieren, dass der richtige Schlüssel verwendet wird - aber für den falschen Account. In solchen Fällen wird der Verbindungsversuch abgelehnt, ohne dass der Grund sofort ersichtlich ist.

Wenn ein Konfigurationsmanagement-Tool wie Ansible, Plesk oder ein Cloud-Init-Skript im Einsatz ist, kann es auch sein, dass die SSH-Zugänge regelmäßig automatisiert überschrieben werden. Das betrifft insbesondere neu generierte Host-Keys oder den Austausch von authorized_keys-Dateien.

Sollte es sich um einen virtuellen oder Container-basierten Server handeln, lohnt sich zudem ein Blick darauf, ob die Netzwerkinfrastruktur korrekt durchgereicht wird - z.b bei NAT, Bridge-Modus oder DNS-basierten internen Routen.