Tutorials

[Gelöst!!] Vagrant SSH: Permission Denied (publickey) – Schritt-für-Schritt-Anleitung

Melden

Der Fehler vagrant@127.0.0.1: Permission denied (publickey) ist einer der häufigsten und frustrierendsten Fehler bei der Nutzung von Vagrant. Er tritt meistens auf, wenn Vagrant versucht, den standardmäßigen „unsicheren“ Schlüssel (Insecure Key) durch einen neu generierten, sicheren Schlüssel zu ersetzen, und dieser Prozess unterbrochen wird oder die Dateiberechtigungen nicht stimmen.

In diesem Tutorial gehen wir die bewährtesten Lösungen durch, um den SSH-Zugriff schnell wiederherzustellen.

Schnelldiagnose: Warum passiert das?

  1. Schlüssel-Mismatch: Vagrant erwartet einen anderen privaten Schlüssel als den, der in der VM hinterlegt ist.
  2. Falsche Dateirechte: SSH blockiert den Zugriff aus Sicherheitsgründen, wenn ~/.ssh oder authorized_keys in der VM zu offene Rechte haben.
  3. Absturz beim ersten Boot: Das automatische Austauschen des Keys (insert_key) schlug fehl.

Lösung 1: Den Standard-Schlüssel erzwingen (Häufigste Lösung)

Wenn der automatische Schlüsselaustausch fehlgeschlagen ist, kannst du Vagrant anweisen, vorübergehend den Standard-Schlüssel von HashiCorp zu verwenden.

  1. Öffne deine Vagrantfile.
  2. Füge folgende Zeile innerhalb des Konfigurationsblocks ein:
Vagrant.configure("2") do |config|
  # ... andere Konfigurationen ...

  # Deaktiviert das automatische Ersetzen des Schlüssels:
  config.ssh.insert_key = false

end
  1. Speichere die Datei und starte die VM neu mit:
    vagrant reload
vagrant ssh

    Funktioniert es wieder? Falls ja, kannst du die Zeile wieder entfernen, sobald die VM einmal sauber läuft.

Lösung 2: GUI aktivieren & Berechtigungen in der VM reparieren

Oft hat SSH in der VM den Zugriff verweigert, weil die Ordner-Rechte falsch gesetzt sind. Da SSH nicht geht, loggen wir uns über das GUI-Fenster des Hypervisors (z. B. VirtualBox) ein.

1. GUI in der Vagrantfile aktivieren:

Aktiviere das Fenster in deiner Vagrantfile:

config.vm.provider "virtualbox" do |vb|
  vb.gui = true
end

2. Neu starten und einloggen:

Führe vagrant reload aus. Es öffnet sich das VirtualBox-Fenster.

  • Benutzername: vagrant
  • Passwort: vagrant

3. SSH-Rechte und Keys reparieren:

Tippe folgende Befehle direkt in das Konsolenfenster der VM ein:

# 1. Rechte für das SSH-Verzeichnis korrigieren
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R vagrant:vagrant ~/.ssh

# 2. Den öffentlichen Vagrant-Standardschlüssel neu herunterladen (falls gelöscht)
curl -k https://raw.githubusercontent.com/hashicorp/vagrant/master/keys/vagrant.pub >> ~/.ssh/authorized_keys

# 3. SSH-Dienst neustarten (je nach Linux-Distribution)
sudo systemctl restart ssh   # oder: sudo service ssh restart

Schließe das Fenster und versuche erneut auf deinem Host-Rechner:

vagrant ssh

Lösung 3: Passwort-Authentifizierung erzwingen

Wenn Schlüssel komplett streiken, kannst du Vagrant anweisen, sich temporär per Passwort anzumelden:

  1. Trage Folgendes in deine Vagrantfile ein:
    config.ssh.password = "vagrant"
  2. Führe aus:
    vagrant reload
vagrant ssh

    Sobald du eingeloggt bist, kannst du das Problem mit den Keys wie in Lösung 2 beschrieben beheben.

Lösung 4: Lokale Vagrant-Metadaten aufräumen

Manchmal hat sich dein lokaler Host-Rechner "gemerkt", dass ein privater Schlüssel existiert, der auf der VM gar nicht mehr aktuell ist.

  1. Navigiere im Projektordner in den versteckten Ordner: .vagrant/machines/<box-name>/virtualbox/
  2. Suche nach der Datei private_key.
  3. Benenne sie um (z. B. in private_key.backup) oder lösche sie, falls du sicher bist.
  4. Führe aus:
    vagrant reload

    Vagrant greift nun automatisch auf den globalen Standardschlüssel zurück.

Lösung 5: Der "Nuclear Reset" (Wenn Datenverlust egal ist)

Wenn sich keine wichtigen Daten auf der VM befinden und du schnell weiterarbeiten musst, ist der sauberste Weg ein kompletter Reset:

vagrant destroy -f
vagrant up

Achtung: Dabei werden alle Daten innerhalb der VM gelöscht! Die VM wird komplett frisch und fehlerfrei neu aufgesetzt.

Zusammenfassung

In 90% der Fälle löst Lösung 1 (config.ssh.insert_key = false) das Problem sofort. Liegt es an falschen Dateirechten auf dem Gastsystem, hilft der kurze Weg über die GUI (Lösung 2), um die Rechte auf 700 (~/.ssh) und 600 (authorized_keys) zurückzusetzen.

0