Cannot sftp, can ssh and scp

I’d noticed an issue on my server where it allows me to login with ssh, or transfer files with scp or rsync, but would not allow me to use Filezilla to transfer files using sftp protocol

My /var/log/auth.log showed the following:

Mar  7 05:31:03 gambit sshd[28323]: Server listening on 0.0.0.0 port 22.
Mar  7 05:31:03 gambit sshd[28323]: Server listening on :: port 22.
Mar  7 05:31:09 gambit sshd[28310]: pam_unix(sshd:session): session closed for user root
Mar  7 05:31:14 gambit sshd[28329]: Accepted password for root from 59.93.41.155 port 55173 ssh2
Mar  7 05:31:14 gambit sshd[28329]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar  7 05:31:15 gambit sshd[28329]: subsystem request for sftp
Mar  7 05:32:52 gambit sshd[28323]: Received signal 15; terminating.
Mar  7 05:32:52 gambit sshd[28352]: Server listening on 0.0.0.0 port 22.
Mar  7 05:32:52 gambit sshd[28352]: Server listening on :: port 22.
Mar  7 05:32:55 gambit sshd[28329]: pam_unix(sshd:session): session closed for user root
Mar  7 05:33:00 gambit sshd[28358]: Accepted password for root from 59.93.41.155 port 55198 ssh2
Mar  7 05:33:00 gambit sshd[28358]: subsystem request for sftp

I checked my sshd_config at /etc/ssh/sshd_config. The line I was looking for was:

PermitRootLogin yes

However that was already set.

So I was in a delimma. I couldnt find out at all, what the issue was, until I read this comment by mdpc on Server Fault, where he says:

Another issue that I have noticed, is that if your login startup files generate any sort of output, scp and sftp fail. Be sure you bracket things that output to the terminal in your startup scripting using a test on the variable $?prompt if it is non-zero you talking with a terminal.

This made me remember that I wasnt getting this issue immediately after installed a new OS, however only after I’ve worked on it for a while. So I understood that it was because I had .bashrc set to output a few things. So if .bashrc output anything to the terminal, an sftp would fail.

Moving .bashrc fixed the issue.

In fact, once I became aware of the issue, it was easy to find that this situation was rather well documented, in no less than the openssh

http://www.openssh.org/faq.htmlFAQ

2.9 – sftp/scp fails at connection, but ssh is OK.

sftp and/or scp may fail at connection time if you have shell initialization (.profile, .bashrc, .cshrc, etc) which produces output for non-interactive sessions. This output confuses the sftp/scp client. You can verify if your shell is doing this by executing:

ssh yourhost /usr/bin/true

If the above command produces any output, then you need to modify your shell initialization.

There are many solutions you can use, and all of them involve checking what kind of shell you’re running. If it’s a non-interactive shell like xterm, you execute .bashrc. If it’s filezilla, you dont.

So you first rename .bashrc to .bashc_real

Then you insert one of the following code into a new file .bashrc:

if [ "$TERM" = "xterm" ]
then
   source .bashc_real
fi

OR

if [ "$TERM" != "dumb" ]
then
   source .bashc_real
fi

OR

if [ "$SSH_TTY" ]
then
   source .bashc_real
fi

 


You are reading this post on Joel G Mathew’s tech blog. Joel's personal blog is the Eyrie, hosted here.