Pourquoi les règles ne se combinent-elles pas dans un fichier de configuration ssh?


12

Il semble que ce qui suit fonctionnerait comme prévu, c'est-à-dire que la deuxième règle, ayant un nom d'hôte correspondant à la première règle, l'appliquerait.

Host *.hostname.com
 User myuser
 IdentityFile ~/.ssh/myidentity

Host blah
 HostName complicated.hostname.com

Cependant, la saisie ssh blahs'applique uniquement à la deuxième règle (et non au fichier utilisateur ou d'identité de la première).

J'ai deux questions:

  1. Pourquoi cela arrive-t-il?
  2. Est-il possible de faire (simplement) ce que j'essaie de faire?

Réponses:


9

Depuis la ssh_configpage de manuel:

Pour chaque paramètre, la première valeur obtenue sera utilisée. Les fichiers de configuration contiennent des sections séparées par des spécifications «Host», et cette section n'est appliquée qu'aux hôtes qui correspondent à l'un des modèles indiqués dans la spécification. Le nom d'hôte correspondant est celui donné sur la ligne de commande.

Étant donné que la première valeur obtenue pour chaque paramètre est utilisée, des déclarations plus spécifiques à l'hôte doivent être fournies vers le début du fichier et des valeurs par défaut générales à la fin.

De plus, je m'assurerais de bien comprendre ces 2 sections si vous ne savez pas comment l'hôte et les modèles fonctionnent. Il n'y a qu'un seul niveau de correspondance en cours. Cette fonctionnalité est très basique dans ses capacités d'expression régulière, mais est toujours puissante une fois que vous l'avez fait.

Sections hôtes

 The possible keywords and their meanings are as follows (note that keywords 
 are case-insensitive and arguments are case-sensitive):

 Host    Restricts the following declarations (up to the next Host keyword) 
         to be only for those hosts that match one of the patterns given
         after the keyword.  If more than one pattern is provided, they 
         should be separated by whitespace.  A single ‘*’ as a pattern can 
         be used to provide global defaults for all hosts.  The host is the 
         hostname argument given on the command line (i.e. the name is not
         converted to a canonicalized host name before matching).

         A pattern entry may be negated by prefixing it with an exclamation 
         mark (‘!’).  If a negated entry is matched, then the Host entry is      
         ignored, regardless of whether any other patterns on the line 
         match.  Negated matches are therefore useful to provide exceptions 
         for wildcard matches.

         See PATTERNS for more information on patterns.

MOTIFS

 A pattern consists of zero or more non-whitespace characters, ‘*’ (a 
 wildcard that matches zero or more characters), or ‘?’ (a wildcard that
 matches exactly one character).  For example, to specify a set of 
 declarations for any host in the “.co.uk” set of domains, the following
 pattern could be used:

       Host *.co.uk

 The following pattern would match any host in the 192.168.0.[0-9] network 
 range:

       Host 192.168.0.?

 A pattern-list is a comma-separated list of patterns.  Patterns within 
 pattern-lists may be negated by preceding them with an exclamation
 mark (‘!’).  For example, to allow a key to be used from anywhere within an 
 organisation except from the “dialup” pool, the following entry
 (in authorized_keys) could be used:

       from="!*.dialup.example.com,*.example.com"

Règles de superposition

Le problème avec votre approche est que le modèle qui correspond à la première section hôte ne correspond pas au deuxième. Je fais généralement quelque chose comme ça:

Host *
 User myuser
 IdentityFile ~/.ssh/myidentity


Host blah
 HostName complicated.hostname.com

Une chose que les gens ne comprennent généralement pas avec ces règles, c'est qu'ils peuvent répéter. Donc, ce que je fais souvent, c'est avoir plusieurs sections et je les décompose à l'aide Host *de.

Host *
 User user1

Host blah1
 HostName complicated1.hostname.com

Host blah2
 HostName complicated2.hostname.com

