Outbound ssh/sftp connections timing out

[daaaveybaby]

I'm having problems with outgoing secure connections (ssh, sftp, etc.) The connections regularly timeout. If I keep trying I will eventually make a connection to the remote server. This only occurs when my computer is attached to my home Bell Fibe network (either wireless or wired). I've my notebook at different physical sites with no issues.

Any help or hint would be appreciated.

Thanks.

[ZaneP]

So you're not having any problems when outside the Bell domain?

Have you done a traceroute to the remote server when you're at home on your LAN? It will show the routing and may reveal some issues when your ssh rclient is making the connection request.

Cheers,

ZaneP

I don't work for Bell, just a customer

[daaaveybaby · Accepted solution]

I tried all connectivity tests (ping, traceroute, etc.) before anything else.

I have found the cause of my problem. SSH is performing DNS checks on the incoming connections. There seems to be something with the Bell DNS servers that are causing a timeout with this authentication and verification cycle. Disabling the DNS validation portion of ssh authentication resolves the issue. Now everything is quite snappy.

[Nono31]

I have the exact same problem with SSH... only happens on Bell Wifi at home (tried at 2 homes with BELL). using hotspot (fizz, bell) or wifi on other ISP, I have no problem. 

How did you disabled dns check?

[daaaveybaby]

On my Linux machine, I edited /etc/ssh/ssd_config and set the following:

UseDNS no

Then restarted sshd, e.g. "systemctl restart sshd"

[Nono31]

then that's on the server level... which I can't change... 😞

thanks!

[Vanadiel]

It's normal behavior because it's doing a forward and reverse DNS check on your IP. It will fail because the DNS server used has no record for your domain and that IP for a reserve lookup. You only have that record locally for a forward lookup. You would need to have access to the authoritative server for that zone in order to map the hostname to that IP. It's a safety feature as that is another thing a potential hacker would need to be able to access and modify in order for reverse lookup and forward lookup to your local domain to work.

[Nono31]

@Vanadiel you are saying that we should keep `UseDNS on` ? if so Bell needs to fix their side. I am connecting to the ssh a lot per day, loosing a lot of time because of this issue... 😞

[Vanadiel]

No, I am not saying that. What I am saying is that part of the protocol is to perform a forward and reverse DNS check. It's not an issue with Bell and not something they need to fix.

If you are performing SSHD from an IP that has a proper domain associated with it, it will not fail.

But it will fail if you perform it from a LAN in the range of 192.168.x.x. A possible solution would be to use DMZ and get an external IP address. This way the DNS server will have a proper DNS record for both forward and reverse lookup.

[daaaveybaby]

If it's giving you problems, then definitely disable UseDNS. From what I can see it's only used for host-based authentication, which can be important if you are making use of keys + hostnames for your authentication; but if you're not using that then there's no problem.

Regarding DNS resolution. I've tested frontways and backways from my IPs without issue. Everything resolves properly. (i.e. ptr and a records exist and match.) There's something about the Bell network that gives me trouble. If I try my connections from other networks I have no issues. (I roam a lot.) However, whatever the issue is it is not significant enough to warrant a great deal of my time. Koodos to anyone who has the time and inclination to figure this out.

[Vanadiel]

The only downside to disable UseDNS is that the log file will only show IP's, not resolved host names. That might make it a bit harder to read should you need to read it.

[Nono31]

I just disabled it on the server... which solved my issue... 

I still wonder why this in only an issue on BELL fibe and not other ISP... 🤔