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: Server listening on 0.0.0.0 port 22. Mar 7 05:31:03 gambit sshd: Server listening on :: port 22. Mar 7 05:31:09 gambit sshd: pam_unix(sshd:session): session closed for user root Mar 7 05:31:14 gambit sshd: Accepted password for root from 184.108.40.206 port 55173 ssh2 Mar 7 05:31:14 gambit sshd: pam_unix(sshd:session): session opened for user root by (uid=0) Mar 7 05:31:15 gambit sshd: subsystem request for sftp Mar 7 05:32:52 gambit sshd: Received signal 15; terminating. Mar 7 05:32:52 gambit sshd: Server listening on 0.0.0.0 port 22. Mar 7 05:32:52 gambit sshd: Server listening on :: port 22. Mar 7 05:32:55 gambit sshd: pam_unix(sshd:session): session closed for user root Mar 7 05:33:00 gambit sshd: Accepted password for root from 220.127.116.11 port 55198 ssh2 Mar 7 05:33:00 gambit sshd: subsystem request for sftp
I checked my sshd_config at /etc/ssh/sshd_config. The line I was looking for was:
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
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
if [ "$TERM" != "dumb" ] then source .bashc_real fi
if [ "$SSH_TTY" ] then source .bashc_real fi
Joel G Mathew, known in tech circles by the pseudonym Droidzone, is an opensource and programming enthusiast.
His favorite pastime is grappling with GNU compilers, discovering newer Linux secrets, writing scripts, hacking roms, and programs (nothing illegal), reading, blogging. and testing out the latest gadgets.
When away from the tech world, Dr Joel G. Mathew is a practising ENT Surgeon, busy with surgeries and clinical practise.