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)

Hash: SHA1

On Thu, 27 Jun 2002, John Chambers wrote:
> Another reason you might want to wait:  I tried installing 3.3 on  my
> home  machine.

   Don't look now, but the latest version is now 3.4. :)
   The difference between 3.3 and 3.4 seems to be that the vulnerability 
was avoidable in 3.3, whereas in 3.4 it's actually been fixed.

> I can now ssh out, but incoming connections all get "Permission denied"  
> after I type the password, and /var/log/messages gets a "Failed password
> for jc from port 46127 ssh2" type message.

   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.

> One curiosity is that, which the sshd user and group exist, I don't seem
> to see ~sshd, i.e., /home/sshd/.  I wonder if that could be a problem.  

   User "sshd" should have a home dir of /var/empty, which is exactly 
that, empty.  This is the chroot jail for the sshd process.

> Well, that did change things. Now I don't even get prompted for a
> password.  The ssh command instandly says "Connection closed" and
> /var/log/messages says:
> Jun 27 09:10:06 kendy sshd[2328]: fatal: mmap(65536): Invalid argument

   Find the line in /etc/ssh/sshd_config that reads:
# Compression yes

   and change it to:
Compression no

   If you're running a 2.2 kernel you can't have PrivSep and Compression 
at the same time.  I don't really know why, but that's the case.

> Since this has to do with  UsePrivilegeSeparation,  I  went
> into  sshd_config  and turned that off.

   While privsep is a REALLY good idea, remember that it's not strictly 
necessary.  As long as you run 3.4 or better, or have ChallengeResponse 
disabled, this particular hole is unexploitable.  Of course, leaving 
privsep enabled should help avoid future problems.

- -- 

The light at the end of the tunnel has been turned off due to budget cuts.

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


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 /