# ssh requires lots of time for login



## krnlpk (Sep 12, 2010)

I've the default 8.1-RELEASE openssh installed on my machine. This is my sshd_config file:

```
#	$OpenBSD: sshd_config,v 1.81 2009/10/08 14:03:41 markus Exp $
#	$FreeBSD: src/crypto/openssh/sshd_config,v 1.49.2.2.2.1 2010/06/14 02:09:06 kensmith Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

#VersionAddendum FreeBSD-20100308

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	.ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable PAM authentication
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs server
```

When the daemon loads on startup, it takes to minutes, and when I log in from another computer to the bsd one, I have to wait much longer than on Linux to see the passphrase request.
Why? I've already tried to recompile /usr/src/secure.


----------



## phoenix (Sep 12, 2010)

Double-check your DNS settings on the server and on the client.  You need to be able to run `$ host <server hostname>` or `$ ping <server hostname>` and it resolves to an IP address.

If those fail, then you either need to fix your local DNS server that has the hostname<-->IP mappings.

Or, add the hostname/IP address of the *server* to /etc/hosts file on the *client*.

And the hostname/IP address of the *client* to the /etc/hosts file on the *server*.


----------



## krnlpk (Sep 12, 2010)

Two computer can ping together well, without any slowdown. 
I can login to FreeBSD, but I have to wait much, much longer than Linux. And this is strange.


----------



## phoenix (Sep 12, 2010)

They can ping by name?  Not by IP address.


----------



## krnlpk (Sep 12, 2010)

phoenix said:
			
		

> They can ping by name?  Not by IP address.



if I add something in hosts like 
	
	



```
192.168.1.118 FreeBSD
```
 I can ping 192.168.1.118 using ping FreeBSD. But the problem is not that I can't connect, it's the extreme slowness of the sshd daemon when loading and when a connection is going to be established.


----------



## AlexJ (Sep 12, 2010)

Try to add 

```
UseDNS no
```
to /etc/ssh/sshd_config
Use IP of ssh server only when connecting.

If it help then you have problem with your DNS server (of DNS-forwarder)

What "hostname" command return?
It should return FQDN of your host, not just a name of host.
Do you use static IP or obtain IP address over DHCP for SSH server?
Try "sysinstall" and in the section of network configuration set correct values.


----------



## phoenix (Sep 12, 2010)

krnlpk said:
			
		

> if I add something in hosts like
> 
> 
> 
> ...



Exactly.  It's a DNS (hostname to IP translation) issue, just as I suspected.

When ComputerA connects to ServerB using "ssh serverb", first ComputerA does a hostname lookup to get the IP address of ServerB.  If there's no entry in /etc/hosts, then it does a DNS lookup (incorrectly configured, it can take up to 2 minutes to fail).  Once ComputerA has the IP, then it connects to the SSH daemon on ServerB.

ServerB will look at the IP address of the connection and do a reverse hostname lookup.  If the IP of ComputerA is not listed in /etc/hosts, then it will do a DNS lookup (incorrectly configured, this can take up to 2 minutes to fail).  Only once the DNS lookup has failed, or the SSH daemon has confirmed the "ComputerA has IP x.x.x.x and and x.x.x.x has name ComputerA" will it allow the login to continue.

On ServerB, the shell can also do some hostname lookups, depending on what's in your shell configuration files, also slowing things down.

IOW, the solution is:

configure a DNS server that has all the A and PTR records for all the hostnames/IPs on your network, and use that DNS server in /etc/resolv.conf on all stations, or
configure /etc/hosts on every computer with entries for every IP and hostname on your network.

After that, your logins should be almost instantaneous.


----------



## krnlpk (Sep 12, 2010)

I've found an error in FreeBSD hosts file; after correcting it, it just tooks 10-20 seconds more than the Linux counterpart on the same server, which response is pratically immediate, why? I've modified client hosts, this is how they looks now:

Linux client /etc/hosts


```
127.0.0.1       localhost
192.168.1.118   EeePC
192.168.1.117   Arch
192.168.1.121   FreeBSD FreeBSD.kan.col
[some ipv6 stuff]
```

FreeBSD server /etc/hosts

```
::1                     localhost localhost.kan.col
127.0.0.1               localhost localhost.kan.col
192.168.1.121           FreeBSD.kan.col FreeBSD
192.168.1.121           FreeBSD.kan.col.
192.168.1.118           EeePC
```


----------



## AlexJ (Sep 14, 2010)

krnlpk said:
			
		

> I've found an error in FreeBSD hosts file
> 
> ...
> 
> after correcting it, it just tooks 10-20 seconds more than the Linux counterpart on the same server, which response is pratically immediate, why?



*"hosts" file care information for resolving on particular machine, but not for introducing itself to the world.*

You can write in your "hosts" file whatever you want - you can even override any domain name in the world:

```
127.0.0.1 google.com
```
but it will take affect only on that particular host. I'll still able connect to google.com regardless your "hosts" file settings, but you wouldn't, because it applied only for your single machine only where is that "hosts" file live.

Shortly - DNS in your network really don't care about your settings in the "hosts" file.
If you use static IP then you SHOULD told to DNS server about your wishes.
If you use DHCP then you should play by its rule.

Run command "hostname" on FreeBSD then run "nslookup 192.168.1.121" on another machine in your network - respond of "nslookup" SHOULD match with respond of "hostname".


----------



## krnlpk (Sep 14, 2010)

AlexJ said:
			
		

> *"hosts" file care information for resolving on particular machine, but not for introducing itself to the world.*
> 
> You can write in your "hosts" file whatever you want - you can even override any domain name in the world:
> 
> ...




So, how can I fix it?


----------



## clintm (Jun 16, 2013)

Registered to add an answer to this question since there wasn't one already.

Edit /etc/nsswitch.conf and change the order of resolution for hosts.

By default:

```
hosts: files dns
```

Change this to:

```
hosts: files mdns dns
```

This requires that you install dns/nss_mdns.


----------

