long delay during ssh login

Question

When I connect to my Debian server via ssh, the ssh client tries to establish a IPv6 connection. This fails after a long timeout (~30sec), then falls back to IPv4, which then succeeds, and I'm prompted for a password.

This is quite annoying, because I often miss the time I can enter the password (password timeout feels really short in comparison), and I have to sit through this again.

This happens both on Windows via putty and on my Debian machine using the standard ssh client.

I like to fix this either by making the IPv6 connection working or by directly connecting via IPv4.

• How can I find out why I'm unable to connect via IPv6?
• How can I configure my ssh client to connect via IPv4?

Here is what my output of ssh is like (changed personal data)

> ssh -v [email protected]
OpenSSH_6.9p1 Debian-2, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: /home/someuser/.ssh/config line 12: Applying options for somedomain.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to somedomain.com [1234:1234:1234:1234::1] port 12345.

after this ssh waits for ~30sec (as mentioned above), and then falls back to IPv4 and I can login as usual.

update

I did some testing, and I think the server is not setup correctly for IPv6 (although ping6 ::1 and ssh -6 ::1 worked). For now I will configure my ssh clients to use IPv4 until I figured out how to fix IPv6 on my server.

Solution

The best approach, in my opinion, is to get things working (rather than working around what isn't working). So, fix IPv6.

Does ping6/ping for IPv6 work? Can you ssh to "::1"? Does firewall rules permit the incoming traffic to the IPv6 address?

Is Reverse DNS set up? If not, OpenBSD FAQ about Reverse DNS specifically describes this behavior in OpenSSH, and adjusting that by getting Reverse DNS working or by adding entries to a /etc/hosts file.

Or, if you'd like to not follow my earlier advice of getting things to work instead of performing a workaround, you could disable the lookups (rather than make the lookups succeed).

This guide says to add UseDNS=no to the sshd_config file (and then don't forget to have sshd reload the config), and also have sshd be started with the "-u0" option.

Comments

[Admin]

Could you add the output of ssh -vvvvv [email protected]?

[Admin]

You can always use the -4 option to force an IPv4 connection, so you get something like ssh -4 host.example.com. But obviously fixing IPv6 connections is the cleaner approach.

[Admin]

For your system to try to use IPv6 there have to be at least three things: 1. the hostname your are connecting to has an AAAA DNS record. 2. Your local system thinks it has IPv6 connectivity. 3. Your IPv6 connectivity doesn't work and you are not getting proper ICMPv6 errors that would make your system stop trying IPv6

[Sander Steffann]

Please be aware that disabling IPv6 often results in unsupported configurations these days. A better solution would be to try to find out what is going wrong.

[Daniel]

It's possible that there's a switch somewhere in his ISP's network or the server's network that doesn't support IPv6.

[Daniel]

There also could be a setting in PuTTY to disable IPv6 ssh.

[Daniel]

See the.earth.li/~sgtatham/putty/0.60/htmldoc/…

[mic]

The ssh -4 solved the timeout problem, and I was also able to find such an option in putty. But I don't want to disable IPv6. I'm more interested in finding and fixing the problem.

[mic]

I'm more interested in fixing the problem than to work around it. So ssh to ::1 worked. But right now I'm trying to find a way to test IPv6 connectivity, since I have no machine for which I'm sure its IPv6 setup is correct.

[Daniel]

The problem is likely in a network somewhere between you and the server. I doubt that it's something you can fix.