3 Jan
2016
3 Jan
'16
9:19 a.m.
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
3 Jan
3 Jan
9:28 a.m.
Hi John,
On Sun, Jan 03, 2016 at 09:19:50AM +0000, John Winters wrote:
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.
I've had this before. Turns out that my ssh agent setup was messed
up (SSH_AUTH_SOCK environment variable wasn't pointing at the agent
socket any more):
https://twitter.com/grifferz/status/664784801191317506
Try unsetting SSH_AUTH_SOCK and see if the problem goes away.
ssh seems to gracefully fall back to not using the agent; scp seems
to just wait forever.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
11:40 a.m.
Hi John,
On Sun, Jan 03, 2016 at 10:59:28AM +0000, John Winters wrote:
Thanks for the suggestion. Unfortunately, I'm not
using ssh-agent so I
don't think that's it.
Are you sure? Most people use it without knowing. So you have no
SSH_AUTH_SOCK environment variable set then?
Also, it works fine through the other gateway.
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.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
12:08 p.m.
On 03/01/16 11:40, Andy Smith wrote:
Yes, that's what's rather baffling me.
The school previously used something called (IIRC) bloxx which sniffed
and interfered with connections - even internal ones. I spent some time
trying to diagnose a failure to fetch debian packages from an internal
caching host. A simple connection worked fine, but fetching a package
(over http) got a REFUSED response, and yet I couldn't find any
corresponding message in the cache server's logs. It turned out that
bloxx was sitting in the middle and monitoring the connection. It let
simple listings through, but when one requested a .deb file it faked the
response.
Trying to do things in schools can be a nightmare, but I don't see how
one could get a similar effect interfering with an ssh connection.
Thanks for the suggestions - I shall keep working at it.
Cheers,
John
Hi John,
On Sun, Jan 03, 2016 at 10:59:28AM +0000, John Winters wrote:
john@mach2:~$ env | grep SSH
SSH_CLIENT=81.187.217.217 54413 xxx
SSH_TTY=/dev/pts/1
SSH_CONNECTION=81.187.217.217 54413 172.16.1.21 xxx
john@mach2:~$
I type the passphrase for my ssh key each time I connect to my VPS.
Thanks for the suggestion. Unfortunately,
I'm not using ssh-agent so I
don't think that's it.
Are you sure? Most people use it without knowing. So you have no
SSH_AUTH_SOCK environment variable set then? Also, it works fine through the other gateway.
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. 
9:33 a.m.
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.
Cheers,
Alun.
On 3 January 2016 09:19:50 GMT, John Winters <john(a)sinodun.org.uk> wrote:
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
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
11:02 a.m.
On 03/01/16 09:33, Alun wrote:
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.
I was wondering about that too, and will certainly try it. I'm not
currently in a position to be able to re-boot one end of the link, but
will try it later.
As an interim measure, I've tried scp'ing a five byte file and that
still doesn't work, which makes me doubt it as a candidate explanation.
I don't think this conversation would have involved any large packets.
Thanks for the suggestion though.
Cheers,
John
3128
days inactive
3128
days old
6 comments
3 participants
participants (3)
-
Alun -
Andy Smith -
John Winters