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

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

Edits:

-- 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 2.6.26.8+20091222+1056-debhawk-5.2.2-custom #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
share|improve this question
3  
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
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 '12 at 19:25

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.

http://www.linuxforums.org/forum/ubuntu-linux/173779-solved-ssh-issue.html
http://www.unix.com/hp-ux/169496-solved-ssh-debug1-exit-status-254-problem.html
http://www.mail-archive.com/seawolf-list@redhat.com/msg04460.html

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
fi;

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
fi;

A tip I found at http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

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:

pam_unix_*.so

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

pam_unix.so

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.

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
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
ListenAddress 0.0.0.0
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
share|improve this answer

Your Answer

 
discard

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.