Incorrect determinition of rsa-sha-* signatures support

[vladimirlagunov]

Steps to reproduce

1. Get an Arch Linux. It has the freshest OpenSSH server.

   docker run -ti --rm -p 2222:22 archlinux:base-devel-20211017.0.36769
   

2. Ensure that OpenSSH server version is OpenSSH_8.8p1, OpenSSL 1.1.1l 24 Aug 2021:

   pacman -Sy core/openssh
   /usr/sbin/sshd -h
   

3. On the client, create a new RSA key:

   ssh-keygen -N 12345 -t rsa -f ~/.ssh/delete_me_rsa_pass_12345
   cat ~/.ssh/delete_me_rsa_pass_12345.pub   # or: type ~\.ssh\delete_me_rsa_pass_12345.pub
   

4. Authorize the key on the server:

   mkdir /root/.ssh
   cat > /root/.ssh/authorized_keys   # paste the public key, then Ctrl+D
   chmod -R go-rwx /root/.ssh
   

5. Generate a host key of any type except RSA:

   ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -t ed25519 -N ''
   

6. Launch the server:

   /usr/sbin/sshd -D -e -o PermitRootLogin=yes -o AuthenticationMethods=publickey -o HostKey=/etc/ssh/ssh_host_ed25519_key -o LogLevel=DEBUG2
   

7. Ensure that you can connect to the server via OpenSSH:

   ssh -i ~/.ssh/delete_me_rsa_pass_12345 -p 2222 -o StrictHostKeyChecking=no root@localhost cat /etc/issue
   

8. Try to connect to root@localhost:2222 with a simple SSHJ-based application, like Exec.java from the examples.

Expected result

SSHJ connects successfully.

Actual result:

Connection failed.

---

It happens because SSHJ enabled rsa-sha-512 only if a server proposes a host key of type RSA. If the host key type from the instruction changed from ed25519 to rsa, SSHJ would work with the server.

Instead of testing with OpenSSH 8.8, any older OpenSSH version may be used, but then the server should have an option PubkeyAcceptedAlgorithms=-ssh-rsa

Of course, OpenSSH can connect to such server. However, OpenSSH won't connect if a server prohibits rsa-sha2-* keys (which is a strange scenario, but still possible).

I propose to remove the heuristic based on the host key, and add an analog of PubkeyAcceptedAlgorithms, which would allow enabling and disabling any possible signatures, including ssh-rsa, rsa-sha2-256, rsa-sha2-512.

[vladimirlagunov]

Going to fix it. Also, I remember I promised testcontainers in #733. It's almost done Done: #741. I think it would be difficult to make a test for this bug using the current integration tests infrastructure.

[hierynomus]

@vladimirlagunov Just to check, this is now solved with the 2 MRs from yesterday, right?

[vladimirlagunov]

Not yet, I'm working on it now.

[ylangisc]

We have updated to the latest version of sshj in Cyberduck and now there are reports that pubkey auth with RSA keys does not work anymore, e.g. iterate-ch/cyberduck#12733.

This is caused by the removed heuristic based on the host key algorithms sent by the server. For older servers without support for rsa-sha2-* a connection is not possible anymore as in SSH_MSG_USERAUTH_REQUEST the pubkey algorithm rsa-sha2-512 is chosen due to its position in the config list. To invoke #prioritizeSshRsaKeyAlgorithm would resolve the issue but is not an option as we don't know in advance what kind and version of server the user connects to. This would break the client for new server without ssh-rsa support. A workaround could be to try with and without #prioritizeSshRsaKeyAlgorithm but IMO this should be handled by the library.

As we cannot rely on the SSH extension SSH2_MSG_EXT_INFO/server-sig-algs I would suggest to repeat the SSH_MSG_USERAUTH_REQUEST request with all possible pubkey algorithms for a specific key type, e.g. ssh-rsa, rsa-sha2-256, rsa-sha2-512 for RSA keys. That's the way it's done in the MINA client btw. Refer to https://issues.apache.org/jira/browse/SSHD-1105.