I have been using OpenSSH clients against a number of embedded SSH servers with no problem up till now. Starting with version 6.4p1 password authentication has stopped working against such servers. What happens is that the client enters an infinite loop during the authentication phase. I built OpenSSH 5.9p1 and 6.4p1 in a Linux box so that the client prints out to the screen all of the SSH messages sent to, and received from, the server. What follows is a condensed account of my observations based on the output generated by the 5.9p1 and 6.4p1, respectively, displaying only the relevant data. The output is organized in two columns. The left column contains the messages sent by the client, and the right column contains the messages sent by the server. Time is assumed to flow from top to bottom, so the message exchange ordering may be immediately noticed. The output is constrained to the authentication phase, after the session keys have been derived by both parties, and before any channels are opened. The asymmetric keys and user name are exactly the same in both cases. OpenSSH client 5.9p1 Embedded SSH server SSH_MSG_USERAUTH_REQUEST Method name: none SSH_MSG_USERAUTH_FAILURE Supported auth. methods: password, publickey Partial success Boolean: FALSE SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: FALSE SSH_MSG_USERAUTH_PK_OK SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: TRUE SSH_MSG_USERAUTH_FAILURE Supported auth. methods: password, publickey Partial success Boolean: TRUE SSH_MSG_USERAUTH_REQUEST Method name: password Boolean: FALSE SSH_MSG_USERAUTH_SUCCESS After this the client opens a channel and the interactive session gets established. OpenSSH client 6.4p1 Embedded SSH server SSH_MSG_USERAUTH_REQUEST Method name: none SSH_MSG_USERAUTH_FAILURE Supported auth. methods: password, publickey Partial success Boolean: FALSE SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: FALSE SSH_MSG_USERAUTH_PK_OK SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: TRUE SSH_MSG_USERAUTH_FAILURE Supported auth. methods: password, publickey Partial success Boolean: TRUE SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: FALSE SSH_MSG_USERAUTH_PK_OK SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: TRUE SSH_MSG_USERAUTH_FAILURE Supported auth. methods: password, publickey Partial success Boolean: TRUE SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: FALSE SSH_MSG_USERAUTH_PK_OK SSH_MSG_USERAUTH_REQUEST Method name: publickey Boolean: TRUE SSH_MSG_USERAUTH_FAILURE Supported auth. methods: password, publickey Partial success Boolean: TRUE The first six messages exchanged are identical in both cases, as far as their payloads are concerned. However, after the sixth message (an SSH_MSG_USERAUTH_FAILURE sent by the server) things change dramatically. The 5.9p1 client at that point gives up attempting public-key-based authentication, falling back on to password authentication. This is as it should be, for there is no public key for this particular user in the server. On the other hand, at the same point in the exchange the 6.4p1 client sends another public key authentication request, this time, like the very first one, with the Boolean field set to FALSE. This is the start of the infinite loop on the client side, which just prints out the 'Authenticated with partial success.' line ad infinitum, without ever prompting the person at the keyboard for a password. The loop is in the last four messages depicted in the traces above. Why is the 6.4p1 client attempting to probe for public key authentication again, when the server has already indicated that the public key received will not authenticate the user? In every SSH_MSG_USERAUTH_REQUEST that contains a public key (an RSA one, in this case) the client always sends the same public key. As it happens, should there be a matching public key for that user in the server, the authentication phase succeeds and the interactive session gets established without any issues. I am hoping that this is a bug in the OpenSSH 6.4p1 code (and later - at least, the same seems to be true of 6.6p1) that is tickled by the embedded server (things work fine against OpenSSH servers) for it would be far easier to change SSH client than fixing the server. However, a reading of RFC 4252 seems to indicate that the 6.4p1 client is not doing the right thing here, but I may be misinterpreting the RFC. Hopefully experts in this forum will be able to clarify this situation one way or the other. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev