Normal behavior you say, if /etc/nologin exists, yet therein lies the rub. No such critter. I ssh -vv and see:

<edited for brevity>
.
.
.
.
<username>@10.0.0.36's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug1: channel 0: request pty-req
debug1: channel 0: request shell
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to 10.0.0.36 closed by remote host.
Connection to 10.0.0.36 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 81 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 6270.3
debug1: Exit status -1

And on the server side in /var/log/messages I see "sshd(pam_unix)[15448]: session opened for user <username> by (uid=<uid of username>).

Just out of curiosity I created /etc/nologin, the contents of which are supposed to be printed before disconnect when someone other than root tries to log in and i get

<edited for brevity>
.
.
.
.
debug1: Next authentication method: password
<username>@10.0.0.36's password:
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
<username>@10.0.0.36's password:
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
<username>@10.0.0.36's password:
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
debug1: Calling cleanup 0x8062c30(0x0)

i.e. It doesn't print the contents of /etc/nologin like it's supposed to.

Oh, and as the title of the post implies, ssh'ing in as root works just fine.

Any thoughts on where to start on this?

Thanks

*crickets*

Ahhhh, I hate to bump my own post, but.........

Anyone?........

Anything?........

Even a "Wow that's freaky, I have no friggin clue" would make me feel a little better.

Thanks in advance guys..

hmmm... Freaky...
how about /etc/ssh/ssh_config do you have anything in there that could be messing you up?

Just for reference my Redhat 9 box only has the following lines that are not commented out:
#grep -v "#" ssh_config
Host *
ForwardX11 yes

what about the sshd deamon?
service sshd status

The only other thing I can think of is when I was messing with /etc/passwd and removed the sshd user... that would break it... (actually copied an /etc/passwd from a 7.3 box and RH7.3 doesn't need the user but RH8 does)
You ought to have a line like this in /etc/passwd:
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

Something to look at anyway...

AHA! The plot thickens!

I found this in /var/log/secure

Apr 12 13:06:47 <box name> sshd[15446]: Accepted password for <username> from <client ip> port 4190 ssh2
Apr 12 13:06:47 <box name> sshd[15448]: fatal: PAM session setup failed[6]: Permission denied


The sshd priviledge separation user is indeed intact, and service sshd status shows "sshd (pid 22113 22111) is running..."

My ssh_config is the same. I did notice a difference between the sshd_config on the Fedora box and the sshd_config on the other RH 9 box that this problem is holding up the upgrade of. These extra lines existed in the Fedora sshd_config:

ReverseMappingCheck no
GatewayPorts no
AllowTcpForwarding yes
KeepAlive yes
Protocol 2

But commenting them out and kill -HUP'ing sshd didn't fix anything.

How about your security level... you know that thing you go into when you use
'redhat-config-securitylevel'

redhat-config-securitylevel lists SSH as a trusted service.

Apr 12 13:06:47 <box name> sshd[15448]: fatal: PAM session setup failed[6]: Permission denied
This one's the culprit me thinks. Add a debug statement at the end of /etc/pam.d/system-auth session lines and post output.

Welll..... errrr...... ummmmm....... uhhhhhh.......

It kinda fixed itself. I couldn't get the debug argument on pam_limits.so to give me any output so as a last ditch effort to make it tell me SOMETHING I rebooted. And, well now it just kind of works like it's supposed to. I could swear I've rebooted since the upgrade, however at this point, who knows.

I feel so... so.... so.... Windows ::shudders::

But it's not my fault I didn't think of that I tell you! It's..... it's..... it's that damnable Linux reliability! Yeah! That's what it is! ::mutters:: Stupid reliability....




So the moral of the story is, to quote the great sage Dogbert, "SHUT UP AND REBOOT!"

any improvements on the situation?

Yep, as of my last post it's fixed. Thinking back on it now I'm positive the upgrade process made me reboot as the final (or nearly final) step in the process but apparently a second reboot was required.

I've done one similar upgrade since then and while I didn't test the sshd behavior after the first reboot, I did do an extra reboot as the final step just in case and everything worked as advertised.

The exact same thing happened to me. Cleary there is an issue with FC1 related to non-root users using SSH to access the system.

Might be some kind of setup specific glitch, as I have several fully updated FC1 boxes running SSHd and haven't experienced it (thankfully).

Ok I'm not educated in the full use of all the sshd and fedora core2 and pam.
I had the same thing happen. Specifically trying to SSH into my core2 box I would just get frustrated.

[bd@nite bd]$ ssh demon.com
bd@demon.com's password:
Connection to demon.com closed by remote host.
Connection to demon.com closed.
[bd@nite bd]$

looking in the /var/log/secure I saw:

Nov 22 19:45:36 demon sshd[8823]: pam_succeed_if: requirement "uid < 100" not met by user "bd"
Nov 22 19:45:36 demon sshd[8823]: Accepted password for bd from ::ffff:10.1.43.23 port 48230 ssh2
Nov 22 19:45:36 demon sshd[8825]: fatal: PAM session setup failed[6]: Permission denied

however I found a post:

http://www.netsys.com/pamldap/2003/08/msg00018.html

and there in plain sight was an answer which fixed my ssh problems.

"pam_mkhomedir will not work if privilege separation is enabled in
OpenSSH. It is enabled by default.

In your sshd_config:

UsePrivilegeSeparation no"

I looked and in my /etc/ssh/sshd_config it did say
...
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
...

I changed it to
...
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no

stop/started sshd and poof it worked.

I don't know if this will work everytime but it might.

I have run into this problem as well with FC2... simply restarting the sshd service via /etc/init.d/restart or /sbin/service sshd restart will cure the problem of not being able to login via ssh as any user other than root... but it only lasts until the next reboot. I have tried adding these restart commands in /etc/rc.local to no avail, I have also tried modifying the sshd_config file with no real success. Have any of you managed to get this behavior to stop for good?

Agrapha, thanks, that did the trick, i was having this same problem on a FC1 box...