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

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?

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

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.)

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.