Host *
 User user2

3
Dans votre exemple, comment définir "user2"? Je pensais que la première valeur obtenue pour un hôte était utilisée, donc chaque hôte correspondra au premier bloc et aura "user1" défini?
jdm

@jdm - Les règles d'hôte qui viennent après le 2e Host *qui sont mises en correspondance utiliseront user2 comme utilisateur par défaut, sauf si elles le spécifient explicitement elles-mêmes.
slm

@slm: J'ai trouvé que cela ne fonctionnait pas. Si vous enchaînez deux Host * User xxx puis Host * User yyy, la règle suivante utilisera "xxx" - sauf si je fais quelque chose de mal.
Jérémie

@slm, votre exemple ne fonctionne pas. Au moment où le 2e Host *est atteint, la règle de la «première valeur obtenue pour chaque paramètre est utilisé» s'applique et ainsi cette Userdéfinition et toutes les définitions suivantes sont ignorées. Les IdentityFilemots - clés, btw, font exception à cette règle .
maxschlepzig du

5

SSH applique toutes les sections qui correspondent au nom d'hôte comme indiqué sur la ligne de commande (c'est-à-dire que les HostNamerègles qu'il rencontre n'affectent pas les vérifications de conditions ultérieures). Si CanonicalizeHostnameest activé, il réappliquera les fichiers de configuration à la fin, en utilisant le nom d'hôte mis à jour. (Certaines versions SSH ont fait cela indépendamment CanonicalizeHostnameet votre exemple fonctionnerait avec ces versions; mais cela est considéré comme un bogue par les développeurs SSH. Voir # 2267. )

Ce qui signifie que vous pouvez utiliser CanonicalizeHostnamepour faire fonctionner votre exemple, en ajoutant

Host *
  CanonicalizeHostname yes
  CanonicalizeFallbackLocal no

qui ne fera aucune canonisation mais permettra de faire une deuxième passe avec le nom d'hôte mis à jour. (Notez qu'il ne rendra toujours pas l'analyse de configuration "récursive", répétez-la une seule fois. Donc, si vous changez le nom d'hôte deux fois, cela ne fonctionnera pas.)


1
J'ai récemment mis à jour Ubuntu 14.04 vers 16.04, et avec lui est venu ce bug. Cette réponse est parfaite; cela me ramène au comportement d'origine. Merci!
Brian Malehorn

ugh # 2267 signifie que les Host nickname; Hostname hostnamestrophes ne sont plus en mesure de fournir un surnom. Cela fonctionnera si vous ajoutez le CanonizalizeHostname yesmot - clé dans chaque bloc de surnom, mais cela double la taille des blocs de surnom et semble laid.
studog

1

Depuis la page de manuel

Pour chaque paramètre, la première valeur obtenue sera utilisée. Les fichiers de configuration contiennent des sections séparées par des spécifications '' Host '', et cette section n'est appliquée qu'aux hôtes qui correspondent à l'un des modèles donnés dans la spécification. Le nom d'hôte correspondant est celui donné sur la ligne de commande.

Étant donné que la première valeur obtenue pour chaque paramètre est utilisée, des déclarations plus spécifiques à l'hôte doivent être fournies vers le début du fichier et des valeurs par défaut générales à la fin.

Essayez de changer l'ordre de vos entrées.


Malheureusement, changer l'ordre des entrées ne fonctionne pas (c'était en fait l'ordre que j'avais utilisé à l'origine).
Jérémie

S'il existe plusieurs définitions d'hôte correspondant au nom d'hôte auquel vous vous connectez, tous les paramètres définis dans chacun d'entre eux seront fusionnés en une seule définition. Quand il dit "la première valeur obtenue", cela parle de choses au niveau des paramètres, pas au niveau de l'hôte. Ceci est contre-intuitif si vous pensez que chaque bloc hôte est une définition.
Giovanni Tirloni
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.