(bash) ssh to other systems fails to connect

Thank you for your bug report. To analyze the problem's potential cause, some debug output would be helpful. Please retry the connection with "ssh -vvv sage@..." and attach the output.

By the way, if the "15 sec delay" appeared only after your upgrade to feisty, it may be related to bug #84899.

This issue was resolved with a corrected /etc/ssh/sshd.conf file

.conf changes made

LoginGraceTime 20
useDNS no

Sorry for the bother

> Sorry for the bother

Not at all! The Community is here to help. Regarding your problem with SSH:

The "resolution" you described seems more like working around the problem. Changing "UseDNS" to "no" will simply prevent sshd from commencing a reverse DNS lookup. The real issue is thereby circumvented, not solved.

A lot of people are having similar DNS-related problems with Feisty, so I strongly suspect that also in your case Avahi's mDNS is the real culprit. Please try the following:

1. Undo your changes to /etc/ssh/sshd_config (that's what you meant when you said sshd.conf, I suppose), i.e. remove the lines saying "LoginGraceTime" and "useDNS".

2. In /etc/nsswitch.conf, replace the line
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
with
hosts: files dns

This will tell all nsswitch-aware programs (including SSH) to skip DNS lookups via mDNS, probably speeding up the lookup process so that SSH connection attempts won't hit the login grace time.

("LoginGraceTime" defaults to 120 seconds, by the way, so specifying "20" probably didn't contribute to improving your situation.)

You are correct the fix I implemented was a work around but at the same time I had no need for reverse DSN lookup.

At any rate
I made the requested changes to /etc/nsswitch.conf
hosts: files dns

I also commented out the following lines in /etc/ssh/sshd_config
LoginGraceTime 20
useDNS no

This corrected my problem, it would seem based on your description however that my problem was really a symptom of the problem.
There is now a slight pause (approx 3-4 sec) after the password is entered before ssh displays /etc/motd, is this due to the system checking what is specified in the hosts: files dns line in /etc/nsswitch.conf

Thanks again for the help.

(looking back on it I specified the LoginGraceTime value based on a Debian system hardening website/walk through ....thoughts?)

> There is now a slight pause (approx 3-4 sec) after the password is entered before ssh displays /etc/motd, is this due to the system checking what is specified in the hosts: files dns line in /etc/nsswitch.conf [?]

A delay *after* authentication is probably caused by your login shell's startup sequence on the server side. For example, bash executes /etc/profile, /etc/bash.bashrc, ~/.bash_login, ~/.profile, and ~/.bashrc in order. You can trace how long each script takes to execute by adding a line like e.g. »echo "/etc/profile"« to the bottom.

Anyway: To further cut down on delay *before* password authentication, add "GSSAPIAuthentication no" to /etc/ssh/ssh_config on your client. This will prevent SSH from requesting GSSAPI auth, which would fail silently anyway because it is disabled by the default sshd_config shipped in Ubuntu. (Except, of course, if you explicitly deployed Kerberos.)

> looking back on it I specified the LoginGraceTime value based on a Debian system hardening website/walk through ....thoughts?

One could imagine a Distributed Denial of Service attack where multiple foreign hosts bombard the server with new connection attempts. This will leave this server's CPU(s) commited to answering connection attempts while doing little other work, exhaust the server's memory and file descriptor resources, and overflow the session tables of any stateful firewalls or NAT routers that happen to sit in front of the server.

Lowering LoginGraceTime will shorten the timeout until sshd closes an unauthentified incoming connection. Lowering MaxStartups will limit the maximum number of concurrent unauthentified connections. These two settings will lessen the damage somewhat, though with a side effect: Your incoming SSH connections won't be treated any differently, effectively locking you out of your own system.

There's probably more to it, but these are my thougths :)

Thanks for the input...I am satisfied with the fixes we have implemented.

Could you please (as a test) try the connection with GSSAPIAuthentication disabled anyway? This would help to distinguish the issues you were experiencing from those described in bug #84899. The easiest way to do this:

  ssh -vvv -oGSSAPIAuthentication=no sage@192.168.1.2 >>ssh-nogssapi-nomdns.log 2>&1

This will disable the GSSAPI setting only for this connection, and additionally log every single step taken by SSH to a file called »ssh-nogssapi-nomdns.log« in your current directory. Please attach this log file to your next comment.

As I can't find a solution to that SSH problem, I did try that

ssh -vvv -oGSSAPIAuthentication=no sage@192.168.1.2 >>ssh-nogssapi-nomdns.log 2>&1

See attachment.
Many thanks for your work.

Is this still a problem for you? What about in Hardy or Intrepid?

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!