Vagrant ssh 'Echec de l'authentification. Réessayer ... 'erreur répétée - les clés ne correspondent pas, ne peut pas trouver la solution

J'ai connu un problème irritant que je ne peux pas contourner.Vagrant ssh 'Echec de l'authentification. Réessayer ... 'erreur répétée - les clés ne correspondent pas, ne peut pas trouver la solution

Je suis en train de vagrant up un système centos7 dans cet environnement:

de Windows 10
Hyper-V (non anniversaire version mise à jour)
l'image Docker "serveit/centos7" ou " bluefedora/HyperV-alpha-centos7"
OpenSSH installé, clé privée configurée

Le contenu de mon 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

j'obtiens cette erreur lorsque vous faites un vagrant up:

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.

je peux faire une 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

j'ai vu ailleurs que je devrais essayer vagrant halt et vagrant up à résoudre le problème. Cela n'a pas fonctionné.

J'ai également supprimé le fichier .vagrant.d/insecure_private_key et vu qu'il a été recréé. Pas de problème, c'est aussi prévu.

également vagrant ssh fonctionne avec le mot de passe:

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

parce que je pouvais SSH, j'ai décidé de vérifier le fichier .ssh/authorized_keys:

[errante @ localhost ~] .ssh $ cat/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 est cette clé?!?! Je suis tout à fait sûr que ce n'est pas la clé publique qui correspond à Vagrant. Ce n'est pas non plus ma clé publique du système. Quand je vérifie l'Vagrant Public key je reçois ceci:

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

De plus, si je mets à jour mon Vagrantfile à utiliser mon système clé privée:

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

Je reçois une autre clé publique dans la machine virtuelle, qui est la 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

Je vois aussi que le processus d'approvisionnement n'insère pas une nouvelle clé. Tout cela semble en arrière, je pensais que la clé ne devrait être mise à jour que si j'utilise ma clé privée, et qu'elle devrait utiliser la mienne.

AIDE!

Quelqu'un peut-il m'aider à comprendre pourquoi cela se produit?

Source

2016-07-29 Kareem

fin de compte, il y a un bug connu dans Vagrant 1.8.5 (Sera fixé à 1.8.6):

Détails here

Si vous utilisez 1.8.5, vous pouvez télécharger la version actualisée la version de PR #7611 en utilisant 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)

Source

2016-08-01 12:23:45 Kareem

D'après les commentaires là-bas, j'ai appris la Le fichier à patcher sur Mac est '/ opt/vagagrant/embarqué/gems/gems/errant-1.8.5/plugins/invités/linux/cap/public_key.rb'. (Les contenus de diff sont donnés dans le lien.) Tout a bien fonctionné après ce patch. – Wildcard

SSH dans la machine et errante donner ce privilège.

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

sortie en retour à l'hôte et cliquez sur « reload errante »

Il fonctionne !!!

Source

2016-08-08 17:01:59 gaurav

intérieur public_key.rb fichier trouver ceux à la ligne 56 et append chmod 0600 ~/.ssh/authorized_keys comme ceci:

  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}'

chemin pour Windows: C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.5\plugins\guests\linux\cap\public_key.rb

chemin pour mac: /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/plugins/guests/linux/cap/public_key.rb

Source

2016-09-23 04:41:31

Vagrant ssh 'Echec de l'authentification. Réessayer ... 'erreur répétée - les clés ne correspondent pas, ne peut pas trouver la solution

Répondre

Questions connexes