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 xxxxxxx.com #1 SMP PREEMPT Tue Dec 22 10:58:57 EST 2009 i686

Last login: Mon Apr 30 14:48:07 2012 from xxxxxxx.com
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
  • 5
    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, 2012 at 18:58
  • 2
    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, 2012 at 19:25
  • @Sven and to everyone else who thinks otherwise, Linux is an operating system. End of comment.
    – Bobort
    Mar 4, 2020 at 18:51

14 Answers 14


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.


  • 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, 2014 at 15:48
  • 1
    In my experience it's wise to specify shell upon creating the user. The default setting vary from dist to dist. Jun 2, 2016 at 13:45

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.

  • Definitely check the /var/log/messages/auth.log for pointers. Also had a file issue
    – Nick
    Mar 8, 2017 at 10:21

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 http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

  • What would the equivalent be on CentOS 7 which used systemd rather than SysV? Mar 24, 2019 at 7:15
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

In your SSH server's sshd_config file, add the following line:

UsePAM no

Below is the sshd_config I use on OS X. I'm posting it (rather than one on a Debian machine) because I experienced the same problem on OS X using Macports (and not Debian).

AddressFamily any
Port 1522

# The default requires explicit activation of protocol 1
Protocol 2

# HostKeys for protocol version 2
HostKey /opt/local/etc/ssh/ssh_host_ed25519_key
HostKey /opt/local/etc/ssh/ssh_host_ecdsa_key
HostKey /opt/local/etc/ssh/ssh_host_rsa_key
HostKey /opt/local/etc/ssh/ssh_host_dsa_key

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# User Authentication

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
UsePAM no

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

# Use sandbox on OS X
UsePrivilegeSeparation sandbox

# All user's environment
PermitUserEnvironment yes

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /opt/local/libexec/sftp-server
  • 1
    UsePAM=yes is the problem in my centos7/i686 LXD image. Once set to 'no', ssh logins work again. However, there's a note in sshd_config: "WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several problems." If anyone knows what exactly this means, please, shed some light.
    – ILIV
    Feb 14, 2019 at 14:25
  • When I tried changing to UsePAM=no, I was asked to enter a password, even though I should be authenticating with an RSA key. Mar 24, 2019 at 7:14

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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

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.


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.


I had similar issues with Ubuntu 16.04 with LDAP. "ssh -vv ..." showed the password authentication succeeded, but then came the msg: "Connection to ... closed by remote host."

Fixed in /etc/ldap.conf in the configuration of "bind_policy".

/var/log/auth.log showed:

sshd[19884]: Accepted password for xxxx from xx.xx.xx.xx port 48426 ssh2
sshd[19884]: pam_unix(sshd:session): session opened for user xxxx by (uid=0)
systemd-logind[577]: New session 22 of user xxxx.
systemd: pam_unix(systemd-user:session): session opened for user xxxx by (uid=0)
sshd[19884]: nss_ldap: could not search LDAP server - Server is unavailable
sshd[19884]: fatal: login_get_lastlog: Cannot find account for uid 1502 
sshd[19884]: pam_unix(sshd:session):   session closed for user xxxx

Found that the problem was in /etc/ldap.conf. I have changed the bind_policy to "soft", so nss_ldap returns immediately on server failure. The default is "hard_open", which reconnects if opening the connection to the LDAP server failed. Commenting out the line "bind_policy soft" changed it back to the default, and solved the problem. :-)


After a lot of searching, I finally found an answer in the case of CentOS 7 running in an unprivileged container.

Comment out the session required pam_loginuid.so line in the /etc/pam.d/sshd file, and then restart the container.

I found this solution at https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119


In my case, it was caused by a user without a shell on an SSH server. It has a very easy fix, just use the -N switch with your (Open)SSH client.

From the man page:

-N Do not execute a remote command. This is useful for just forwarding ports.


I just cannot agree with some of the answers here. A user with the shell /bin/false, /bin/nologin is a proper configuration, it's often used for user accounts used only for SSH tunnels, without the possibility to login and execute any commands on an SSH server. So don't try to "fix" it on the server, you may introduce a potential security hole by doing that. Just use the -N switch with your SSH client.


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.


Make sure that /etc/passwd has the correct shell for the user.

For example, the user ahmad couldn't login to the server due to missing shell:


Since the shell set to /bin/false it means the user ahmad does not have a shell, and to fix this you have to change /bin/false to /bin/bash for bash or whatever other shells.

If you are using a web hosting control panel e.g. Plesk, make sure the user has the ability to access the server.


I just ran into this problem (specifically for sftp but not ssh, where I could connect without issue) and none of the solutions here worked for me. In my case it was due to having too many ssh keys (IdentityFile's) in ~/.ssh/. It seems that when you don't have a host entry in ~/.ssh/config for the host you are trying to connect to with the right key, it just sends all your keys one by one. I had more than 6 keys, and sure enough, the default MaxAuthTries is 6 (at least in Ubuntu).

The solution was to edit the server's /etc/ssh/sshd_config and increase MaxAuthTries. I set mine to 10.

#MaxAuthTries 6
MaxAuthTries 10

(Or of course, just add a host entry with the right key -- in this particular case I'm trying to log in without the use of a key).


I had a very similar issue, (immediate disconnection using ssh after entering correct credentials). It turned out that the subnet that I had put the Debian VM on was not listed in our Active Directory sites and services. Took me ages to find the answer and this page kept coming up in my searches, so I'm posting the answer here in case anyone is in the same boat in future.


It might be LDAP issue. The authconfig to configure LDAP, Kerberos, and SMB settings was run without,


  • Hello, try answering other questions : OP talks about debian 5, completely outdated for production
    – bgtvfr
    Mar 21, 2019 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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