Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am working on a server with Debian 5.2.2. Barely having any administrative knowledge with Linux, I think I screwed something up. I used apt-get update and apt-get upgrade to get everything up to date and then I downloaded and installed Apache, PHP, and MySQL. Those tools seem to work fine, but now I can't even login to the server EXCEPT via local console. If I try to login via the GUI or if I try to login remotely via ssh, scp, or anything else, I get disconnected IMMEDIATELY upon successful login. In other words, it has no problem with the initial connection, but when I put in the correct username and password (for root or any user), I get disconnected. With the GUI, the screen goes black for a second and then puts me right back to the login prompt. With ssh, I get "connection to [server] closed." I tried WinSCP and I get "Connection has been unexpectedly closed. Server sent command exit status 254."

Any help is appreciated, and if there is any way I could give more information, please let me know. Thank you for your time.


-- Any user can login on the local console

-- At the moment I don't have local access to the machine, so all I can do right now is ssh. Here is the output of ssh -vvv [server] after I enter my password:

Linux #1 SMP PREEMPT Tue Dec 22 10:58:57 EST 2009 i686

Last login: Mon Apr 30 14:48:07 2012 from
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel 0: close_fds r -1 w -1 e 6
Connection to xxx.x.xx.xx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3845.3
debug1: Exit status 254
share|improve this question
Linux is a kernel, not an operating system. There is no kernel version 5.2.2, so what distribution are you using? – Sven Apr 30 '12 at 18:58
log on via the console and check the /var/log/messages and /car/log/secure logs when you try to log on remotely. Try logging on with ssh -vvv <servername> so you can see what is going wrong. dmesg output might be useful as well but you'll need to trim and post only relevant parts. Can you log on with any user account on the local console or only root? Is the SSH daemon running (ps auxwww|grep ssh)? – Bram Apr 30 '12 at 19:25

6 Answers 6

There are a couple of similar posts suggesting that this could be a problem with spawning a shell because of incorrect settings for the shell path in /etc/passwd

To check this, determine that your user shell path exists and is executable;

# cat /etc/passwd | grep tomh
tomh:x:1000:1000:Tom H:/home/tomh:/bin/bash <-- check this exists

Check shell exists:

# file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

also, check that the shell is not set to either /sbin/nologin or /bin/false, which would also block login, even with a successful authentication.

share|improve this answer
This was indeed my issue, with a fresh cygwin install, the user created by the install had a user shall path of /bin/false. Changing this to /bin/bash fixed the issue. Thanks! – Mitch Kent Oct 2 '14 at 15:48

When I encountered such a problem, I still had one connection open /var/log/messages revealed:

pam_loginuid(sshd:session): Cannot open /proc/self/loginuid: Read-only file system

Editing vi /etc/init.d/named allowed to change the way /proc was mounted, so the error didn't after a reboot.

Basically the lines

if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
        mount -tproc -oro,nosuid,nodev,noexec proc ${CHROOT_PREFIX}/proc 2>/dev/null

Were changed to

if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
        mount –bind -o ro /proc “${CHROOT_PREFIX}/proc” 2>/dev/null

A tip I found at

share|improve this answer
Welcome to SF. You can improve the style of your answer by indenting the code with 4 spaces (or using backticks around it). – ℝaphink Mar 7 '13 at 17:13

My problem was login user name directory was not available in the /home directory. So if you have a user called 'testuser' make sure the /home/testuser directory is available. Learned that from the /var/log/messages file.

share|improve this answer

If you are using LDAP replace every occurrence of:


in all files in /etc/pam.d/ with:

This is a bug in the libpam-ldap package (example pam.d files), see:

Make sure the system can resolve properly, ssh is a bit particular about that.

Check /etc/secuiry/limits.conf to see if any accounts have hard limits on amount of log ins and increase those, i.e.:

*       hard    maxlogins   0

In addition to /var/log/messages as mentioned by Bram, also check /var/log/auth.log and please paste any relevant output. Too much information is better than too little.

share|improve this answer

I've indeed encountered exactly these symptoms in the fashion suggested by @tom-h earlier... and the resolution was very straightforward.

To resolve, simply vipw and edit the passwd file, adjust shell from /bin/false to /bin/bash or the option of your preference.

# cat /etc/passwd | grep adamjohn
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/false <-- check this exists
# vi /etc/passwd
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/bash <-- change this item

Please understand that in some cases this might be done in order to protect a sensitive account. There may be other access restrictions in place. You should know the importance of protecting the server and be aware of the implications of permitting this type of access to it.

share|improve this answer

All of these are great suggestions. In my case, it was a PuTTY setting that causing my pain:

I had put a remote command to send to the server under "SSH" configuration. Which works great 99% of the time, however, when the command fails, it just closes the session.

The command??? screen -rd

Works great when there's actually a session to resume. Fails horribly after a restart.

The Solution:

move that to bashrc/bash_profile.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.