Add support for ed25519_sk and ecdsa_sk SSH keys

[artemist]

Fixes #11203
OpenSSH 8.2 or higher supports storing SSH keys on standard U2F keys using two new key types, one for P-256 ECDSA and one for ed25519 EdDSA. The Go built-in SSH server and OpenSSH server 8.2 or higher support these new types as client authentication keys. This PR allows users to specify these new key types as their SSH auth keys. I have tested that I am able to connect to gitea using both the built-in SSH server and OpenSSH server 8.3.

[artemist]

The build test failure appears to be because the Docker container golang:1.15 uses Debian buster, which has OpenSSH 7.9, while OpenSSH 8.2 is required for support. I'm not sure how to workaround this cleanly.

[silverwind]

OpenSSH 8.2 is required for support.

Probably need to detect OpenSSH version in the test and skip if too old.

[mrsdizzie]

IMO these changes are very minimal and don't touch any existing logic. These tests could just be commented out until it is possible to run them in the future with the golang container we use.

Don't need to add extra code to detect a particular version of openssh if the version in our CI is always going to be too low and they will never run anyway.

[zeripath]

do we know if this very old version of ssh will always show a help page on ssh-keygen --help that includes the text:

                  [-t dsa | ecdsa | ed25519 | rsa]

?

If so it would be possible to parse this line and determine what keys ssh-keygen would accept.

[zeripath]

Arguably we'd be better off figuring out what things the SSH would accept.

[silverwind]

One can get a list of supported key types via ssh -Q key:

$ ssh -Q key
ssh-ed25519
[email protected]
[email protected]
[email protected]
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

[zeripath]

that's ssh not sshd.

[silverwind]

Can't we just assume they are from the same package for the purpose of tests?

[zeripath]

even if they are the same package - just because the ssh command will offer these keys and has support for them does not mean that the sshd will accept them. It's entirely possible to set them differently - and quite common - for example note that your ssh -Q has reported ssh-dss - I would not be surprised if your sshd did not support ssh-dss.

[silverwind]

Maybe search the manpage? 😆

$ man sshd | grep "supported key" -A10
     is optional.  The supported key types are:

           [email protected]
           ecdsa-sha2-nistp256
           ecdsa-sha2-nistp384
           ecdsa-sha2-nistp521
           [email protected]
           ssh-ed25519
           ssh-dss
           ssh-rsa

[silverwind]

Should we disable the failing tests as per #13462 (comment)?

[mscherer]

Isn't that a way to see what is supported:

$ ssh -vvv 127.0.0.1 id 2>&1 |grep 'host key algorithms'

It return 2 lines and the 2nd one is the remote supported keys after the key negociation:

debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

I tested on a Debian and a RHEL 7, and indeed and it doesn't return the same lines: (for the 2nd line)

debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa

So wouldn't it be sufficient ?

[zeripath]

#13462 (comment) is probably the only way we can get t
autodetection working but I suspect even that is not going to work for every case - (for example it could easily be that you can't reach the SSH server from the Gitea or it's firewalled off.)

I think we might just have to have a set a of allowed types configured manually, (or at least some way of falling back to this.)

Probably can just reuse the SSH server settings already provided for the internal SSH server for this and we can try to add an autodetection option in some other pr. I guess that just means the best way of moving this PR forward is to comment out the tests or make it recognise the settings disallowing it.

[mscherer]

I only suggested autodetection for the tests, to implement the suggestion on #13462 (comment)

E.g., we can detect what is supported on the platform with a ssh connection, and test only those type of keys. If we can't connect by ssh during the tests, they would fail anyway no matter what keys we try.

[zeripath]

OK I've updated the test to just skip it

[zeripath]

@lafriks do we know if our docker openssh supports ed25519_sk, ecdsa_sk keys?

[lafriks]

We now have alpine 3.13 that has OpenSSH 8.4 so it should support it