Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-01
16:14:32 bauzas clarkb: ok, then your preference would be "-t rsa -E sha256 " correct ?
16:14:39 bauzas for ssh-keygen
16:14:51 clarkb bauzas: the sha version shouldn't matter at keygen time its all dynamic protocol negoatiation
16:15:47 clarkb bauzas: is this talking to cirros?
16:16:22 clarkb if so cirros' dropbear server may not support sha2 negotiation which would be a similar problem to what we addressed in Gerrit
16:17:12 bauzas clarkb: context https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f59/875773/3/check/grenade-skip-level-continuous/f597bdf/controller/logs/grenade.sh_log.txt
16:17:49 bauzas clarkb: coming from https://github.com/openstack/grenade/blob/master/projects/70_cinder/resources.sh#L186 failing
16:18:01 clarkb ya thats cirros. And the test node must be jammy?
16:18:02 bauzas we generate ssh-rsa keys by default with jammy
16:18:07 bauzas yup
16:18:46 clarkb I think your options are: use newer cirros with newer dropbear, use ecdsa/ed25519 key if dropbear supports these, explicitly override configs to allow rsa + sha1 on the jammy side to talk to dropbear that only knows this combo
16:19:49 clarkb Part of the problem here is that when everyone deprecated sha1 they kept the fallback default in protocol negotiation as rsa + sha1 despite knowing it will not work. It would've been better if they updated the fallback default to be rsa + sha2 which would have worked with gerrit its only problem was understanding how to negotiate things, not lack of sha2 support
16:21:39 clarkb dropbear version 2020.79 added support for both ed25519 keys and rsa sha2
16:22:40 clarkb the easiest thing is probably using ecdsa keys and that would also satisfiy fips
16:27:53 bauzas clarkb: cool, then
16:33:07 opendevreview Alexey Stupnikov proposed openstack/nova stable/train: reenable greendns in nova. https://review.opendev.org/c/openstack/nova/+/833438
17:08:21 gmann bauzas: thanks for RBAC things in prelude. I will check
17:08:29 bauzas cool
17:09:54 dansmith clarkb: okay, so you're saying the different key type ends up using a different hash algo in the negotiation and that's what sidesteps the problem?
17:09:58 dansmith I thought it was the key type itself
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

Earlier   Later