New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Newly generated key is empty #5219

Closed
ghost opened this Issue Jan 20, 2015 · 18 comments

Comments

Projects
None yet
@ghost

ghost commented Jan 20, 2015

I'm booting a CentOS 7 machine with SELinux enabled.

==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Starting the VMware VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 172.16.171.131:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection refused. Retrying...
    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 its present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
Text will be echoed in the clear. Please install the HighLine or Termios libraries to suppress echoed text.
vagrant@172.16.171.131's password:vagrant
==> default: Machine booted and ready!

It seems that the newly generated public key isn't inserted:

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

This comment has been minimized.

Show comment
Hide comment
@sethvargo

sethvargo Jan 20, 2015

Contributor

@yves-vogl sorry you are having problems with the new key insertion. Just for posterity sake, what happens if you disable SELinux?

Contributor

sethvargo commented Jan 20, 2015

@yves-vogl sorry you are having problems with the new key insertion. Just for posterity sake, what happens if you disable SELinux?

@shiny

This comment has been minimized.

Show comment
Hide comment
@shiny

shiny Jan 27, 2015

I have the same problem too

vagrant up

default: Warning: Connection timeout. Retrying...
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 its 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...

Login in with password, cat ~/.ssh/authorized_keys is empty.

I have to excute openssl rsa -in .vagrant/machines/default/virtualbox/private_key -pubout
generate a public key,write it to authorized_keys by vim, then it goes normal.

Use debian7 minimal, SELinux not enabled.
That's very strange.

shiny commented Jan 27, 2015

I have the same problem too

vagrant up

default: Warning: Connection timeout. Retrying...
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 its 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...

Login in with password, cat ~/.ssh/authorized_keys is empty.

I have to excute openssl rsa -in .vagrant/machines/default/virtualbox/private_key -pubout
generate a public key,write it to authorized_keys by vim, then it goes normal.

Use debian7 minimal, SELinux not enabled.
That's very strange.

@shiny

This comment has been minimized.

Show comment
Hide comment
@shiny

shiny Jan 28, 2015

Solved by check the "Standard system utilities"
32

shiny commented Jan 28, 2015

Solved by check the "Standard system utilities"
32

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 4, 2015

SELinux did not cause this. The same happens with SLES 11.3

==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 172.16.171.131:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection refused. Retrying...
    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 its 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...```

ghost commented Feb 4, 2015

SELinux did not cause this. The same happens with SLES 11.3

==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 172.16.171.131:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection refused. Retrying...
    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 its 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...```
@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Mar 12, 2015

vagrant package keeps messing with the key now even if the built box has correct file permissions on it. This is the second major roadblock towards getting my box up and running just this.

haf commented Mar 12, 2015

vagrant package keeps messing with the key now even if the built box has correct file permissions on it. This is the second major roadblock towards getting my box up and running just this.

@smozely

This comment has been minimized.

Show comment
Hide comment
@smozely

smozely Mar 27, 2015

I'm seeing the same issue with RHEL and SELInux.

Update:
I don't think it is SELinux, having SELinux set to disabled. still ends up with same result.

Update 2:
A workaround is to just set config.ssh.insert_key = false in your Vagrantfile. Hat tip to the kitchen-vagrant link.

smozely commented Mar 27, 2015

I'm seeing the same issue with RHEL and SELInux.

Update:
I don't think it is SELinux, having SELinux set to disabled. still ends up with same result.

Update 2:
A workaround is to just set config.ssh.insert_key = false in your Vagrantfile. Hat tip to the kitchen-vagrant link.

@rbair23

This comment has been minimized.

Show comment
Hide comment
@rbair23

rbair23 May 28, 2015

I'm seeing this also on Oracle Linux 7.1. It seems like a pretty universal issue then with any RHEL 7 based system, as there are now reports of RHEL, CentOS 7, and OEL 7.1.

rbair23 commented May 28, 2015

I'm seeing this also on Oracle Linux 7.1. It seems like a pretty universal issue then with any RHEL 7 based system, as there are now reports of RHEL, CentOS 7, and OEL 7.1.

@dkoloditch

This comment has been minimized.

Show comment
Hide comment
@dkoloditch

dkoloditch May 28, 2015

This worked for me.

Assuming your IP addresses are the same (check via cat ~/.ssh/known_hosts), run:

ssh-keygen -R 172.28.128.1
ssh-keygen -R 172.28.128.3
ssh-keygen -R 127.0.0.1
ssh-keygen -R [127.0.0.1]
ssh-keygen -R [127.0.0.1]:2222
ssh-keygen -R 10.0.2.1
ssh-keygen -R 10.0.2.15

dkoloditch commented May 28, 2015

This worked for me.

Assuming your IP addresses are the same (check via cat ~/.ssh/known_hosts), run:

ssh-keygen -R 172.28.128.1
ssh-keygen -R 172.28.128.3
ssh-keygen -R 127.0.0.1
ssh-keygen -R [127.0.0.1]
ssh-keygen -R [127.0.0.1]:2222
ssh-keygen -R 10.0.2.1
ssh-keygen -R 10.0.2.15

@rbair23

This comment has been minimized.

Show comment
Hide comment
@rbair23

rbair23 May 28, 2015

I was wrong. In fact I am seeing the same symptoms (constantly being told that the key is insecure and a new secure key has been successfully installed) but not because /home/vagrant/.ssh/authorized_keys is empty, but rather because it is over-full. The file contains two keys: the original insecure one and the new secure one.

