Vagrant: openssh deprecates ssh-rsa key type: maybe update vagrant insecure key

Created on 24 Jul 2020  路  8Comments  路  Source: hashicorp/vagrant

Vagrant version

vagrant-2.2.9

Host operating system

Fedora 31

Guest operating system

Fedora Rawhide (will become Fedora 33) with openssh-8.3p1-3.fc33.x86_64 and crypto-policies-20200702-1.gitc40cede.fc33.noarch.

Vagrantfile

Any vagrantfile

Expected behavior

vagrant up works. vagrant ssh works.

Actual behavior

Gets stuck at Waiting for SSH to become available.... Inside the box in the logs we see:

Jul 24 15:21:32 localhost.localdomain sshd[1853]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]

Description

Upstream SSH has been claiming for a few releases now that:

It is now possible to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K. For this reason, we will be
disabling the "ssh-rsa" public key signature algorithm by default in a
near-future release.

Distributions are picking up on this and deprecating ssh-rsa. Fedora did this recently and it will land in the next major Fedora release. We should consider updating the pubkey to something that uses a newer algorithm.

bug core enhancement

Most helpful comment

This may not be for everyone, but my team has found that incorporating update-crypto-policies --set LEGACY
in Fedora 33 vagrant box generation does successfully set the policies such that vagrant can communicate with the box during vagrant up.

All 8 comments

Hey there @dustymabe - thanks for the heads up, that makes sense. insecure_private_key is however named that for a reason :) So I don't know how soon we'll get to this, but I'm happy to keep this issue open for now. Also, to avoid the warning, you can always replace the insecure key with one of your own so that you aren't using the default: https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html#config-ssh-insert_key

Hey there @dustymabe - thanks for the heads up, that makes sense. insecure_private_key is however named that for a reason :) So I don't know how soon we'll get to this, but I'm happy to keep this issue open for now.

Thanks!

Also, to avoid the warning, you can always replace the insecure key with one of your own so that you aren't using the default: https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html#config-ssh-insert_key

It's not a warning that can be ignored. It's an error. The vagrant up never completes and hangs at Waiting for SSH to become available... and thus would never be able to replace the insecure key because it can never get into the box to begin with.

I do the box builds for Fedora and publish them to https://app.vagrantup.com/fedora. Other distros are going to hit this soon, Fedora just happens to be one of the earliest to pick things up.

Ohhh, I see! Well that makes sense. Thanks for letting us know then @dustymabe

This may not be for everyone, but my team has found that incorporating update-crypto-policies --set LEGACY
in Fedora 33 vagrant box generation does successfully set the policies such that vagrant can communicate with the box during vagrant up.

Fedora 33 is now in Beta. (Edit: Upstream OpenSSH is still planning on deprecating the RSA-SHA1 key type).

This may not be for everyone, but my team has found that incorporating update-crypto-policies --set LEGACY
in Fedora 33 vagrant box generation does successfully set the policies such that vagrant can communicate with the box during vagrant up.

@jshimkus-rh I am now implementing update-crypto-policies --set LEGACY for https://github.com/lavabit/robox/pull/173, but always get reinitialized to DEFAULT during first vagrant up. May you share some hints about your successful story?

On Nov 1, 2020, at 23:08, Wong Hoi Sing Edison notifications@github.com wrote:

This may not be for everyone, but my team has found that incorporating update-crypto-policies --set LEGACY
in Fedora 33 vagrant box generation does successfully set the policies such that vagrant can communicate with the box during vagrant up.

@jshimkus-rh I am now implementing update-crypto-policies --set LEGACY for lavabit/robox#173, but always get reinitialized to DEFAULT during first vagrant up. May you share some hints about your successful story?

I took at look at your change and one difference that jumps out is that we added a crypto-policies.sh (see attached) and placed it immediately after swap.sh in the fedora33 .json file:

"provisioners": [
{
...
"scripts": [
"{{user bento_file_dir}}scripts/swap.sh",
"{{user bento_file_dir}}scripts/crypto-policies.sh",
"{{user bento_file_dir}}scripts/fix-slow-dns.sh",
"{{user bento_file_dir}}scripts/build-tools-30.sh",
"{{user bento_file_dir}}scripts/install-supporting-packages.sh",
"{{user bento_file_dir}}../_common/motd.sh",
"{{user bento_file_dir}}../_common/sshd.sh",
"{{user bento_file_dir}}../_common/virtualbox.sh",
"{{user bento_file_dir}}../_common/vmware.sh",
"{{user bento_file_dir}}../_common/parallels.sh",
"{{user bento_file_dir}}../_common/vagrant.sh",
"{{user bento_file_dir}}scripts/cleanup.sh",
"{{user bento_file_dir}}../_common/minimize.sh"
],
...
}
],

Other than that it doesn't seem fundamentally different.

For those trying to figure out how to work around this, check out what I did in the official fedora vagrant box for now: https://pagure.io/fedora-kickstarts/pull-request/669#request_diff

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dorinlazar picture dorinlazar  路  3Comments

luispabon picture luispabon  路  3Comments

tomhking picture tomhking  路  3Comments

Cbeck527 picture Cbeck527  路  3Comments

cbednarski picture cbednarski  路  3Comments