2

What if one host is defined in /etc/hosts like:

192.168.0.100   server

and one is defined in ~/.ssh/config like:

 Host    server
         HostName    192.168.0.101

and you ssh into server: ssh server.

How would such a conflict be resolved? I guess one has higher priority than the other.

2

If you do ssh server the server part could be a real host name or some ssh internal "nickname". ssh first looks for some nickname in .ssh/config, if it finds a configuration there it will use this. If it does not find a configuration it assumes a real hostname and tries to resolve it via /etc/host and dns.

1

The file ~/.ssh/config has nothing to do with /etc/hosts. Rather it's a configuration file for ssh to use if it exists.

You can see that ssh refers to this file prior to doing anything else by using the verbose switch, -v, to ssh.

Host entry in ~/.ssh/config

Here I have an entry in my ~/.ssh/configfile for a server named "skinner". I'm enabling debug level 3 by including 3 -v's switches.

Example
$ ssh -vvv skinner 
OpenSSH_6.2p2, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/saml/.ssh/config
debug1: /home/saml/.ssh/config line 8: Applying options for *
debug1: /home/saml/.ssh/config line 35: Applying options for skinner
debug1: /home/saml/.ssh/config line 55: Applying options for *
debug3: cipher ok: arcfour [arcfour,blowfish-cbc]
debug3: cipher ok: blowfish-cbc [arcfour,blowfish-cbc]
debug3: ciphers ok: [arcfour,blowfish-cbc]
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for *
debug1: auto-mux: Trying existing master
...

In the above you can see that ssh is making use of this definition and not even consulting the system's name resolution facilities.

No host entry in ~/.ssh/config

If there is no corresponding entry in the ~/.ssh/config file, then ssh will consult the system's DNS resolution to find out how to connect to a hostname that's been specified.

Example
$ ssh -vvv skinner
OpenSSH_6.2p2, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/saml/.ssh/config
debug1: /home/saml/.ssh/config line 8: Applying options for *
debug1: /home/saml/.ssh/config line 55: Applying options for *
debug3: cipher ok: arcfour [arcfour,blowfish-cbc]
debug3: cipher ok: blowfish-cbc [arcfour,blowfish-cbc]
debug3: ciphers ok: [arcfour,blowfish-cbc]
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/saml/.ssh/master-saml@skinner:22" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to skinner [192.168.1.3] port 22.
debug1: Connection established.

Here you can see that ssh is consulting the system to find out the IP address for the hostname "skinner".

NOTE: You can use getent to look up hostnames on your system:

$ getent hosts skinner
192.168.1.3     skinner.dom.net
-1

Generally, for Unix software in general, user-specific settings (in this case, ~/.ssh/config) would override system-wide settings (in this case, /etc/hosts); thus, the settings in ~/.ssh/config would be higher priority.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.