Infrastructure/fedora-infrastructure

Fork 0

SSH keys length can prevent user from login in Fedora infrastructure #7377

New issue

Closed

opened 2018-11-16 09:15:40 +00:00 by germano · 11 comments

germano commented

2018-11-16 09:15:40 +00:00

Describe what you need us to do:
Since yesterday I was unable to login into src.fedoraproject.org and pagure.io: everytime I clicked on Login button I was prompted to the same webpage, like if I pressed refresh button.
Today Patrick Uiterwijk told me that my SSH keys are too long (3 keys each related to 8196 bit private key), which means the cookie it gets all stored in is too big, and browsers ignore it.

In my humble opinion it is a design flaw, because the user is not told to not insert "too" long SSH keys

When do you need this? (YYYY/MM/DD)
Well I would have needed it now.
When is this no longer needed or useful? (YYYY/MM/DD)
I don't know
If we cannot complete your request, what is the impact?
I cannot use all my SSH keys

* Describe what you need us to do: Since yesterday I was unable to login into src.fedoraproject.org and pagure.io: everytime I clicked on Login button I was prompted to the same webpage, like if I pressed refresh button. Today Patrick Uiterwijk told me that my SSH keys are too long (3 keys each related to 8196 bit private key), which means the cookie it gets all stored in is too big, and browsers ignore it. In my humble opinion it is a design flaw, because the user is not told to not insert "too" long SSH keys * When do you need this? (YYYY/MM/DD) Well I would have needed it now. * When is this no longer needed or useful? (YYYY/MM/DD) I don't know * If we cannot complete your request, what is the impact? I cannot use all my SSH keys

pingou commented

2018-12-12 16:25:32 +00:00

Metadata Update from @pingou:

Issue tagged with: src.fp.o

**Metadata Update from @pingou**: - Issue tagged with: src.fp.o

bowlofeggs commented

2018-12-13 21:08:26 +00:00

Metadata Update from @bowlofeggs:

Issue priority set to: Waiting on Assignee (was: Needs Review)

**Metadata Update from @bowlofeggs**: - Issue priority set to: Waiting on Assignee (was: Needs Review)

linuxmodder commented

2018-12-21 01:03:42 +00:00

@germano ,

Not to discount your concern, but 8196 bit rsa keys are not 'typical' in this day and age, mostly it's 4096 or some variant of the ed25519/ecdsa/{insert ecc curve here}. You indicate having 3 keys, these are all for Fedora ??? Arguably the quickest and easiest fix to this would be to make some rsa4096 key(s) or ecc keys for Fedora uses, and return to https://admin.fedoraproject.org/accounts and browse to these new key(s) and upload and within ~ 30 or the next timed sync whichever comes first you should be able to login as desired.

Note: If you need to access any host that is still running on RHEL/CentOS 6 it will NOT work with a ecc key ( presently and likely not thru the lifecycle of those hosts from my understanding) so I'd advise rsa4096. While 8196 is nice to have most services don't natively support it, or have cookie space for them.

Hope this helps at least in expanding on puiterwijk's (Patrick) comments last week.

@germano , Not to discount your concern, but 8196 bit rsa keys are not 'typical' in this day and age, mostly it's 4096 or some variant of the ed25519/ecdsa/{insert ecc curve here}. You indicate having 3 keys, these are all for Fedora ??? Arguably the quickest and easiest fix to this would be to make some rsa4096 key(s) or ecc keys for Fedora uses, and return to https://admin.fedoraproject.org/accounts and browse to these new key(s) and upload and within ~ 30 or the next timed sync whichever comes first you should be able to login as desired. Note: If you need to access any host that is still running on RHEL/CentOS 6 it will NOT work with a ecc key ( presently and likely not thru the lifecycle of those hosts from my understanding) so I'd advise rsa4096. While 8196 is nice to have most services don't natively support it, or have cookie space for them. Hope this helps at least in expanding on puiterwijk's (Patrick) comments last week.

kevin commented

2019-04-05 19:39:53 +00:00

@pingou so we could go to OIDC on the web interface of pagure anytime? Or are we waiting for the api to be done first?

Alternately, we could try a small fas patch to reject too long ssh keys, but not sure how hard that would be or if we want to update fas.

@pingou so we could go to OIDC on the web interface of pagure anytime? Or are we waiting for the api to be done first? Alternately, we could try a small fas patch to reject too long ssh keys, but not sure how hard that would be or if we want to update fas.

cverna commented

2020-03-25 08:57:18 +00:00

Metadata Update from @cverna:

Issue tagged with: high-trouble, low-gain

**Metadata Update from @cverna**: - Issue tagged with: high-trouble, low-gain

smooge commented

2020-12-10 23:07:18 +00:00

Metadata Update from @smooge:

Issue tagged with: dev

**Metadata Update from @smooge**: - Issue tagged with: dev

pingou commented

2021-03-16 15:08:09 +00:00

@pingou so we could go to OIDC on the web interface of pagure anytime?

Technically yes

Or are we waiting for the api to be done first?

I think the hope/idea was to have both at once, but maybe we should re-consider

> @pingou so we could go to OIDC on the web interface of pagure anytime? Technically yes > Or are we waiting for the api to be done first? I think the hope/idea was to have both at once, but maybe we should re-consider

pingou commented

2021-03-16 15:11:40 +00:00

Metadata Update from @pingou:

Issue priority set to: Next Meeting (was: Waiting on Assignee)

**Metadata Update from @pingou**: - Issue priority set to: Next Meeting (was: Waiting on Assignee)

kevin commented

2021-05-17 19:27:25 +00:00

So, I see our options here:

Go ahead and move pagure.io web logins to OIDC now, close this.
Keep waiting for ipsilon work to unblock the api move, close this
Just close this won't fix for now until 1 or 2 happens
something else.

Thoughts?

So, I see our options here: 1) Go ahead and move pagure.io web logins to OIDC now, close this. 2) Keep waiting for ipsilon work to unblock the api move, close this 3) Just close this won't fix for now until 1 or 2 happens 4) something else. Thoughts?

ryanlerch commented

2021-10-12 22:55:08 +00:00

Owner

i'm

So, I see our options here:

Go ahead and move pagure.io web logins to OIDC now, close this.

Keep waiting for ipsilon work to unblock the api move, close this

Just close this won't fix for now until 1 or 2 happens

something else.

Thoughts?

There has been no response from the initial reporter since this was reported, so going to implement 3)

closing as won't fix, and it can be reopen when 1) or 2) happens. (or if the original reporter wants it open still for some reason)

i'm > So, I see our options here: > > 1) Go ahead and move pagure.io web logins to OIDC now, close this. > 2) Keep waiting for ipsilon work to unblock the api move, close this > 3) Just close this won't fix for now until 1 or 2 happens > 4) something else. > > Thoughts? There has been no response from the initial reporter since this was reported, so going to implement 3) closing as won't fix, and it can be reopen when 1) or 2) happens. (or if the original reporter wants it open still for some reason)

ryanlerch commented

2021-10-12 22:55:09 +00:00

Owner

Metadata Update from @ryanlerch: