Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-01
16:12:34 bauzas clarkb: do you think it would be better to rather use rsa with sha256 ?
16:12:54 clarkb today fedora users can use those same exact rsa keys to talk to gerrit because the gerrit sshd will now negotiate with the fedora ssh client to use sha2
16:13:10 clarkb bauzas: if ou want to use rsa then ya that is he non deprecated option
16:13:49 clarkb one consideration here is fips testing. fips doesn't allow ed25519 keys. Which means you're stuck using ecdsa or rsa
16:14:04 clarkb Personally when all this started becoming a problem I switched my personal things to ed25519 as I don't care about fips at home
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

Earlier   Later