OS is Redhat 6.2 (with many updates) previously running OpenSSH 3.4p1 with default settings with no problems. I'm installing by extracting the openssh.spec file and building my own RPM's. On updating to either 3.7p1 or 3.7.1p1 I can no longer log in using SecureCRT and Password authentication. All messages and debugging information claim the password is wrong when it is not. I've tried both SecureCRT V3.1, and V4.08, with no change. Logging in from another Linux box using the openssh ssh client (3.4p1) *DOES* work. After spending many hours trying different configuration options I'm completely stumped. I've attached two attachments, one is a debug report from sshd from the old version showing a successful connection from Secure CRT the other from 3.7.1p1 showing an unsuccessful connection. I can provide more information if necessary. (At this point, I don't know what information might help)
Created attachment 404 [details] Successful login with V3.4p1 This is the output of sshd -d -d -d of V3.4p1 following a successful login from SecureCRT V3.1
Created attachment 405 [details] Unsuccessful login with V3.7.1p1 This is the output of sshd -d -d -d of V3.7.1p1 following an unsuccessful login from SecureCRT V3.1
Opps. That second attachment should say UNsuccessful login with V3.7.1p1
Does it work for a non-root account? What do you get if you run sshd with "-o PermitRootLogin=yes"?
No, it doesn't work for a non root account either. Using -o PermitRootLogin=yes doesn't help either, although I should point out I already have this in my sshd_config. Also in my sshd_config are: PasswordAuthentication yes UseLogin yes UsePrivilegeSeparation yes Compression no As I mentioned, using the openssh ssh client from another Linux box *can* log in using password authentication both as root or non root, and yet SecureCRT cannot. I've tried both ssh1 and ssh2 in SecureCRT, with no results. As an extra data point I just tried using Putty V0.51, and the result is "Access denied" after entering the password. Reverting to 3.4p1 allows both SecureCRT and Putty to log in ok. I'm at a loss to explain why the openssh ssh client can connect to both versions.
I had the same problem. Try rebuilding with the configuration option --with-md5- passwords. That worked for me.
Well that worked. Since I'm building RPM's theres no easy way to force the use of md5 over pam without choosing a rescue disk build, so I hacked the .spec file to use md5 and the resulting RPM's allow me to log in ok. (Our systems can use either MD5 directly or PAM) It looks like the PAM support in this release is broken, (at least on some configurations) as using MD5 is only a workaround... At least I don't have to keep using a vulnerable version now...
>It looks like the PAM support in this release is broken, (at least on some >configurations) as using MD5 is only a workaround... I'm not seeing how --with-md5-password implies broken --with-pam. Pam is now a run-time option. Therefor if you do 'UsePam no' it will failback to trying to handle the /etc/shadow password directly. If you use md5.. you need to tell OpenSSH about it.
>I'm not seeing how --with-md5-password implies broken --with-pam. Pam is now >a run-time option. Therefor if you do 'UsePam no' it will failback to trying >to handle the /etc/shadow password directly. Not sure I understand your comment, or that it even makes sense. For me, PAM authentication no longer works when it worked fine under 3.4p1. Thats why I refer to it as broken. (Please see my attached debug output) UsePam no in sshd_config did not help either. > If you use md5.. you need to >tell OpenSSH about it. Well we use PAM, its only because PAM support isn't working that I resorted to trying MD5 support. How exactly is one supposed to enable MD5 support when building RPM's ? The supplied openssh.spec file doesn't provide a way to do it without hacking the SPEC as I did. At the end of the day, the PAM support is still broken in 3.7.1p1 on my systems...(I've had a couple of emails from people saying they're also having the same problem)
A workaround: securecrt-->properties-->authentication-->TIS Correct method or not, I've seen it work fine for both putty and securecrt.
The MD5 specfile thing was fixed in bug #714 to always enable --with-md5-passwords. If you built with PAM, you should probably have either either PasswordAuthentication or UsePAM enabled but not both. Note that using PAM will need ChallengeResponseAuthentication enabled, and this means that the client will need to use keyboard-interactive (SSHv2) or TIS authentication (SSHv1).
Mass change of RESOLVED bugs to CLOSED