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'm having problems connecting to my server via SFTP. I can SSH in to the system perfectly fine, but for some odd reason, i'm not able to SFTP (which I used to be able to).

I have cleared ALL my iptables rules iptables -F still no access. I have removed the sub system (to allow FULL access) still no access. I can't for the life of me figure out what the problem is. Thus is therefore making a solution impossible.


Subsystem configuration section from

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp sftp-server
share|improve this question
up vote 0 down vote accepted

Removal of the sftp subsystem is what would disable sftp. Try adding the entry again. If it still doesn't work after restarting the ssh service, update the question with your sshd config.


The config you provided doesn't give the full path, try using the commented version.

Subsystem sftp /usr/lib/openssh/sftp-server

For example, my config has

# grep sftp /etc/ssh/sshd_config 
Subsystem       sftp    /usr/libexec/openssh/sftp-server

and if I look for the file via locate, it confirm that it is only located there.

# locate sftp-server
share|improve this answer
I did re-enable them and restart ssh, the config is... – ash Jun 6 '12 at 23:08
Damn it - Why did I comment out the working line? Thanks for your response it's working perfectly fine now (I shall wear the derp hat). – ash Jun 7 '12 at 9:28

This probably will not help the original poster, but I ran into another cause that results in the same symptoms.

The symptoms: When I sftp -v <user>@<host>, the connection blocks after printing:

debug1: Sending subsystem: sftp

The cause: In order to bypass the system default shell configuration, I have put the following line at the top of ~/.bashrc:

exec env -i HOME=$HOME TERM=$TERM bash --noprofile --rcfile ~/.bash2

Even simply exec bash causes the same problem. I guess this makes sense - the sourcing of ~/.bashrc never returns - instead a new instance of bash is exec'ed and replaces the old one.

It is perhaps surprising that the ssh server needs to source the shell config files before running /usr/lib/openssh/sftp-server.

Update: See also this related entry in the OpenSSH FAQ:
(The entry titled: "sftp/scp fails at connection, but ssh is OK.")

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.