openssh bugs - Sep 2003 - [Bug 648] Cannot login using SecureCRT since openssh 3.7p1

http://bugzilla.mindrot.org/show_bug.cgi?id=648

           Summary: Cannot login using SecureCRT since openssh 3.7p1
           Product: Portable OpenSSH
           Version: -current
          Platform: ix86
        OS/Version: Linux
            Status: NEW
          Severity: critical
          Priority: P2
         Component: sshd
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: simon at igrin.co.nz


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)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From simon at igrin.co.nz  2003-09-17 15:14 -------
Created an attachment (id=404)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=404&action=view)
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



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From simon at igrin.co.nz  2003-09-17 15:15 -------
Created an attachment (id=405)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=405&action=view)
Successful 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



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648

simon at igrin.co.nz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    Attachment #405|Successful login with       |Unsuccessful login with
        description|V3.7.1p1                    |V3.7.1p1





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From simon at igrin.co.nz  2003-09-17 15:21 -------
Opps. That second attachment should say

UNsuccessful login with V3.7.1p1




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From dtucker at zip.com.au  2003-09-17 17:13 -------
Does it work for a non-root account?  What do you get if you run sshd with
"-o
PermitRootLogin=yes"?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From simon at igrin.co.nz  2003-09-17 18:50 -------
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.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From wcb3 at ou.edu  2003-09-18 06:12 -------
I had the same problem. Try rebuilding with the configuration option --with-md5-
passwords. That worked for me.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From simon at igrin.co.nz  2003-09-18 07:58 -------
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...



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From mouring at eviladmin.org  2003-09-18 11:05
-------
>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.





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From simon at igrin.co.nz  2003-09-18 11:12
-------
>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)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648





------- Additional Comments From tim at newmoonnine.com  2003-09-20 02:34
-------
A workaround:
securecrt-->properties-->authentication-->TIS 
Correct method or not, I've seen it work fine for both putty and securecrt.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=648

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From dtucker at zip.com.au  2003-10-15 18:20 -------
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).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.