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 lavabit/robox#173, but always get reinitialized to DEFAULT during first vagrant up. May you share some hints about your successful story?

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

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

dunno whether it should have done - probably not - but this workaround didn't make it into the fedora 33 cloudbase amis (eg ami-0edca001b0a05f840)

The Fedora cloud images uploaded to AWS aren't specific to vagrant so they weren't updated to workaround this problem.

Hi everyone,

I was confused on why this was still an issue with the net-ssh backports in place to support the rsa-sha2-256 (and 512 variant) signatures. There is no issue with RSA keys so long as they are SSH2 keys, not SSH1. From the OpenSSH release notes (https://www.openssh.com/txt/release-8.5):

Note that the deactivation of "ssh-rsa" signatures does not necessarily
require cessation of use for RSA keys. In the SSH protocol, keys may be
capable of signing using multiple algorithms. In particular, "ssh-rsa"
keys are capable of signing using "rsa-sha2-256" (RSA/SHA256),
"rsa-sha2-512" (RSA/SHA512) and "ssh-rsa" (RSA/SHA1). Only the last of
these is being turned off by default.

In fact, we can see this is actually the case by removing ssh-rsa from the PubkeyAcceptedKeyTypes (assuming a fedora 33 box with config update applied to allow ssh-rsa), reload the sshd and then run:

> vagrant provision

When a provision script is attempted to be run by Vagrant, we see that there's an error connecting. However, if we run:

> vagrant ssh

We can connect as expected. This means that as far as OpenSSH is concerned, the RSA keys we are attempting to use are in fact valid. The vagrant ssh command uses the OpenSSH ssh client under the hood but vagrant provision uses the SSH communicator plugin which is built on the net-ssh library. That meant that something has changed with how the OpenSSH client is doing authentication that the net-ssh library is not doing.

After digging through a bunch of code in the net-ssh library, the OpenSSH source, and some of the OpenSSL source I happened upon this commit:

openssh/openssh-portable@d1e578a

wherein the client has been updated to send the signature algorithm in the USERAUTH_REQUEST, not the key type. Applying some quick modifications to the net-ssh source for RSA public key authentication resulted in successful authentication and the end results are the modifications found in #12298. These changes will be included in the next release and will resolve this issue.

Cheers!

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.