Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[REDHAT] Re: OpenSSH bug workaround *NOT NEEDED* (fwd)

| >   What distro (or *nix flavor) is this?  My gut reaction is that it's a
| >PAM or shadow password issue.  If it's Red Hat, or probably any RPM based
| >system, the RPM spec file has the right build flags.  If it isn't, you'll
| >have to make sure that you have the right "--with-pam" or "--with-shadow"
| >arguments to configure.

Well, actually, I've been trying it on two different RedHat releases,
one  running 7.1 and one an earlier VAlinux system with RH 6.2 (which
I should probably upgrade, but it's been  fun  to  watch  the  uptime
growing  to  be  several  years, until we finally had a power failure
yesterday, so maybe I'll do it now ;-).

Anyhow, I installed the latest OpenSSH on both of them, try tests  on
both,  and  I  get  pretty much the same failures.  Both can ssh out;
neither accepts ssh connections.  I've been tweaking the  sshd_config
files  a lot, and sometimes the errors change a bit to the funny mmap
invalid argument.  But  most  tweaks  just  get  a  rejection  of  my

The "ssh -v" was a good idea; here's what happened when  I  tried  it
from a remote machine:

: ssh -v
SSH Version OpenSSH_2.3.0 green at 20010321, protocol versions 1.5/2.0.
Compiled with SSL (0x0090600f).
debug: Reading configuration data /home/jc/.ssh/config
debug: Reading configuration data /etc/ssh/ssh_config
debug: ssh_connect: getuid 1000 geteuid 1000 anon 1
debug: Connecting to [] port 22.
debug: Connection established.
debug: Remote protocol version 1.99, remote software version OpenSSH_3.3
debug: no match: OpenSSH_3.3
debug: Local version string SSH-1.5-OpenSSH_2.3.0 green at 20010321
debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Host '' is known and matches the RSA host key.
debug: Encryption type: 3des
debug: Sent encrypted session key.
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Trying RSA authentication with key 'jc at'
debug: Server refused our key.
debug: Doing password authentication.
jc at's password:
Permission denied, please try again.
jc at's password:

This is interesting because the server also says:

Jun 27 15:11:36 kendy sshd[2661]: Connection from port 2197
Jun 27 15:11:36 kendy sshd[2661]: Failed rsa for jc from port 2197
Jun 27 15:11:47 kendy sshd[2661]: Failed password for jc from port 2197

The "Failed rsa for jc" is now fairly reproducible,  as  long  as  it
gets  to  the  point  of  asking for a password.  I've been trying to
figure out how I might have screwed up RSA  authentication,  but  I'm
not  finding many clues.  This is all black magic, anyway, so I could
have easily gotten a comma wrong somewhere.  But as far as I know,  I
didn't touch any of my own ~/.ssh/* files during the install, so it's
not obvious how I could have screwed up my RSA stuff.  I  have  since
gone  in and removed the references to hosts, to get rid of the fatal
warnings about a man-in-the-middle  attack.   But  this  doesn't  fix
anything, it just lets me get to the password request.

One thing that I see in /var/log/messages when I start sshd is:

Jun 27 15:10:04 kendy sshd[2658]: socket: Invalid argument
Jun 27 15:10:04 kendy sshd[2658]: Server listening on port 22.
Jun 27 15:10:04 kendy sshd[2658]: Generating 768 bit RSA key.
Jun 27 15:10:05 kendy sshd[2658]: RSA key generation complete.

I can't tell whether these are error messages or something normal.

One thing that's weird about the "ssh -v" output is the "getuid  1000
geteuid  1000"  line.  There is no uid 1000 on this system.  The sshd
user that was created has uid 502. This strikes me as suspicious. Why
would it claim a nonexistent uid?

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /