Vagrant ssh 'Authentifizierungsfehler. Wiederholen ... 'wiederholter Fehler - Schlüssel stimmen nicht überein, kann nicht gefunden werden

Ich habe ein irritierendes Problem erlebt, dass ich nicht herumkommen kann.Vagrant ssh 'Authentifizierungsfehler. Wiederholen ... 'wiederholter Fehler - Schlüssel stimmen nicht überein, kann nicht gefunden werden

Ich versuche, vagrant up ein centos7 System in dieser Umgebung:

Windows-10
Hyper-V (nicht Jahrestag Update-Version)
Docker Bild "serveit/centos7" oder " bluefedora/hyperv-alpha-centos7"
OpenSSH installiert, privaten Schlüssel konfiguriert

den Inhalt meiner Vagrantfile:

Vagrant.configure("2") do |config| 
    #config.vm.box = "serveit/centos-7" 
    config.vm.box = "bluefedora/hyperv-alpha-centos7" 
    config.ssh.private_key_path = "~/.vagrant.d/insecure_private_key" 
    config.ssh.forward_agent = true 
end

Ich erhalte diese Störung, wenn ein vagrant up tun:

PS C:\Programs\vagrant_stuff\centos7> vagrant up 
Bringing machine 'default' up with 'hyperv' provider... 
==> default: Verifying Hyper-V is enabled... 
==> default: Importing a Hyper-V instance 
    default: Cloning virtual hard drive... 
    default: Creating and registering the VM... 
    default: Successfully imported a VM with name: vagrantbox 
==> default: Starting the machine... 
==> default: Waiting for the machine to report its IP address... 
    default: Timeout: 120 seconds 
    default: IP: 192.168.137.6 
==> default: Waiting for machine to boot. This may take a few minutes... 
    default: SSH address: 192.168.137.6:22 
    default: SSH username: vagrant 
    default: SSH auth method: private key 
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace 
    default: this with a newly generated keypair for better security. 
    default: 
    default: Inserting generated public key within guest... 
    default: Removing insecure key from the guest if it's present... 
    default: Key inserted! Disconnecting and reconnecting using new SSH key... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
    default: Warning: Authentication failure. Retrying... 
Timed out while waiting for the machine to boot. This means that 
Vagrant was unable to communicate with the guest machine within 
the configured ("config.vm.boot_timeout" value) time period. 

If you look above, you should be able to see the error(s) that 
Vagrant had when attempting to connect to the machine. These errors 
are usually good hints as to what may be wrong. 

If you're using a custom box, make sure that networking is properly 
working and you're able to connect to the machine. It is a common 
problem that networking isn't setup properly in these boxes. 
Verify that authentication configurations are also setup properly, 
as well. 

If the box appears to be booting properly, you may want to increase 
the timeout ("config.vm.boot_timeout") value.

Ich kann ein tun vagrant ssh-config:

Host default 
    HostName 192.168.137.6 
    User vagrant 
    Port 22 
    UserKnownHostsFile /dev/null 
    StrictHostKeyChecking no 
    PasswordAuthentication no 
    IdentityFile C:/Users/Kareem/.vagrant.d/insecure_private_key 
    IdentitiesOnly yes 
    LogLevel FATAL 
    ForwardAgent yes

ich an anderer Stelle sah, dass ich vagrant halt und vagrant up versuchen sollte zu behebe das Problem. Das hat nicht funktioniert.

Ich löschte auch die .vagrant.d/insecure_private_key Datei und sah, dass es neu erstellt wurde. Kein Problem, das wird auch erwartet.

Auch vagrant ssh Arbeiten mit Passwort:

PS C:\Programs\vagrant_stuff\centos7> vagrant ssh 
[email protected]'s password: 
[[email protected] ~]$

Also, weil ich SSH konnte, beschloss ich, die .ssh/authorized_keys Datei zu überprüfen:

[vagrant @ localhost ~] $ cat .ssh/authorized_keys

