Was wird bei einem Konflikt zwischen ~/.ssh/config-Hostname und /etc/hosts priorisiert?

Was wird bei einem Konflikt zwischen ~/.ssh/config-Hostname und /etc/hosts priorisiert?

Was passiert, wenn ein Host wie folgt definiert ist /etc/hosts:

192.168.0.100   server

und eines ist wie ~/.ssh/configfolgt definiert:

 Host    server
         HostName    192.168.0.101

und Sie greifen per SSH auf den Server zu: ssh server.

Wie würde ein solcher Konflikt gelöst werden? Ich schätze, das eine hat eine höhere Priorität als das andere.

Antwort1

Wenn Sie dies tun, ssh serverkönnte der Serverteil ein echter Hostname oder ein interner SSH-Spitzname sein. SSH sucht zuerst in .ssh/config nach einem Spitznamen. Wenn es dort eine Konfiguration findet, wird diese verwendet. Wenn es keine Konfiguration findet, nimmt es einen echten Hostnamen an und versucht, ihn über /etc/host und DNS aufzulösen.

Antwort2

Die Datei ~/.ssh/confighat nichts damit zu tun /etc/hosts. Es handelt sich vielmehr um eine Konfigurationsdatei, die sshverwendet werden kann, wenn sie existiert.

Sie können sehen, dass sshauf diese Datei verweist, bevor Sie irgendetwas anderes tun, indem Sie den ausführlichen Schalter , -v, auf verwenden ssh.

Host-Eintrag in ~/.ssh/config

Hier habe ich in meiner Datei einen Eintrag ~/.ssh/configfür einen Server namens „Skinner“. Ich aktiviere Debug-Level 3, indem ich -vdie Schalter von 3 einschließe.

Beispiel
$ 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
...

Oben können Sie sehen, dass sshdiese Definition verwendet wird und nicht einmal die Namensauflösungsfunktionen des Systems konsultiert werden.

Kein Host-Eintrag in ~/.ssh/config

~/.ssh/configWenn in der Datei kein entsprechender Eintrag vorhanden ist , sshwird die DNS-Auflösung des Systems konsultiert, um herauszufinden, wie eine Verbindung zu einem angegebenen Hostnamen hergestellt werden kann.

Beispiel
$ 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.

Hier können Sie sehen, dass sshdas System abgefragt wird, um die IP-Adresse für den Hostnamen „skinner“ herauszufinden.

NOTIZ:Sie können Folgendes verwenden, getentum Hostnamen auf Ihrem System nachzuschlagen:

$ getent hosts skinner
192.168.1.3     skinner.dom.net

Antwort3

Bei Unix-Software allgemein ~/.ssh/confighaben benutzerspezifische Einstellungen (in diesem Fall ) Vorrang vor systemweiten Einstellungen (in diesem Fall ); daher hätten /etc/hostsdie Einstellungen in eine höhere Priorität.~/.ssh/config

verwandte Informationen