Let me start by saying that I'm pretty confident that this problem has nothing to do with Bitfolk, but it involves my Bitfolk VPS and there are some pretty knowledgeable people here... I run a git repository on my Bitfolk VPS, which clients connect to over ssh using an unusual port number. (I know that doesn't provide much extra security, but it reduces the number of irritating log messages.) One of the client machines is at a school, and said school is in the process of changing their ISP and firewall software. The new ISP is Virgin and the new firewall is Smoothwall. The actual client machine has a local IP address (172.16.x.x) and both old and new Internet connections use a NAT firewall. I've been asked to switch over their client machine from using their old firewall as its default gateway to using the new one. Most things are fine, but... With the client machine set to use the new gateway it can ssh to my Bitfolk VPS just fine. If on the other hand I try to use scp from the client to the VPS, it gets through the authentication phase and then just hangs. If I switch back to the old gateway, both ssh and scp work fine. I get no warnings about machine IDs having changed, so I'm fairly confident that there isn't a man-in-the-middle element to the new firewall. I've been scratching my head over this for a couple of days because I can't imagine how a firewall lets through ssh and blocks scp. The only thing I've found on-line is the surprising news that scp is sensitive to messages echoed during login, but when I connect using ssh then the messages which I get are identical via old or new gateway. Anyone any ideas? TIA, John ------------------------------------------------------------------------ _______________________________________________ users mailing list users(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/users

That sounds like an pMTU problem to me. Try temporarily reducing the MTU on the interfaces at both ends and see if the problem goes away.

Hi John, On Sun, Jan 03, 2016 at 10:59:28AM +0000, John Winters wrote: Are you sure? Most people use it without knowing. So you have no SSH_AUTH_SOCK environment variable set then?

I'm still thinking SSH_AUTH_SOCK because the only time I have ever seen what you describe was when that was messed up. You can rule out most networking issues by doing a tcpdump, and/or by running a debug sshd on a different port and scp to that. But as ssh works regardless, these aren't going to tell you much.