Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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've always used PuTTY (win32) in order to access my servers through SSH. Yesterday I upgraded OpenSSH on my server from 4.3 to 5.8 and it seems that PuTTY doesn't work now. It asks for a password, then confirms that the password is correct, and then gives the fatal error Server refused to start a shell/command.

When I try to log on with cygwin's OpenSSH, I have no problems.

share|improve this question
Can you paste the contents of PuTTY's Event Log? – nickgrim Apr 15 '11 at 8:28
Can you add -v to plink command and post output? – davey May 28 '11 at 7:55
The problem was a shortage on RAM. – iTayb May 31 '11 at 21:49

It sounds like something in your putty configs is requesting a specific shell after login that is no longer approved. Try creating a new session instead of your saved one and input as few settings as possible, just the host and any authentication details. That should get you in. Then if you want to fix your previous saved session look through the settings for bits about remote command, preferred shell, etc.

share|improve this answer
plink user@ip -p 22 -pw pass alone gives me this error. I believe that something is blocking me at the sshd side and not the putty. – iTayb Apr 15 '11 at 7:58
Still have a look through your default setings. Putty is likely requesting something that is unavailable on the server that the cygwin openssh client is not asking for. – Caleb Apr 15 '11 at 8:00
Did you try creating a new session, as Caleb suggested? Are you running the latest Putty? – Eduardo Ivanec Apr 29 '11 at 17:27

You probably have the "remote command" set under the SSH settings in the putty config. Just remove this setting and try again.

share|improve this answer
up vote 0 down vote accepted

The problem was a shortage on RAM.

share|improve this answer
same issue on full RAM/CPU server – Dude Dec 6 '13 at 14:37

For users who encounter this issue: You can resolve this by killing the session of one of the users using

pkill -KILL -u username

NB: I used root access, since it was logging in successfully

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.