| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-01 | |||
| 17:10:15 | clarkb | dansmith: correct | |
| 17:10:22 | dansmith | hrm | |
| 17:10:27 | clarkb | all the newer keys use hashes that are secure enough to have not been replaced | |
| 17:10:35 | clarkb | rsa didn't so has extra negotiation requirements when setting up a connection | |
| 17:10:46 | dansmith | but I thought you said the hash wasn't part of the key? | |
| 17:10:48 | clarkb | its the key exchange extensions bit of the ssh protocol | |
| 17:10:59 | clarkb | sorry correct to the first statement not to the second | |
| 17:11:10 | clarkb | this is not part of the key itself. It is part of how the key is used at connection time | |
| 17:11:15 | dansmith | because I thought even ssh'ing between two newer machines still fails with the old key | |
| 17:11:31 | clarkb | it shouldn't | |
| 17:12:23 | dansmith | that hasn't been my experience, but perhaps I was just missing what the linkage was | |
| 17:13:01 | clarkb | I think cirros + dropbear and gerrit + mina sshd may have created confusion around that? But new openssh to new opensshd should be fine | |
| 17:13:22 | dansmith | I had to enable two things over the course of the last few years: | |
| 17:13:23 | dansmith | PubkeyAcceptedKeyTypes +ssh-rsa | |
| 17:13:29 | dansmith | and | |
| 17:13:30 | dansmith | KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 | |
| 17:14:38 | dansmith | seems like the latter must be the part you're talking about | |
| 17:14:57 | dansmith | but at some point, something (one of my systems, which might have been macos) stopped even considering rsa keys | |
| 17:17:00 | dansmith | although some docs make the PubkeyAcceptedTypes sound like maybe it's not the key type? I dunno, it's just confusing (to me) :) | |
| 17:26:21 | bauzas | iiuc, it's a matter of negotiation like clarkb said | |
| 17:26:44 | bauzas | the current interim solution allows the existing keys to continue to work by asking the server to negociate with them | |
| 17:27:06 | bauzas | later, "they" could drop support of those keys and then the pubkeyacceptedtypes hint wouldn't work | |
| 17:27:43 | bauzas | the idea of that option hint is to leave a graceful period to ops to generate new keys and deliver their public ones into the servers | |
| 17:28:14 | bauzas | but like every other migration helper, people will rather use the workaround instead of migrating their keys | |
| 17:28:26 | bauzas | until the full removal arrives | |
| 17:35:24 | dansmith | bauzas: you see that documented somewhere/ | |
| 17:35:39 | dansmith | because if I read what clarkb is saying, there's nothing wrong with rsa keys themselves... | |
| 17:35:52 | bauzas | well, I need to remember that situation | |
| 17:36:20 | dansmith | back in the day, I migrated all my keys to dsa because that was "the way" and then dsa was dropped and I had to migrate back | |
| 17:36:26 | dansmith | so forgive me if I'm a bit skeptical :D | |
| 17:37:16 | clarkb | correct you should not need to generate new keys to fix this | |
| 17:37:28 | clarkb | its purely a I'm making a connection we need to negotiate details and can't agree on those details problem | |
| 17:37:29 | bauzas | https://www.rfc-editor.org/rfc/rfc8332#section-5.2 | |
| 17:38:06 | bauzas | "Nevertheless, implementations SHOULD start to disable "ssh-rsa" in their default configurations as soon as the implementers believe that new RSA signature algorithms have been widely adopted." | |
| 17:39:36 | dansmith | clarkb: so why do I need the PubkeyAcceptedTypes change? | |
| 17:40:07 | clarkb | dansmith: because ssh-rsa means sha1 | |
| 17:40:20 | clarkb | dansmith: the protocl uses something liks rsa-sha-256 to denote the sha2 varints | |
| 17:40:39 | dansmith | clarkb: so is the option really "PubkeyExchangeNegotiationTypes" ? | |
| 17:40:43 | clarkb | and the server doesn't know to negotiate rsa-sha-256 because the default when you don't know how to negotiate is ssh-rsa | |
| 17:41:24 | dansmith | like, the key is rsa, and ssh-rsa is not the key type *on disk* but the key type "in our negotiation" ? | |
| 17:41:34 | clarkb | dansmith: sort of? I think what goes on is both sides need to agree on the pubkey type they will accept. The server if old like dropbear says ssh-rsa but not rsa-sha-256. Your client is new and only says rsa-sha-256 and there is no overlp and it fails | |
| 17:42:23 | dansmith | I guess the thing that is confusing is that I consider the "type of the key" to be a property or characteristic of the content of my file on disk | |
| 17:42:44 | dansmith | but it sounds like that's not what "Pubkey .. Type" means both to ssh over the wire and in its config | |
| 17:42:57 | clarkb | correct | |
| 17:43:11 | dansmith | all I want is you to hug me and tell me I'm not crazy for finding that confusing :D | |
| 17:43:32 | clarkb | you are not crzy. When we first ran into this with gerrit and fedora making the change early there was a couple days of major head scratching | |
| 17:54:23 | sean-k-mooney | fedora used to have a tool to cofniuure thigns https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 | |
| 17:55:03 | sean-k-mooney | and yes you can use rsa-sha2-256 or rsa-sha2-512 | |
| 17:55:40 | bauzas | clarkb: you have way more background than me on this one, do you agree with me on the fact that the current pubkey hint will be later dropped, if I read carefully https://www.rfc-editor.org/rfc/rfc8332#section-5.2 ? | |
| 17:55:55 | sean-k-mooney | so you would add PubkeyAcceptedKeyTypes +rsa-sha2-256 to the sshconfig | |
| 17:56:52 | sean-k-mooney | after i had it working and then it broke with gerrit later i jsut gave in and stopped using rsa keys | |
| 17:58:29 | bauzas | sean-k-mooney: my thought was that PubkeyAcceptedKeyTypes +ssh-rsa was only a temporary workaround until all OpenSSH clients were supposed new enough to drop this compat natively | |
| 17:58:59 | sean-k-mooney | yes but you can disable his on the server side too | |
| 17:59:25 | sean-k-mooney | for gerrit it did not supprot swaping to sha2 until very recently | |
| 18:00:17 | clarkb | bauzas: what that is saying is that ssh-rsa is going away which means rsa + sha1 is going away. There are no plans to remove rsa + sha2 as far as I know | |
| 18:00:44 | bauzas | anyway, for the grenade need, generating a ecdsa key is OK | |
| 18:00:51 | sean-k-mooney | bauzas: i fyou look at https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 | |
| 18:01:00 | bauzas | clarkb: yeah that's what I found | |
| 18:01:27 | sean-k-mooney | fedor aplanned to drop rsa for key excachange in a future defualt policy that was for f33 | |
| 18:01:35 | sean-k-mooney | i think that came intor affect aroudn f35 | |
| 18:01:52 | bauzas | that's not the RSA keys which are deprecated, that's the SHA1 signature algorithm which is (hence the +o PubkeyAcceptedKeyTypes +ssh-rsa be only a temporary workaround) | |
| 18:02:01 | clarkb | sean-k-mooney: thats only rsa + sha1 | |
| 18:02:17 | sean-k-mooney | key exchange: ECDHE, DHE | |
| 18:02:23 | sean-k-mooney | under FUture | |
| 18:02:50 | clarkb | wut | |
| 18:03:17 | clarkb | oh dhe is rsa iirc | |
| 18:03:28 | sean-k-mooney | anyway it sould liek a this is related to rsa/sha1 and we shoudl be able to fix that by using a ecdsa key which will work for fips too | |
| 18:03:43 | sean-k-mooney | instead of hacking in the old key type which wont | |
| 18:05:33 | clarkb | and if anyone can grok the openssh code better than I a PR to default to rsa + sha2 as teh fallback might generate interesting conversations | |
| 18:05:34 | sean-k-mooney | so we should just replace https://github.com/openstack/grenade/blob/master/projects/70_cinder/resources.sh#L121 | |
| 18:05:46 | sean-k-mooney | with a call to ssh-keygen | |
| 18:05:50 | clarkb | the rfc suggests this happen eventually but as far as I can tell it hasn't happened yet which leads to annoying failures n a lot of cases | |
| 18:06:51 | bauzas | sean-k-mooney: patch is up to change grenade https://review.opendev.org/c/openstack/grenade/+/875940/ | |
| 18:07:09 | sean-k-mooney | cool | |
| 18:07:18 | sean-k-mooney | so ye were just discussing why this is needed | |
| 18:07:24 | bauzas | yeah | |
| 18:07:25 | sean-k-mooney | rahter then trying to find a solution | |
| 18:07:27 | sean-k-mooney | ok | |
| 18:07:29 | dansmith | yeah because I definitely didn't | |
| 18:07:30 | bauzas | well | |
| 18:07:47 | bauzas | we are trying to untangle the oddness of ssh negociation | |
| 18:07:48 | dansmith | and I have a bunch of hacks in my own ssh_config that probably need revisiting now that more of my systems are upgraded | |
| 18:07:56 | bauzas | me too | |
| 18:08:10 | bauzas | this discussion is half-workwise, halp-personalwise | |
| 18:08:14 | sean-k-mooney | ok i got burned by this years ago and have helped other fix it in the past so i mostly just accpet it at this point | |
| 18:08:36 | bauzas | I just shamelessly tuned the signature negociation on the fly with my ssh_config | |
| 18:09:04 | bauzas | as I didn't wanted to generate a new pair of ECDSA or something else keys | |
| 18:09:15 | sean-k-mooney | ya i still have PubkeyAcceptedKeyTypes +ssh-rsa for one site in my config | |
| 18:09:20 | sean-k-mooney | but i think thats offline | |
| 18:09:41 | bauzas | but now if I understand correctly, I could rather continue to use my RSA keys but ask for a different signature | |
| 18:09:58 | sean-k-mooney | i also still have | |
| 18:10:01 | sean-k-mooney | host review.opendev.org | |
| 18:10:01 | bauzas | using rsa-sha2 | |
| 18:10:03 | sean-k-mooney | HostKeyAlgorithms ssh-rsa | |
| 18:10:05 | sean-k-mooney | KexAlgorithms +diffie-hellman-group1-sha1 | |
| 18:10:07 | sean-k-mooney | Ciphers +aes128-cbc | |
| 18:10:12 | sean-k-mooney | for some reason witch i relly dont need | |
| 18:10:46 | clarkb | bauzas: correct. The problem is that some servers don't know how to negotiate that with you like old dropbear and old gerrit | |
| 18:10:49 | sean-k-mooney | thats what i treid when PubkeyAcceptedKeyTypes +ssh-rsa stopped working for gerrit | |
| 18:11:17 | bauzas | clarkb: so the per-host config is still required, gotcha | |