# Openssh 3.4 password problems?

## crotty

I've searched the forums, and tried compiling openssh 3.4 via emerge and directly from source, but I keep getting the same problem. When I try to log in (with the right password, as root or a normal user), it tells me permission denied, please try again. It's like this whether or not I turn on UsePrivelegeSeparation, which i doubt has anything to do with this. It was not happening with the emerge of openssh right before 3.4, but it started with 3.4. Any help would be greatly appreciated....

Crotty

----------

## Zu`

Strange problem, since 3.4 works fine here on Gentoo aswell as on OpenBSD.

Man page says this about PrivilegeSeparation, althought it's not really clear (at least to me):

```

     UsePrivilegeSeparation

             Specifies whether sshd separates privileges by creating an

             unprivileged child process to deal with incoming network traffic.

             After successful authentication, another process will be created

             that has the privilege of the authenticated user.  The goal of

             privilege separation is to prevent privilege escalation by con-

             taining any corruption within the unprivileged processes.  The

             default is ``yes''.

```

Perhaps try using the default config for sshd and see what gives?

Greets

----------

## crotty

The really weird thing is that i just compiled openssl-0.9.6d and the latest openssh-3.4 from source on a redhat test box, and the same freakin thing happened...damn, i was hoping other people had this problem... 

this has to be a configuration file problem, what possible option deals with this weirdness....i'm stumped....

thanks

Crotty

(oh, and i tried it with the default config files, and with the PrivSep thing, same problem... i'm gonna cry )

----------

## klieber

Do your log files have anything pertinent in them?

--kurt

----------

## crotty

Pertinent info from my log file: (/var/log/messages)

when i restart sshd:

sshd[14039]: Server listening on 0.0.0.0 port 22

when i telnet in:

PAM_pwdb[14016]: (login) session opened for user whoever by (uid=0)

but when i ssh in:

sshd[14039]: Failed password for whoever from 127.0.0.1 port 1033 ssh2

also, there's a modprobe error abou net-pf-10

modprobe: Can't locate module net-pf-10

but isn't that for IPv6?

Could my problem be that i'm not compiling in PAM support or something like that? 

Thanks in advance,

Crotty

----------

## dice

I get this same error, I've re-emerged openssh but I still get it  :Sad:   Actualy, I can ssh in as the first user account I created, but none of the other ones.

----------

## bung-foo

I have this exact smae problem.  Has anyone figured out what this is about or how to fix it?

Bung-Foo

----------

## vert

Anyone found a solution yet? I just ran into the same problems.  But found out that root can login, no users though...

----------

## bung-foo

yep, same issue.  no solution yet.  I've got a thread going on the gentoo-newbies mailing list.  I'll post here if/when I find a solution.

Bung-Foo

----------

## bung-foo

i lied, check /etc/passwd make sure the line for your user indicates a shell to use  should look like this

bung-foo:x:1000:100::/home/bung-foo:/bin/bash

shell entry should be at the end.

Bung-Foo

----------

## Xor

well my 2c

do you allow root to login directly? some systems (configs) have disabled that... check you sshd_conf  :Smile: 

I emerged openssh 3.4p1 in gentoo a while ago, there was no problem with the package.

----------

## Blahbbs

That's the ticket... Check your entry in the /etc/passwd file and make sure you have a shell defined.  I added /bin/bash to the end of the account entry and ssh worked like a champ.  

Thanks bung-foo...

--Blahbbs

----------

## bung-foo

sweetness.  glad you got it working.  I picked up that info from the gentoo-newbies mailing list.  

Bung-Foo

----------

## Mandr4ke

very strange.. i just emerge and starting using openssh.. and i'm having a big problem with it.. 

I can login as root, and my main user.. but when i try another user (3rd),, i get password failed each time.. i've changed the password a couple time, and the shell..  aswell.. it's currently set to just /bin/bash and login's normally.. just not through ssh..  and ideas??

My goal also is for this 3rd user account to a public account, so i want it to accept all keys from everyone to excrypt each session.. it's kicks off a BBS and i thoguht this would be a good replacement for Telnetd could i be missing something with generating a key for the 'bbs' user..  hmmm

----------

## rac

 *Mandr4ke wrote:*   

> when i try another user (3rd),, i get password failed each time.  and ideas??

 

Try shutting down the main sshd daemon with 

```
# /etc/init.d/ssh stop
```

...then try running it in debugging mode with something like: 

```
# /usr/sbin/sshd -d
```

...see the sshd man page for information about making the debugging mode more verbose.  

Then try to connect and see if you get some more detailed information that might help you diagnose just where the connection is breaking down.  If the client side is using openssh also, you can try running it in verbose mode (-v) to get debug messages on that side too.  Otherwise, see the documentation for the client you are using.

----------

## EPrime

Fwiw, I enabled PrivSep here (Mandrake 7.2) and haven't had a problem with ssh or anything related.

Given that this option has less code running as root the least one should do is try it out and if it doesn't work or causes unwanted side-effects alternatives can be tried.

I'd prefer not to get into the fingerpointing business, so this is a purely technical observation from my own experience with it.

----------

## rac

After consulting with jmglov, his post has been split into its own thread in Gentoo Chat.

----------

## jmglov

 *EPrime wrote:*   

> Fwiw, I enabled PrivSep here (Mandrake 7.2) and haven't had a problem with ssh or anything related.

 

Red Hat and Mandrake released new RPMs with PrivSep enabled. I am sure that it works without overt problems on a lot of systems. Thats is not the question.

The question is rather, "why should we be running largely untested, unaudited code on mission-critical and/or security-sensitive servers?"

My answer is, "we should not!"

 *EPrime wrote:*   

> Given that this option has less code running as root the least one should do is try it out and if it doesn't work or causes unwanted side-effects alternatives can be tried.

 

I agree that PrivSep is, in theory, a damned good idea. Unix philosophy has long dictated two things:

1) Keep it simple, stupid, and

2) Do *not* use root unless you need to!

OpenSSH, in its 3.1 incarnation, violated both of those maxims. So PrivSep is certainly A Good Idea(tm), and may well become A Good Thing(tm). But that does not mean that it is now. The code is so new that the OpenSSH team has not been able to port it to many different platforms. And the individual vendors are are responsible in the end for releasing PrivSep-enabled packages or not. Some vendors, like Red Hat and Mandrake, did. Others, like Sun, did not.

I happen to think that Sun is right in the case. So why did Red Hat and Mandrake quickly release packages and Sun not? Because, in the end, Sun *has* to be accountable to its customers. Red Hat has shown in the past that it is willing to push out beta-level code in its actual releases (and I refer to the gcc-2.96 fiasco[1]).

 *EPrime wrote:*   

> I'd prefer not to get into the fingerpointing business, so this is a purely technical observation from my own experience with it.

 

The reason that I posted my largely political attack on how the OpenSSH team handled the whole PrivSep issue is that I felt they used a technical vulnerability to slingshot a political issue past otherwise reluctant vendors. Pretty shady stuff, if you ask me.

--Josh Glover

[1] Here is a pro-Red Hat view. I happen to disagree, but it does a good job of explaining some of the issues surrounding Red Hat's decision.

http://www.bero.org/gcc296.html

----------

## rac

Followups to jmglov's post should be directed here.  I would graft these last two posts onto that thread, but alas, phpBB has not this feature.

----------

## BradB

I had problems logging into sourceforge with ssh.  I don't know if this is the same problem, but I fixed it by forcing protocol 1 (RSH I think).  You can create a ~/.ssh/Profile file and add the line "Protocol 1,2" I think.

Cheers

Brad

----------

## rac

 *BradB wrote:*   

> I fixed it by forcing protocol 1 (RSH I think).  You can create a ~/.ssh/Profile file and add the line "Protocol 1,2" I think.

 

Thanks for the tip.  There still may be servers that are only running SSH protocal 1 where this is necessary.  A couple of points of clarification: RSH is the unencrypted predecessor of SSH, it's a completely different animal.  Use of SSH protocal 1 has been deprecated because it has some security vulnerabilities related to design flaws in the protocol itself.  So, if you have control of the server environment, and you're in a situation like BradB describes, try to upgrade your server to something that speaks protocol 2.

----------

## klieber

 *BradB wrote:*   

> You can create a ~/.ssh/Profile file and add the line "Protocol 1,2" I think.

 

As rac said, you want to avoid using protocol 1 whenever you can.  However, in the event that you *must* use 1 for some reason, make sure the line is entered as follows:

```
Protocol 2,1
```

That tells ssh to try protocol 2 first, and to fall back on 1 only if that fails.  The other way, ssh always tries protocol 1 first, which is a Bad Thing.  :Smile: 

--kurt

----------

## dingo

I just had the exact same problem a few minutes ago on a remote machine, only root could ssh in. I found the problem to be with the 'adduser' program gentoo uses to add users, it doesn't give them a shell in /etc/passwd (since i've never even physically touched this machine i've never tried from the terminal). After much frustration I fixed it by adding /bin/bash to the end of the line in the user's line in /etc/passwd. Hope that works.

----------

## rac

 *dingo wrote:*   

> I found the problem to be with the 'adduser' program gentoo uses to add users, it doesn't give them a shell in /etc/passwd (since i've never even physically touched this machine i've never tried from the terminal).

 

I've seen several people with this problem, and I still don't fully understand why it happens to them.  In any case, when you make the user you can specify a shell with the -s argument to adduser, and you can use "adduser -D -s" to set the default shell for all future users.

----------

## acidreign

I have found that it is actually a pam configuration issue, no.. gentoo has it fine, its just that pam expects the user to have a shell.

You have to set the users shell, you can do this when you add a new user by

adduser -m -s /bin/bash username

(if you have bash installed)

or to a running user with 

usermod -s /bin/bash username

On the upside, if you do not give a user a shell, they can not log in remotely with ssh, yet still log in with ftp and other daemons.

----------

## jmglov

 *rac wrote:*   

>  *dingo wrote:*   I found the problem to be with the 'adduser' program gentoo uses to add users, it doesn't give them a shell in /etc/passwd (since i've never even physically touched this machine i've never tried from the terminal). 
> 
> I've seen several people with this problem, and I still don't fully understand why it happens to them.  In any case, when you make the user you can specify a shell with the -s argument to adduser, and you can use "adduser -D -s" to set the default shell for all future users.

 

Problem? I call it a feature! ;)

Seriously, when I run adduser, I do not necessarily want the user to *have* a shell. There are some situations in which the user should have a password in /etc/shadow but still not be able to login. And that is what this PAM config gives you.

--Josh

----------

## rac

 *jmglov wrote:*   

> There are some situations in which the user should have a password in /etc/shadow but still not be able to login. And that is what this PAM config gives you.

 

What is the benefit of leaving the shell field empty, as opposed to setting it to /bin/false, for example?

----------

## jmglov

 *rac wrote:*   

>  *jmglov wrote:*   There are some situations in which the user should have a password in /etc/shadow but still not be able to login. And that is what this PAM config gives you. 
> 
> What is the benefit of leaving the shell field empty, as opposed to setting it to /bin/false, for example?

 

None that I can readily think of. Two different ways to solve a problem.

--Josh

----------

## exklusve

I had the same problem it had to do with two issues.   Some problems with DNS, but once that was fixed, i still had emerge unmerge openssh, and then re-emerge it.  

and it worked.    :Smile: 

----------

