Bug 1259559 - VMs get stuck at Waiting for SSH when ssh-agent is running and has a ed25519 key
Summary: VMs get stuck at Waiting for SSH when ssh-agent is running and has a ed25519 key
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: vagrant-libvirt
Version: 24
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1369491
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-03 03:49 UTC by Randy Barlow
Modified: 2017-01-09 08:46 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-01-09 08:46:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Vagrantfile (350 bytes, text/plain)
2015-09-03 03:49 UTC, Randy Barlow
no flags Details

Description Randy Barlow 2015-09-03 03:49:31 UTC
Created attachment 1069620 [details]
Vagrantfile

Description of problem:
On rawhide I have a very repeatable problem where vagrant-libvirt never thinks the guest VM's ssh server is running and sits forever at "Waiting for SSH to become available...". The SSH server is running in the guest, as I can ssh to it from the host and it answers and allows me to login. I've attached a simple Vagrantfile that demonstrates the issue.

Version-Release number of selected component (if applicable):
vagrant-libvirt-0.0.30-2.fc23.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Put the attached Vagrantfile into an empty directory
2. $ vagrant up

Actual results:
The echo statement in the Vagrantfile will not execute, and the vagrant up command will get stuck at the "Waiting for SSH" message.

Expected results:
The echo statement should execute, and the vagrant up command should finish successfully.

Comment 1 Randy Barlow 2015-09-03 03:54:52 UTC
The upstream bug report is here: https://github.com/pradels/vagrant-libvirt/issues/452

Comment 2 Josef Stribny 2015-09-14 08:50:41 UTC
I've just tried this:

[strzibny@jstribnyntb test]$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Box 'http://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-22/fedora-22.box' could not be found. Attempting to find and install...
    default: Box Provider: libvirt
    default: Box Version: >= 0
==> default: Adding box 'http://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-22/fedora-22.box' (v0) for provider: libvirt
    default: Downloading: http://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-22/fedora-22.box
==> default: Successfully added box 'http://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-22/fedora-22.box' (v0) for 'libvirt'!
==> default: Uploading base box image as volume into libvirt storage...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default:  -- Name:              test_default
==> default:  -- Domain type:       kvm
==> default:  -- Cpus:              1
==> default:  -- Memory:            512M
==> default:  -- Base box:          http://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-22/fedora-22.box
==> default:  -- Storage pool:      default
==> default:  -- Image:             /var/lib/libvirt/images/test_default.img
==> default:  -- Volume Cache:      default
==> default:  -- Kernel:            
==> default:  -- Initrd:            
==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     5900
==> default:  -- Graphics IP:       127.0.0.1
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        9216
==> default:  -- Keymap:            en-us
==> default:  -- Command line : 
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
    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: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
==> default: Creating shared folders metadata...
==> default: Rsyncing folder: /home/strzibny/tmp/test/ => /vagrant
==> default: Configuring and enabling network interfaces...
==> default: Running provisioner: shell...
    default: Running: inline script
==> default: This won't happen


Works fine. 

I am running:

$ rpm -q vagrant
vagrant-1.7.2-9.fc22.noarch
$ rpm -q vagrant-libvirt
vagrant-libvirt-0.0.26-3.fc22.noarch

Do you have any real reproducer for me? Otherwise I am not sure why it fails for you.

Comment 3 Randy Barlow 2015-09-14 18:12:14 UTC
I changed the subject of this bug to better reflect what has been noted on the upstream bug report. It seems to be related to my use of the ed25519 ssh key. See if you can reproduce with these steps:

0) Create an ed25519 ssh key.
1) Start ssh-agent.
2) Add the ed25519 to the running ssh-agent with ssh-add.
3) Use the example Vagrant file, and vagrant up.

I'm not sure if it matters, but I am also using vagrant and vagrant-libvirt from Rawhide.

Comment 4 Jan Kurik 2016-02-24 15:30:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 5 Vít Ondruch 2016-08-24 14:27:53 UTC
Since you are referencing bug 1369491, did you have a chance to test F25+, since I updated the rubygem-net-ssh there ...

Comment 6 Randy Barlow 2016-08-24 20:04:08 UTC
Hello Vit!

I have not tested this on F25, but I do have plans to update one of my Vagrant systems to F25 soon. I'll report back here when I do (probably a couple or three weeks).

Comment 7 Randy Barlow 2016-09-04 04:32:01 UTC
Hello Vit! I tested this on Fedora 25 tonight, and it worked there. You may still want to fix it on Fedora 24, but I'll leave that decision to you. Thanks!

Comment 8 Vít Ondruch 2016-09-05 07:52:10 UTC
(In reply to Randy Barlow from comment #7)
> Hello Vit! I tested this on Fedora 25 tonight, and it worked there.

Thx for testing and confirmation.

> You may
> still want to fix it on Fedora 24, but I'll leave that decision to you.
> Thanks!

Frankly, I consider this niche issue, so I'd prefer to close the ticket, especially if net-ssh rebase is required, which could break other things.

Comment 9 Matěj Koudelka 2016-09-30 14:00:49 UTC
I have same problem on Fedora24 with libvirt box Centos7. The problem is in wrong rights of new authorized_keys file.
Try log in as user vagrant  using default password ('vagrant') and change rights of file 'chmod 600 ~/.ssh/authorized_keys'.

Comment 10 Vít Ondruch 2016-10-03 11:06:48 UTC
(In reply to Matěj Koudelka from comment #9)
Your might experience similar symptoms, but from your description, comparing to comment 3, it seems to be different one.

Comment 11 Matěj Koudelka 2016-10-03 12:23:34 UTC
(In reply to Vít Ondruch from comment #10)
> (In reply to Matěj Koudelka from comment #9)
> Your might experience similar symptoms, but from your description, comparing
> to comment 3, it seems to be different one.

OK

Comment 12 Randy Barlow 2017-01-07 03:39:44 UTC
Vit I won't personally mind if you want to close this ticket. I've moved my primary Vagrant host to Fedora 25, so I don't hit this issue often anymore.

Comment 13 Vít Ondruch 2017-01-09 08:46:52 UTC
(In reply to Randy Barlow from comment #12)
> Vit I won't personally mind if you want to close this ticket. I've moved my
> primary Vagrant host to Fedora 25, so I don't hit this issue often anymore.

Thank you. I'm closing this now.


Note You need to log in before you can comment on or make changes to this bug.