Bug 10997 – sshd won't accept connections anymore since baselayout changed

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Sven Vermeulen (RETIRED) 2002-11-20 07:05:45 UTC]

I am not certain that the baselayout has anything to do with it, but since the
last emerge -u world, baselayout was updated _and_ since then I can't connect to
my ssh-server anymore.

Please find attached the sshd_config from /etc/ssh/sshd_config. There have been
no changes to the original /etc/pam.d/sshd, there is no /etc/nologin, the
respective users are in the sshusers group. Deactivating PAM authentification
doesn't work, neither does removing the "AllowGroup" statement. 

Also attached is the output of "sshd -dd" for one attempt at logging in.

I have not changed anything, and it worked happily beforehand (before the
"emerge -u world"). If you require more information, please ask.

[Comment 1 Sven Vermeulen (RETIRED) 2002-11-20 07:06:20 UTC]

Created attachment 5815 [details]
sshd_config

[Comment 2 Sven Vermeulen (RETIRED) 2002-11-20 07:10:18 UTC]

Created attachment 5816 [details]
output of sshd -dd

First attempt: correct password (yes I am certain)
Second attempt: wrong password
Third attempt: empty password

[Comment 3 SpanKY 2002-11-20 11:47:41 UTC]

what if you run `strace -f -s 4096 sshd -dd >& sshdlog &` ?
is the PAM stuff dieing ?

[Comment 4 Sven Vermeulen (RETIRED) 2002-11-20 12:59:36 UTC]

I can't seem to find the problem. It gets its connection

accept(3, {sin_family=AF_INET, sin_port=htons(35934), in_addr=inet_addr("127.0.
                                                     0.1")}}, [16]) = 4

afterwards, it starts the PAM session (it has received the login "vipe" through
                                                               the argument (ssh
-l vipe -p 2223 localhost)).

[pid 20335] write(2, "debug1: Starting up PAM with username \"vipe\"\r\n", 46deb
                                                             ug1: Starting up
PAM with username "vipe"^M) = 46

It reads all the necessary files (and pam-modules), gets to the /etc/shadow file
                                                              (yes, that data
has been cut out of the log) from which I guesses it results in                
                                              an approval, otherwise /etc/shells
wouldn't be read:

[pid 20335] stat64("/etc/shells", {st_mode=S_IFREG|0644, st_size=196, ...}) = 0
[pid 20335] open("/etc/shells", O_RDONLY) = 3

Then it searches for a /etc/nologin file (which it doesn't find)

[pid 20335] open("/etc/nologin", O_RDONLY) = -1 ENOENT (No such file or director
                                                             y)

and then, immediately afterwards:

[pid 20335] select(0, NULL, NULL, NULL, {2, 347378} <unfinished ...>
[pid 20337] read(3,  <unfinished ...>
[pid 20335] <... select resumed> )      = 0 (Timeout)
[pid 20335] write(2, "debug1: PAM Password authentication for \"vipe\" failed[7]
                                                             : Authentication
failure\r\n", 82debug1: PAM Password authentication for "vipe"                 
                                             failed[7]: Authentication
failure^M) = 82


I've added the sshdlog output, removed the data I think is not necessary to debu
                                                             g te problem and
the data that could be a security-problem if I released it. "vi                
                                             pe" is a testaccount but has the
necessary rights to logon (i.e. in sshusers gro                                
                             up). Also, the used password is correct (I can
login onto the system fysically w                                              
               ith the same password).

PS If you think you do see information that I shouldn't have released and that i
                                                             s a danger for
security, plz mail me.

[Comment 5 Sven Vermeulen (RETIRED) 2002-11-20 13:00:48 UTC]

Created attachment 5826 [details]
strace output

[Comment 6 Sami Nieminen 2002-11-21 16:17:47 UTC]

I have this same problem, but it is possible to ssh in with root account. Normal user account tells me that password is wrong. 

[Comment 7 Dave Nellans 2002-11-21 17:19:44 UTC]

I can also cause this bug repeatably.  Root can login but anyone in the group
"users" can not with the message "Permission denied, please try again".

[Comment 8 Johannes Ballé 2002-11-23 04:18:46 UTC]

Hello,

I get the same errors, and it also happens since I did emerge -u world some time
ago.

I'm using the newest sshd and baselayout from the stable "x86" tree, with no
modifications in /etc/ssh/* (client and server side)

root can login, everybody else gets a "password incorrect".

[Comment 9 Sven Vermeulen (RETIRED) 2002-11-25 03:59:51 UTC]

Seems like this is an PAM-issue. I've recompiled openssh with debugging and found out that it was a pam-function (pam_authenticate in auth-pam.c iirc) that timed out, and thus never saying the password was valid.  I've re-emerged pam but this didn't help. I guess its a permission-problem. I hate to recompile pam with debugging, since this is a production-system (without sshd :(I'm going to recompile login with debugging to see if it uses the same function, and if so, why that login doesn't time-out.Also, disabling the use of PAM in sshd_config doesn't work: it seems that everything in Gentoo must go through PAM.

[Comment 10 Gentoo Bugs 2002-11-26 16:12:22 UTC]

I'm also getting the same problem. I re-emerged openssh and and removed the
/etc/ssh directory and made new key pair(s) and I am getting the same problem. I
can, however, login as root... but none of my users are able to login. 

This bug happened after I did emerge -u world as well. 

[Comment 11 Matthew Kennedy (RETIRED) 2002-11-26 22:28:36 UTC]

per woodchips suggestion late one night on #gentoo-dev, check your
/etc/passwd and make sure that you have a valid shell set for your
user.

[Comment 12 Matthew Kennedy (RETIRED) 2002-11-26 22:32:26 UTC]

resolving since the last comment fixes this for at least two
users. reopen and complain if it doesn't.

[Comment 13 Sven Vermeulen (RETIRED) 2002-11-27 10:55:39 UTC]

I second this: although I did use a valid shell, it was not mentioned in
/etc/passwd. Adding the shell to /etc/passwd (or by means of chsh) resolved this
issue.