I see in the code (https://github.com/mitchellh/vagrant/blob/efd1d5e11bfc5a72c7a1d1eae294b4751d841544/plugins/guests/linux/cap/insert_public_key.rb) that the new secure key is appended to the authorized_keys file, and the insecure key is never removed.

I created this box that I'm testing with, and followed instructions such as http://docs.vagrantup.com/v2/boxes/base.html which contains language such as:

When Vagrant boots a box and detects the insecure keypair, it will automatically replace it with a randomly generated keypair for additional security while the box is running.

However the code above clearly uses >> to append to authorized_keys and not >, and also doesn't look for and remove the insecure key. I'm left wondering if my base box should just skip this step, and what would happen?

I'm also wondering , if I've followed this right, it hasn't shown up more generally for everybody.

rbair23 commented May 28, 2015

I was wrong. In fact I am seeing the same symptoms (constantly being told that the key is insecure and a new secure key has been successfully installed) but not because /home/vagrant/.ssh/authorized_keys is empty, but rather because it is over-full. The file contains two keys: the original insecure one and the new secure one.

I see in the code (https://github.com/mitchellh/vagrant/blob/efd1d5e11bfc5a72c7a1d1eae294b4751d841544/plugins/guests/linux/cap/insert_public_key.rb) that the new secure key is appended to the authorized_keys file, and the insecure key is never removed.

I created this box that I'm testing with, and followed instructions such as http://docs.vagrantup.com/v2/boxes/base.html which contains language such as:

When Vagrant boots a box and detects the insecure keypair, it will automatically replace it with a randomly generated keypair for additional security while the box is running.

However the code above clearly uses >> to append to authorized_keys and not >, and also doesn't look for and remove the insecure key. I'm left wondering if my base box should just skip this step, and what would happen?

I'm also wondering , if I've followed this right, it hasn't shown up more generally for everybody.

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Jul 6, 2015

Member

@rbair23 After adding the key successfully, it does remove it.

I'll try to repro this with a Cent box.

Member

mitchellh commented Jul 6, 2015

@rbair23 After adding the key successfully, it does remove it.

I'll try to repro this with a Cent box.

@mitchellh mitchellh added guest/redhat and removed core labels Jul 6, 2015

@prateepb

This comment has been minimized.

Show comment
Hide comment
@prateepb

prateepb Jul 9, 2015

Contributor

I'm seeing the same on CentOS 6

Contributor

prateepb commented Jul 9, 2015

I'm seeing the same on CentOS 6

@sethvargo sethvargo added this to the 1.8 milestone Jul 10, 2015

@doctapp

This comment has been minimized.

Show comment
Hide comment
@doctapp

doctapp Jul 28, 2015

Seems linked to #5186

doctapp commented Jul 28, 2015

Seems linked to #5186

@vdloo

This comment has been minimized.

Show comment
Hide comment
@vdloo

vdloo Jul 30, 2015

Contributor

Same on Debian 8 Jessie
@smozely's workaround of adding config.ssh.insert_key = false seems to work

Contributor

vdloo commented Jul 30, 2015

Same on Debian 8 Jessie
@smozely's workaround of adding config.ssh.insert_key = false seems to work

@doctapp

This comment has been minimized.

Show comment
Hide comment
@doctapp

doctapp Jul 30, 2015

Creating a new ubuntu/trusty64 VM works with the config.ssh.insert_key = false, but my existing VMs don't work.

doctapp commented Jul 30, 2015

Creating a new ubuntu/trusty64 VM works with the config.ssh.insert_key = false, but my existing VMs don't work.

@lsmolic

This comment has been minimized.

Show comment
Hide comment
@lsmolic

lsmolic Aug 7, 2015

I have found the 1.7.2 to be very buggy in this particular area and in my google travels I have found the following to resolve almost all situations, assuming you don't need a secure user:

config.ssh.username = "vagrant"
config.ssh.password = "vagrant"
config.ssh.insert_key = false

This will completely overwrite the key implementation, but there are definitely a number of bugs associated with public/private keys in this vagrant version.

Hope it helps.

lsmolic commented Aug 7, 2015

I have found the 1.7.2 to be very buggy in this particular area and in my google travels I have found the following to resolve almost all situations, assuming you don't need a secure user:

config.ssh.username = "vagrant"
config.ssh.password = "vagrant"
config.ssh.insert_key = false

This will completely overwrite the key implementation, but there are definitely a number of bugs associated with public/private keys in this vagrant version.

Hope it helps.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 9, 2015

Has anyone done a root cause analysis so far? Maybe we should support @mitchellh more to get this issue solved.

ghost commented Aug 9, 2015

Has anyone done a root cause analysis so far? Maybe we should support @mitchellh more to get this issue solved.

@vlad-ko

This comment has been minimized.

Show comment
Hide comment
@vlad-ko

vlad-ko Oct 18, 2015

hey guys, any updates on this, we still seem to be running into this problem... anything i can do to help troubleshoot?

vlad-ko commented Oct 18, 2015

hey guys, any updates on this, we still seem to be running into this problem... anything i can do to help troubleshoot?

@sethvargo

This comment has been minimized.

Show comment
Hide comment
@sethvargo

sethvargo Nov 19, 2015

Contributor

This should be fixed by GH-6406. Thanks everyone!

Contributor

sethvargo commented Nov 19, 2015

This should be fixed by GH-6406. Thanks everyone!

@sethvargo sethvargo closed this Nov 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment