#1011756 Vagrant cannot boot VMs with SHA-1 algorithm disabled in OpenSSH

Package:
vagrant
Source:
vagrant
Description:
Tool for building and distributing virtualized development environments
Submitter:
Andrew Chadwick
Date:
2022-05-30 12:18:04 UTC
Severity:
normal
#1011756#5
Date:
2022-05-26 12:07:07 UTC
From:
To:
Dear base box maintainers:

I don’t know if this should be a documentation fix or an image fix. I’ll
just lay out the problem with as much detail as I can so that people can
search it and find better workarounds. I think the FAQ at
https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes should probably be
updated, given that it’s linked from https://app.vagrantup.com/debian, a
place where people sill be looking.

OpenSSH have addressed a weakness of SHA-1 by removing the ssh-rsa public
key signature algorithm from their list of supported key types. The
openssh-server 1:9.0p1-1 package in the debian/testing64 image incorporates
this change. However the vagrant 2.2.14+dfsg-1 package shipped with Debian
11 “bullseye” has a default “vagrant insecure public key” which requires
ssh-rsa.

See
- https://github.com/hashicorp/vagrant/issues/11783
- https://github.com/hashicorp/packer/issues/10074


## Symptoms

The current debian/testing64 image hangs during “vagrant up”. If I follow
the instructions at https://wiki.debian.org/Teams/Cloud/VagrantQuickStart,
the following happens. I already have vagrant and vagrant-libvirt installed
and configured enough for me to use them. I am using the current Debian 11
versions.

However, I can SSH in to the running virtual just fine from another window.
Why this is, I don’t know.

However, connections from the still-running vagrant command on the host are
still failing, as a quick check of auth.log will confirm. What the heck!


## Workaround

One way to fix it from the user perspective is to grab @dustymabe’s fix from
https://github.com/hashicorp/vagrant/issues/11783#issuecomment-720822960,
and apply it over our mysteriously working SSH connection

This allows the hung vagrant to resume immediately:



   thanks for keeping the boxes fresh
   - Andrew
#1011756#10
Date:
2022-05-26 12:14:58 UTC
From:
To:
I should add that the debian/bullseye64 image works perfectly using the
instructions given. No need to fiddle with the SSH config while it’s
half-up.


   - Andrew
#1011756#15
Date:
2022-05-26 14:27:46 UTC
From:
To:
## Workaround 2 (neater)

Testing a bit more, I can confirm that installing vagrant 2.2.19 from
Debian Testing fixes this on Debian 11 (buster) hosts when trying to
connect to debian/testing64 box images.

I guess Vagrant uses ruby-net-ssh for the initial connection using the
insecure default key, the connection it uses to replace that key on the new
machine with the creating user’s. This is why it also ignores
config.ssh.extra_args in Vagrantfiles for that initial connection, but
respects them at “vagrant ssh” time.

Debian 11 users only need to update the vagrant package for now, iupdating
from stable’s 2.2.14+dfsg-1 to testing’s 2.2.19+dfsg-1. They will need to
employ apt pinning to stay on stable while updating vagrant from testing.
One HOWTO is here: https://coderwall.com/p/aatvta/apt-pinning-in-debian, or
see https://wiki.debian.org/AptConfiguration for a deeper dive.

Vagrant’s written in Ruby, and it is packaged to be pretty tolerant about
its dependencies’ versions in Debian.


   - Andrew
#1011756#20
Date:
2022-05-26 18:51:48 UTC
From:
To:
Thanks Andrew for the time you took investigating this.

So I understood right, this was a problem in the way Vagrant ruby
library did ssh connection, as in presence of a ssh-rsa key it would
always try to connect using a SHA-1 signature algorithm (the algo which
was dropped by newer OpenSSH) instead of trying SHA-256 or SHA-512 (see
https://github.com/hashicorp/vagrant/issues/11783#issuecomment-818951984)

This means this was actually a bug in Vagrant, not in the boxes
themselves. This is proved by your fact that the testing version of
Vagrant can perfectly connect to the testing boxes.

Not sure what to here, I am thinking of reassigning this bug report to
the vagrant package, and maybe point the FAQ to this bug report.
#1011756#25
Date:
2022-05-26 22:18:50 UTC
From:
To:
Yeah, I initially thought this was a problem with the debian/testing64 box,
since debian/bullseye64 running on a bullseye host comes up cleanly. The
problem lies with the Debian vagrant version and its way of invoking
Net::SSH.

I think that reassigning this report is the right course of action, and
your summation sounds right too. Pointing the FAQ here would help users
trying testing on stable via vagrant out a lot.

It looks like there's a nice upstream patch (containing a monkeypatch?)
that can be applied to the version of vagrant in stable too:
https://github.com/hashicorp/vagrant/pull/12298/files. It's targeted at
exactly the Net::SSH 6.1.0 that's in Debian stable right now. The vagrant
maintainers will have the option of backporting the patch or releasing a
newer vagrant in the next Debian 11 point release: up to them.

I'm happy to test things out ;)


    - Andrew
#1011756#41
Date:
2022-05-30 11:46:52 UTC
From:
To:
Hi,

The bug in ruby-net-ssh is tracked as #1009155 and #1008541, and is
fixed in stable-proposed-updates and bullseye-backports. I've updated
the wiki page accordingly.

Lucas