user's SSH access denied after last cPanel upgrade.

[jols]

We are getting multiple reports of people who suddenly can not access their accounts via SSH. Their accounts are still set with jailed in the Manage Shell Access area of WHM, but still they are unable to access the shell. They only get a screen with a cursor but can not enter any data.

I am only seeing stuff like this in the logs (the DST IP has been manually hashed out).

messages:Nov 11 15:15:13 northstar kernel: ** SSH ** IN=eth0 OUT= MAC=00:c0:9f:36:57:41:00:e0:52:d1:54:21:08:00 SRC=66.61.55.62 DST=#.#.#.# LEN=48 TOS=0x04 PREC=0x00 TTL=110 ID=32352 DF PROTO=TCP SPT=2204 DPT=22 WINDOW=16384 RES=0x00 SYN URGP=0


Problems seemed to start after this last cPanel upgrade. We are currently running WHM 10.6.0 cPanel 10.8.0-R27

Any ideas?

[bijo]

Hello,

Did you install apf on the server?. flush it and then try

[chirpy]

Those iptables logs are informational and don't indicate a blocked login attempt. You might want to check for blocked ports, though, as bijo suggests. You should also check /var/log/messages and /var/log/secure and then attempt to SSH in yourself to a jailshell account.

You could also try and su into such a users account to make sure that the login shell isn't haveing a problem.

Also, you haven't moved SSH to a different port have you? Or, have you disabled SSHv1 support that the users might still be using?

[jols]

Good suggestions all. Thanks very much.

Yes we are running apf and yes I have flushed iptables. And no, we are not running SSH on an alternat port, at least not yet, and yes I have suED into the user's shell access with no problems.

I will check the various logs you suggest.

Thanks again.

[brianoz]

At the risk of stating the completely obvious, you could also try SSHing in yourself and see what happens. And then, next step, use a remote control session, if you have that facililty, to see what's going on when they try.

[chirpy]

Last case scenario would be to run up the SSHD daemon in debug and interactive mode. It's relatively simple to do, but you do have to be careful. Let me know if you'd like me to post instructions on doing that.

[brianoz]

Actually SSH itself in debug is a huge help to these sorts of problems. Log in using ssh in debug mode from another unix host with the command "ssh -vvv problemhost". You can also put in "-p NNNN" to alter the SSH port, if you do that (a great idea IMHO).

I don't think PuTTY has an ability to produce debug output, but if it does, feel free to use it instead (and share how to put it in debug mode).

[Maquiavelo]

Hello,

We are currently having this same issue, the only way we can get SSH to work for multi users is to reboot (CentOS) run in Single User mode and then bring eth0 up and SSHD.

If we telinit 3, it just stops accepting ssh logins, we can connect, the server asks us for password and it just stalls there, when running ssh with -vvv the last line says: Sent password, waiting for reply.

It started happening a day or two ago, I stopped apf, checked iptables, flushed the rules.

Checked host.allow and host.deny, they were fine.

[chirpy]

OK, try running SSHD as a daemon in debug:

Warning: be careful with this otherwise you can leave yourself unable to login via SSH (although you should be able to restart through WHM)

1. Login as root and:

service sshd stop

2. Runup sshd in debug and interactively:

sshd -D -ddd

3. Try and login in the manner that has been failing

4. What the sshd output very carefully and try and spot the problem

When done:

5. Restart the normal sshd daemon:

service sshd start

[Maquiavelo]

Ok

I ran SSH like you said, then I went into runlevel 3 (It was S), I could login but after a minute it kicked me both of the terminals and hangs whenever I try to login.

Why is it now allowing me to change to runlevel 3 properly?.

[Maquiavelo]

Follow up:

I ran sshd -dd -D on port 30 so I wouldn't get kicked out, it stalls here:

debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10

[chirpy]

Just a guess, it probably won't help, but incase there's a lock file:

rm -fv /etc/*.lock

[Maquiavelo]

Just a guess, it probably won't help, but incase there's a lock file:

rm -fv /etc/*.lock

There are 3 lock files in /etc/


-rw------- 1 root root 5 Nov 16 23:55 group.lock
-rw------- 1 root root 5 Nov 16 23:55 gshadow.lock
-rw------- 1 root root 0 Jun 29 03:06 .pwd.lock


I can't try right now, but what if it's not the .lock files?

Also, isn't the date on the last lock invalid? june 0?

[chirpy]

The 0 is the file size, not the date

You should delete those lock files and then try SSH again.

[Maquiavelo]

The 0 is the file size, not the date

You should delete those lock files and then try SSH again.

Nothing, still happening.


Any other ideas?