xbianonpi / xbian

XBMC on Raspberry Pi, Bleeding Edge
https://xbian.org
GNU General Public License v3.0
294 stars 44 forks source link

Adding 2 options to /etc/ssh/sshd_config - speeding up SSH massively #418

Closed ventz closed 11 years ago

ventz commented 11 years ago

Hi,

Would it be possible to add to /etc/ssh/sshd_config:

UseDNS no AddressFamily inet

The first one is a bit obvious - it will ignore the reverse resolution, thus speeding up the connection. Almost everyone usually adds that one. The second however, starting with Ubuntu 12.04, it seems that it attempts to connect via ipv6 and ends up falling back to ipv4. This takes time. By specifying 'inet' as the family, it will only attempt to ssh in via ipv4.

Iri-Dium commented 11 years ago

Seems to work. Before ~5 seconds. After ~2.5 seconds.

simonvetter commented 11 years ago

Please do not apply # 2 as people do use ipv6. What do you mean by "it attemps to connect via ipv6"? If ipv6 is not enabled on your system or network no attempt to use it will be made.

CurlyMoo commented 11 years ago

I can confirm this is a lot faster.

ventz commented 11 years ago

Simon - true, there are people that use ipv6, but I am assuming the majority at this point don't yet - not at least for this purpose anyway. Maybe it can be provided as an option during setup? (enable ipv6?) Or if ipv6 is detected, the option can be removed from sshd_config? It looks like the SSH daemon by default binds on "any" AddressFamily, and because IPV6 support exists internally, it literally waits for the timeout since if you use ipv4 there isn't an ipv6 connection. I did notice that starting with Ubuntu 12.04, this makes an bigger difference than on Debian. Either way, the bigger speedup is the UseDNS option.

CurlyMoo commented 11 years ago

@ventz, maybe you can implement this autodetection yourself and do a pull request?

mk01 commented 11 years ago

the time (5s vs. 2s) is what time? time to connect to xbian's ssh? with wrongly set local dns or no local dns, this will avoid useless query. with proper dns record, there is no difference and the connect and logout is

(14:42) [aivka:~] amk$ time ssh xbian@xbian exit
Host key fingerprint is f7:08:0b:7e:29:42:9c:8b:5b:f4:a4:52:64:2c:0a:41

real    0m0.224s
user    0m0.014s
sys 0m0.007s

if someone is interested in data transfer speedup, use cipher arcfour ("-c arcfour" - when connection from client, or "cipher arcfour" in sshd_config on server side).

mk01 commented 11 years ago

@ventz ipv6 support is currently build as module and by default blacklisted in /etc/modprobe.d/ipv6.conf

until you manually do "sudo mod probe ipv6", the module can't be loaded automatically due some dependency needs - so support is off by default.

so if someone removes this blacklist record, then probably the reason was need for ipv6 support.

CurlyMoo commented 11 years ago

It's all about the time between the login: and the actual motd. That improves with these settings.

simonvetter commented 11 years ago

@CurlyMoo at the time at which ssh asks for a password, the connection to the server is already made, so the only relationship with ipv6 that I can see would be the reverse dns lookup (which UseDNS no should solve). No need to disable listening over ipv6, I believe.

With the default configuration (without the proposed patch), I do not see the reported delay on MacOS X, neither over ipv6 nor ipv4. I have not set up any specific DNS record.

$ time ssh -6 xbian@xbian.local exit

real 0m0.532s user 0m0.023s sys 0m0.007s $ time ssh -4 xbian@xbian.local exit

real 0m0.430s user 0m0.022s sys 0m0.007s

What I do see is a noticeable delay between motd and the actual prompt when logging in, but that's a different story altogether. My take on this is that the xbian-config scripts do take some time.

I will try to spin an ubuntu VM to narrow down the problem.

@ventz what does your nsswitch.conf file look like? Could you try with hosts: files mdns_minimal [NOTFOUND=return] dns mdns e.g. replace mdns4 with mdns, and see if that makes any difference?

mk01 commented 11 years ago

@simonvetter can you post your /etc/profile and check /etc/bash.bashrc how much you have uncommented (completions / profiles / aliases etc).

also, just to compare, try "UsePAM no" in sshd_config.

ventz commented 11 years ago

Simon - I haven't touched the nsswitch.conf - it's the default one. I'll try it as soon as I get back to civilization and near a computer.

I noticed that there is a small delay for the prompt too. I commented out the xbian-config originally, and there was still an "interesting" delay, but not big enough to matter.

mk01 commented 11 years ago
I noticed that there is a small delay for the prompt too. I commented out
the xbian-config originally, and there was still an "interesting" delay,
but not big enough to matter.

please https://github.com/xbianonpi/xbian/issues/418#issuecomment-20943014

CurlyMoo commented 11 years ago

The greatest speed change was between the password and the actual motd message. This happened after the changing of these settings.

Iri-Dium commented 11 years ago

Whilst I agree it is a lot faster for those of us in Dinosaur Land with RPi and closed N/W, is it actually worth the bother of implementing a check.

Surely it would be easier to post a message, with the fix on the Forum, and let people decide if they want to implement it - it's not that difficult.

I like the fix it sure helps me, but for a second or two, is it really worth worrying about?

mk01 commented 11 years ago

@Iri-Dium you mean the usedns ? I see no reason why not do it, logging is default off so doesn't matter and I suppose nobody is logging to RPI via kerberos tickets and auth servers, so ... ;)

@CurlyMoo can you please post sed miracle for that ? ;)

CurlyMoo commented 11 years ago

Nothing much to sed about. There are only two lines that need to be added. If they already exist, a user must have had altered these settings manually, and nothing should happen.

mk01 commented 11 years ago

which second line? still the ipv6 story? ipv6 is disabled. if someone enables it, then indeed has to decide about ssh proto usage.

CurlyMoo commented 11 years ago

I had to add: UseDNS no AddressFamily inet Manually

mk01 commented 11 years ago

I'm just asking, what else should ssh use, when the only configured is INET. check ifconfig output:

root@xbian:~# ifconfig | grep addr:
          inet addr:192.168.1.126  Bcast:192.168.1.255  Mask:255.255.255.0
          inet addr:127.0.0.1  Mask:255.0.0.0

if you have other AF configured, then you wanted to have it configured. should someone disable by you configured AF in sshd ???

mk01 commented 11 years ago

already at git or debs at daily repo

mk01 commented 11 years ago

jus was thinking, why I didn't mention before, but on such devices I always install the old ugly insecure rlogin and rsh.

plain text is not fashionate enough today, but how fast it is ! and how little resources it uses ;)

anaconda commented 10 years ago

This is just impossible.

If IPv6 is not enabled (i.e. module not loaded) it won't bind on IPv6 (how can it do?).

Furthermore, SSHd is started behind inetd on default installs, at least as of current releases. I'm going to revert AddressFamily inet if nobody voices against. It's just silly to enforce IPv4 if the user manually enabled IPv6.

andrew-scorchsoft commented 5 years ago

Hi,

Would it be possible to add to /etc/ssh/sshd_config:

UseDNS no AddressFamily inet

The first one is a bit obvious - it will ignore the reverse resolution, thus speeding up the connection. Almost everyone usually adds that one. The second however, starting with Ubuntu 12.04, it seems that it attempts to connect via ipv6 and ends up falling back to ipv4. This takes time. By specifying 'inet' as the family, it will only attempt to ssh in via ipv4.

Horray! I can confirm this solution worked for me. Thank-you for your reply.

slintz commented 5 years ago

This solved my problem-case: Ansible very slow connecting to remote target.

FYI - Ansible makes many (many!) SSH connections in the course of it's regular process. It just keeps reaching out - and when "UseDNS no" was in place my Ansible task times dropped from minutes to seconds - each task, for each target system. Saved me years of wait time...