-
Notifications
You must be signed in to change notification settings - Fork 463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support RSA SHA-2 (RFC8332) signatures for SSH authentication #916
Comments
I can confirm that the use of an ed25519 key type resolves the connection issue for me. I just created a new keypair with ssh-keygen -t ed25519 (no passphrase) You then need to specify the new key in the URI uri = "qemu+ssh://user@server/system?keyfile=/home/localuser/.ssh/id_ed25519" |
Same problem with a Fedora 35 client to a CentOS Stream 9 server. Using an ed25519 key also fixed the issue for me. |
@davidalger thanks for the detailed report. I will look into it. |
I have pushed a v0.6.13 with upgraded golang.org/x/crypto Let me know if upgrading helps. Otherwise I will look deeper in the ssh client settings. |
It hasn't changed the behaviour for me on zorin os 16 & Terraform v1.1.4 on linux_amd64
This URI Works This one doesn't ╷ |
I'm also still seeing the error with v0.6.13. |
@dmacvicar Thanks for updating that lib. Unfortunately doesn't seem to resolve it, still get the same err:
with the following showing up in the sshd log on the server side:
The relevant changes should be included based on the new version pinned in the |
I was able to reproduce locally and after hours trying to wrap the Signer APIs, I figured out the missing patches that haven't been merged yet. If you know how to build locally, you can build the ssh-rsa-fix branch of #925 and use a
If I can get some feedback, I'd release it as soon as possible. |
I've built the |
Thanks @tdcook. I will wait for a bit of more feedback and then do a release. |
@dmacvicar Built and tested, issue solved here as well with the patched Crypto lib. It successfully authenticated via SSH using my encrypted RSA key loaded into ssh-agent. Hopefully those patches will be merged upstream soon so you don't have to maintain a patched fork for this to work. 🤞🏻 |
The fork adds the following patches: - ssh: add support for extension negotiation (rfc 8308) golang/crypto#197 - ssh: use extension negotiation (rfc 8308) in ssh clients rmohr/crypto@e4ed966 Closes: #916 Closes: #886
Thanks everyone for the input: https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.6.14 should be available in the registry soon. |
Thanks Duncan,
I can confirm that this fixes my issue - thanks again.
Brynn
…On Mon, 31 Jan 2022 at 22:43, Duncan Mac-Vicar P. ***@***.***> wrote:
Thanks everyone for the input:
https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.6.14
should be available in the registry soon.
—
Reply to this email directly, view it on GitHub
<#916 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFRYNIRRU2UFVFNVMC7WA7LUY4GCLANCNFSM5K6JC63A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hi there, I stumbled upon this when attempting to remote instance with SSH - not sure if related. Using 0.6.14 provider. The following was failing for me. provider "libvirt" {
uri = "qemu+ssh://user@host/system?keyfile=/home/user/.ssh/id_ed25519"
} │ Error: failed to dial libvirt: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
│
│ with provider["registry.terraform.io/dmacvicar/libvirt"],
│ on provider.tf line 8, in provider "libvirt":
│ 8: provider "libvirt" { I needed to add sshauth=privkey in uri and then it was able to connect. provider "libvirt" {
uri = "qemu+ssh://user@host/system?keyfile=/home/user/.ssh/id_ed25519&sshauth=privkey"
} |
I had to do that too, however I didn't see it as an error - just a required configuration step. |
I dunno if i'm doing anything wrong. I'm using v0.6.14. Tried all permutations of the URI (with and without sshauth and keyfile). Nothing worked. I can, definitely, login with my passowrd protected key. Terraform doesn't work, though. I generated the key with: The key is in the keyring. Fedora 35 here.
|
@renich can you login with your password protected key without entering a password? the provider would not work with a password protected key unless you are using the agent. |
yes; of course. I've been using this key for years.
Well, I am using the agent. Using Fedora 35 with GNOME. The agent is configured by default. This is why I listed my keys beforehand. Let me know if there are any commands you want me to try in order to prove it or help debug this further. |
Just ran into this issue. I'm wondering whether golang/crypto@master...dmacvicar:master could be contributed upstream so that other projects benefit from it. |
Same here (Fedora 35). As a workaround i ended up by disabling known hosts verification by using
|
This totally works but it's odd. I can ssh to that host without issues. It's present in |
I am using terraform version: 0.12.14 Any guidance is appreciated. |
System Information
Linux distribution
This affects systems were the remote server is running Fedora 33, 34, 35, CentOS Stream 9 and RHEL 8 with FIPS.
Terraform and provider versions
Description of Issue/Question
Attempting to connect to any of the affected OpenSSH configurations — in my case, default Fedora 34 ssh config — RSA based ssh authentication will fail with the error
failed to dial libvirt: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
and the servers sshd.log will report the following:Fedora 33 updated the system-wide crypto policy to disallow SHA-1 hashes in signatures and OpenSSH 8.8 (released on 2021-09-26) disables the ssh-rsa signature scheme by default as well (http://www.openssh.com/txt/release-8.7) so the change will eventually trickle into other Linux families as well if it hasn't already. 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.
This explains why it was reported that ed25519 keys worked with ssh-agent support added in 0.6.11 while RSA keys continued to fail (#864 (comment)) as the commenter indicated (in previous comment) he was testing with a Fedora 34 server, one which would have
ssh-rsa
disabled by default.Setup
Steps to Reproduce Issue
Terraform debug output:
sshd.log from the server showing why the handshake failed
Additional information:
This may be the root cause for some of the issues noted in #886
Possible solution:
Crypto packages should now support RSA SHA-2 (RFC8332) signatures, so upgrading may be all that is needed to support them. Please see golang/go#37278.
For now I'm going to workaround the issue by adding an ed25519 key to my agent, allowing the plan to succeed:
The text was updated successfully, but these errors were encountered: