Tag Archives: sftp

Paramiko sftp hanging with connections between machines on the same interface of a filtering pfsense box

Odd problem; I had the following set up:

[[machine with paramiko 10.100.x.x]] –|

                                                              | —–(int X) 10.100.x.x [[pfsense]] (int Y) 10.2.x.x —– | —— [[10.2.x.x machine B]]

[[machine A 10.100.x.x]] ——————|


I had a script on the paramiko machine connecting via ssh and sftp to machines A and B.  Connections to machine B had no problem whatsoever.  Connections to machine A, however, would work 5% of the time, and drop the rest of the time either when setting up the channel to execute a command over ssh, or when invoking the sftp subsystem on the remote machine.  Normal ssh and sftp connections (not using paramiko) had no problems whatsoever.  Also, when pfSense filtering was turned off, there were also no problems.

It turned out that pfsense was dropping a lot of packets sent by paramiko due to fragmentation (logs show TCP:PA, TCP:RA and TCP:A).  Unfortunately, tweaking pfsense settings didn’t help here (some people have reported that setting Firewall Optimization Options (under Advanced > Firewall/NAT) to conservative worked – that didn’t help me unfortunately – or disabling firewall scrub worked – which I couldn’t do as it’s required by NAT).

I haven’t been able to figure out exactly what the problem is.  The packets received by machine B and machine A (with filtering off) look exactly the same.  I’m tempted to think this is a pfsense problem, although I have no specific proof (I’ve tested with multiple machines in position of machine A by the way, compared ssh settings, ensured there were no other connectivity problems in the way).

In the end, I’ve set up another network (virtual one, since these are VMs – 10.100.x.x machines plus pfsense on one physical host, and 10.2.x.x on another) connecting these VMs directly to eachother, to bypass pfsense for these connections.

Setting a umask for chrooted sftp users

It took at least an hour of Googling to find this solution, so I’m posting it here for reference and hopefully it could help others.

If you’re not using a chroot jail, you can follow this: http://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions

This involves setting the umask in sshd_config in the Subsystem line, however, it doesn’t work for chrooted users as the umask gets set, ssh session starts and the chroot recreates the umask info (this is how I understand it, anyway).

So if you’re using chroot for users, you probably have something similar to this in your sshd_config:

Subsystem sftp internal-sftp

UsePAM yes

Match user username
ChrootDirectory /path/to/directory
ForceCommand internal-sftp

You should then edit the file /etc/pam.d/sshd and add the following:

session optional pam_umask.so umask=0002

And in /etc/profile, if it’s not already there (it was for me on Ubuntu 10.10), add the following at the bottom:

umask 022

And that’s it.  internal-sftp does not execute any shells so it won’t take any notice of information in profile/login/rc etc, however, pam authentication is used so the configuration is seen there instead (unless, of course, you’ve turned it off).

Ref: http://ubuntuforums.org/archive/index.php/t-1107974.html

RSA authentication with chrooted sFTP – authorized_keys location

There’s something slightly annoying about the default location of the authorized_keys file when you’re working with chrooted sFTP.

The user’s home directory is relative to the chroot jail, however, the authorized_keys file default location (%h/.ssh/authorized_keys) is relative to the root of the server (even though the path is %h, rather than /%h).  (To be clear, %h = home directory.)

So, for example, you have the following setup:

username = sftp
chroot jail = /home/sftp/jail/
home directory = /upload
(therefore actual directory = /home/sftp/jail/upload)

(I use a folder upload as the home directory as the root of the chroot jail cannot be writable, as it has to be owned by root – if you create an additional directory owned by user sftp and direct them into their by default when they log in, they can then read and write to that directory without having to change directories to do anything.)

In this setup, using the default ssh authorized_keys file location, you need to create a new directory /upload in the root of your server just to store the authorized_keys file of this user…not a great solution.

So what to do?  Change the default location of the authorized keys file; I’ve done the following:

/usr/local/share/keys/sftp/.ssh/authorized_keys (create additional directories for each user that needs to use sFTP OR SSH)

And then in the /etc/ssh/sshd_config file, you can use the following for the authorized_keys:


Obviously move the authorized_keys from the default location of /home/sftp/.ssh/authorized_keys to this new location, and make sure your user (sftp in this case) is the owner of the file.  Do this for all users of sftp or ssh.

Restart ssh and you’re done.