Today I experienced a rather strange problem with SSH authentication. Someone in the company where I am working today, requested a password change for his account on some machine. Because the account is used by different persons, I asked him to give me the original password. Of course I first tested the username and password combination myself, and I was actually able to login with it.

There appeared nothing in syslog about an authentication failure whenever he tried to login from his laptop, so at first I thought there was something wrong with DNS, or his hosts file. So we tried connecting on the IP of the server. Same problem. Double checked with tcpdump if the server actually received anything from his machine, which also was the case. Because I was testing with OpenSSH client, from a Linux machine, and he used PuTTY on a Windows machine, I tried with PuTTY from the Windows Workstation I have available here. Again, no problem. Then I though it might be a simple case of PEBKAC, so I tried logging in from his machine, and type the password myself. No PEBKAC, again authentication failure. So, I ended up enabling logging of SSH packets in PuTTY. Tried again. The log showed something about using SSH protocol 1. Changed the PuTTY config to use SSH2, et voila, authentication successful. Of course I tested from my laptop again, forcing SSH protocol 1. No problem, authentication still succeeded. Updated the PuTTY to the latest version, tried again with protocol 1, same problem. So, is this a bug in PuTTY, or in the OpenSSH daemon that comes with SLES10 SP1? No idea, I wonder ... Will do some more testing to get this figured out, so I can report a bug on the correct bug tracker :-)