When attempting a ssh connection using a recent client and recent server but old or non-openssh agent, the ssh client will request rsa-sha2-256/512 signatures from the agent unconditionally (since there is no way for an agent to explicitly signal support for them). The agent signature request and authentication attempt will therefore fail. Maybe we should fall back to attempting the classic ssh-rsa style signature for now?
Created attachment 2814 [details] fall back to olde-style signatures when agent fails to sign neue one
This works, but the verbose output makes it seem like it's still using rsa-sha2-512 which is misleading: debug1: matching key found: file /home/tester/.ssh/authorized_keys, line 5 RSA SHA256:.... debug1: restore_uid: 0/0 debug1: do_pam_account: called Accepted publickey for kenny from 127.0.0.1 port 44220 ssh2: RSA SHA256:.... debug1: monitor_child_preauth: tester has been authenticated by privileged process debug2: userauth_pubkey: authenticated 1 pkalg rsa-sha2-512 [preauth] debug1: monitor_read_log: child log fd closed debug1: temporarily_use_uid: 31337/31337 (e=0/0) debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism debug1: restore_uid: 0/0 debug1: PAM: establishing credentials User child is on pid 8418 debug1: SELinux support enabled debug1: PAM: establishing credentials debug1: permanently_set_uid: 31337/31337
retarget unfinished bugs to next release
OpenSSH 7.4 release is closing; punt the bugs to 7.5
Move incomplete bugs to openssh-7.6 target since 7.5 shipped a while back. To calibrate expectations, there's little chance all of these are going to make 7.6.
remove 7.5 target
De-targetting this until I figure out how best to deal with it. Silently (or even noisily I think) falling back isn't ideal either
We have someone who is getting an RSA failure beginning with 7.4p1 with the 3 regression patches backported from 7.5.1 He is using multiple auth methods -- I noticed there was a fix for that in 7.4p1, but his working RSA pubkey broke when going from 7.3 to 7.4p1 The error messages, debug messages (both client and server), syslogs etc we are getting are not useful, but a very old ldap may be involved. ssh-agent is not in use, but this bug says "agent" not ssh-agent. Should I try to test this patch to see if it helps?
Is there anything in particular that keeps this problem from being addressed? It really is quiet annoying as it prevents me from using key-based-authentication on a daily basis. I encounter this when connecting from Android (ConnectBot app) to an Ubuntu 16.04.3 desktop (with agent forwarding) and then from there to an Ubuntu 16.04.3 server.
This is just a top of the iceberg. There are two issues with ssh-agent and SHA2 signatures. The agent either * Does not support SHA2 and fails, which is sane behavior (usability concerns) * Does not support SHA2, but provides SHA1 signature (silently) and it is accepted by both client and server as I reported as a bug #2799 (security concerns) There is ssh-agent extension negotiation protocol, but the problem is that it is not understood by most of the agents so implementation would need to take care of these cases too.
(In reply to Jakub Jelen from comment #13) > * Does not support SHA2, but provides SHA1 signature (silently) and > it is accepted by both client and server as I reported as a bug > #2799 (security concerns) Well, I'm not asking it to "silently" accept SHA1 signatures. I would find an option with a secure default acceptable. Also, I don't see how falling back from SHA2 to SHA1 reduces security when the server did accept SHA1's in the first place if the client negotiated them. This issue is about the case where client and server negotiate SHA2 but then the agent fails to sign because it does not support SHA2.
(In reply to Sebastian Unger from comment #14) > (In reply to Jakub Jelen from comment #13) > > * Does not support SHA2, but provides SHA1 signature (silently) and > > it is accepted by both client and server as I reported as a bug > > #2799 (security concerns) > Well, I'm not asking it to "silently" accept SHA1 signatures. I > would find an option with a secure default acceptable. Also, I don't > see how falling back from SHA2 to SHA1 reduces security when the > server did accept SHA1's in the first place if the client negotiated > them. I am not asking to accept SHA1 silently either. The security problem is that client and server negotiated SHA2 mechanisms, the client sends envelope labeled with SHA2 mechanisms, but inside it is just SHA1. That is the problem. > This issue is about the case where client and server negotiate SHA2 > but then the agent fails to sign because it does not support SHA2. That would be solved by the extension negotiation with the ssh-agent.
a fix for this is included in the patch at https://bugzilla.mindrot.org/show_bug.cgi?id=2799
This was fixed by the following commits and will be in OpenSSH 7.8: commit 314908f451e6b2d4ccf6212ad246fa4619c721d3 Author: djm@openbsd.org <djm@openbsd.org> Date: Wed Jul 4 13:51:45 2018 +0000 upstream: deal with API rename: match_filter_list() => match_filter_blacklist() OpenBSD-Regress-ID: 2da342be913efeb51806351af906fab01ba4367f commit 89f54cdf6b9cf1cf5528fd33897f1443913ddfb4 Author: djm@openbsd.org <djm@openbsd.org> Date: Wed Jul 4 13:51:12 2018 +0000 upstream: exercise new expansion behaviour of PubkeyAcceptedKeyTypes and, by proxy, test kex_assemble_names() ok markus@ OpenBSD-Regress-ID: 292978902e14d5729aa87e492dd166c842f72736 commit 312d2f2861a2598ed08587cb6c45c0e98a85408f Author: djm@openbsd.org <djm@openbsd.org> Date: Wed Jul 4 13:49:31 2018 +0000 upstream: repair PubkeyAcceptedKeyTypes (and friends) after RSA signature work - returns ability to add/remove/specify algorithms by wildcard. Algorithm lists are now fully expanded when the server/client configs are finalised, so errors are reported early and the config dumps (e.g. "ssh -G ...") now list the actual algorithms selected. Clarify that, while wildcards are accepted in algorithm lists, they aren't full pattern-lists that support negation. (lots of) feedback, ok markus@ OpenBSD-Commit-ID: a8894c5c81f399a002f02ff4fe6b4fa46b1f3207 commit 303af5803bd74bf05d375c04e1a83b40c30b2be5 Author: djm@openbsd.org <djm@openbsd.org> Date: Tue Jul 3 11:43:49 2018 +0000 upstream: some magic for RSA-SHA2 checks OpenBSD-Regress-ID: e5a9b11368ff6d86e7b25ad10ebe43359b471cd4 commit 7d68e262944c1fff1574600fe0e5e92ec8b398f5 Author: Damien Miller <djm@mindrot.org> Date: Tue Jul 3 23:27:11 2018 +1000 depend commit b4d4eda633af433d20232cbf7e855ceac8b83fe5 Author: djm@openbsd.org <djm@openbsd.org> Date: Tue Jul 3 13:20:25 2018 +0000 upstream: some finesse to fix RSA-SHA2 certificate authentication for certs hosted in ssh-agent OpenBSD-Commit-ID: e5fd5edd726137dda2d020e1cdebc464110a010f commit d78b75df4a57e0f92295f24298e5f2930e71c172 Author: djm@openbsd.org <djm@openbsd.org> Date: Tue Jul 3 13:07:58 2018 +0000 upstream: check correct variable; unbreak agent keys OpenBSD-Commit-ID: c36981fdf1f3ce04966d3310826a3e1e6233d93e commit 2f30300c5e15929d0e34013f38d73e857f445e12 Author: djm@openbsd.org <djm@openbsd.org> Date: Tue Jul 3 11:42:12 2018 +0000 upstream: crank version number to 7.8; needed for new compat flag for prior version; part of RSA-SHA2 strictification, ok markus@ OpenBSD-Commit-ID: 84a11fc0efd2674c050712336b5093f5d408e32b commit 4ba0d54794814ec0de1ec87987d0c3b89379b436 Author: djm@openbsd.org <djm@openbsd.org> Date: Tue Jul 3 11:39:54 2018 +0000 upstream: Improve strictness and control over RSA-SHA2 signature In ssh, when an agent fails to return a RSA-SHA2 signature when requested and falls back to RSA-SHA1 instead, retry the signature to ensure that the public key algorithm sent in the SSH_MSG_USERAUTH matches the one in the signature itself. In sshd, strictly enforce that the public key algorithm sent in the SSH_MSG_USERAUTH message matches what appears in the signature. Make the sshd_config PubkeyAcceptedKeyTypes and HostbasedAcceptedKeyTypes options control accepted signature algorithms (previously they selected supported key types). This allows these options to ban RSA-SHA1 in favour of RSA-SHA2. Add new signature algorithms "rsa-sha2-256-cert-v01@openssh.com" and "rsa-sha2-512-cert-v01@openssh.com" to force use of RSA-SHA2 signatures with certificate keys. feedback and ok markus@ OpenBSD-Commit-ID: c6e9f6d45eed8962ad502d315d7eaef32c419dde
Close RESOLVED bugs with the release of openssh-8.0