[[email protected] ~]$ cat /home/vagrant/.ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIRcYs0HBn/BOjiKg9fGnoraVxRnnZk+6sM3waFFE1+U3aO8GQjRKxQsYgJNoyRmNVymzpP13kOoLodDsz 
UKhdcO6dL+zAtmhsFTgmADMXxVzM3mfRWfPG2HdsU13Pof77A68Ln6z6X4jVG4cnsclYvz67Gudl7lZ9VI2TOdDn1V+7ZANlkGnqejIwA2RVWtYLgLQHU9p4 
47nvRqId71XaG8BZpbONRzzrL49wWyjfc4h6SdaHVJZJB6kY+vkr31xw6TPIIlo2UHH7Ihlk6KADNo4wFJYF+ozIA7C792omzjN1zu1SayvCYNG21yZy/cCd 
n2Hr158Jy83A9CslQPbT vagrant

Dafuq ist dieser Schlüssel?!?! Ich bin ziemlich sicher, dass dies nicht der öffentliche Schlüssel ist, der Vagrant entspricht. Dies ist auch nicht mein öffentlicher Systemschlüssel. Als ich die Vagrant Public key prüfe ich diese:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9H 
ZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHi 
lFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRd 
K8jlqm8tehUc9c9WhQ== vagrant insecure public key

Außerdem, wenn ich meine Vagrantfile aktualisieren mein System privaten Schlüssel zu verwenden:

#config.ssh.private_key_path = "~/.vagrant.d/insecure_private_key" 
    config.ssh.private_key_path = "~/.ssh/id_rsa"

ich einen anderen öffentlichen Schlüssel in der VM, die das ist Vagrant Public key:

[[email protected] ~]$ cat /home/vagrant/.ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9H 
ZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHi 
lFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRd 
K8jlqm8tehUc9c9WhQ== vagrant insecure public key

ich sehe auch, dass der Bereitstellungsprozess nicht einen neuen Schlüssel einführen lässt. Das alles scheint rückwärts zu laufen, ich dachte, dass der Schlüssel nur aktualisiert werden sollte, wenn ich meinen privaten Schlüssel benutze und dass er meinen eigenen verwenden sollte.

HILFE!

Kann mir jemand helfen, herauszufinden, warum das passiert?

Quelle

2016-07-29 Kareem

Es stellte sich heraus, ein bekannter Fehler ist 1.8.5 in Vagrant (Wird in 1.8.6 festgelegt werden):

Einzelheiten here

Wenn Sie 1.8.5 verwenden, können Sie die aktualisierte Download Version von PR #7611 mit Powershell:

[IO.File]::WriteAllLines("C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.5\plugins\guests\linux\cap\public_key.rb", (Invoke-WebRequest -Uri https://raw.githubusercontent.com/Poohblah/vagrant/41063204ca540c44f9555bd11ba9e76c7307bec5/plugins/guests/linux/cap/public_key.rb).Content)

Quelle

2016-08-01 12:23:45 Kareem

Aus den Kommentaren dort habe ich gelernt, die Datei auf dem Mac zu patchen ist '/ opt/vagrant/embedded/edelsteine / edelsteine / vagrant-1.8.5/plugins/guests/linux/cap/public_key.rbb'. (Die Diff-Inhalte sind in der Verbindung angegeben.) Nach dem Patch lief alles gut. – Wildcard

SSH in die vagabundierenden Maschine und dieses Privileg geben.

vagrant @ localhost: chmod 600 ~/.ssh/authorized_keys.

Comeback an den Host-Ausgang aus und drücken Sie "Vagabund reload"

Es funktioniert !!!

Quelle

2016-08-08 17:01:59 gaurav

Innerhalb public_key.rb Datei 56 jene in Zeile finden und hängen chmod 0600 ~/.ssh/authorized_keys wie so:

  if test -f ~/.ssh/authorized_keys; then 

      grep -v -x -f '#{remote_path}' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp 

      mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys 
      chmod 0600 ~/.ssh/authorized_keys 
     fi 

     rm -f '#{remote_path}'

Pfad für Windows: C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.5\plugins\guests\linux\cap\public_key.rb

Weg für Mac: /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/plugins/guests/linux/cap/public_key.rb

Quelle

2016-09-23 04:41:31

Vagrant ssh 'Authentifizierungsfehler. Wiederholen ... 'wiederholter Fehler - Schlüssel stimmen nicht überein, kann nicht gefunden werden

Antwort

Verwandte Themen