vagrant-2.2.9
Fedora 31
Fedora Rawhide (will become Fedora 33) with openssh-8.3p1-3.fc33.x86_64 and crypto-policies-20200702-1.gitc40cede.fc33.noarch.
Any vagrantfile
vagrant up works. vagrant ssh works.
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]
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.
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_keyis 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 duringvagrant 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": [
"{{userbento_file_dir}}scripts/swap.sh",
"{{userbento_file_dir}}scripts/crypto-policies.sh",
"{{userbento_file_dir}}scripts/fix-slow-dns.sh",
"{{userbento_file_dir}}scripts/build-tools-30.sh",
"{{userbento_file_dir}}scripts/install-supporting-packages.sh",
"{{userbento_file_dir}}../_common/motd.sh",
"{{userbento_file_dir}}../_common/sshd.sh",
"{{userbento_file_dir}}../_common/virtualbox.sh",
"{{userbento_file_dir}}../_common/vmware.sh",
"{{userbento_file_dir}}../_common/parallels.sh",
"{{userbento_file_dir}}../_common/vagrant.sh",
"{{userbento_file_dir}}scripts/cleanup.sh",
"{{userbento_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
Most helpful comment
This may not be for everyone, but my team has found that incorporating
update-crypto-policies --set LEGACYin Fedora 33 vagrant box generation does successfully set the policies such that vagrant can communicate with the box during
vagrant up.