Sembra che quanto segue funzionerebbe come previsto, vale a dire che la seconda regola, con un nome host che corrisponde alla prima regola, la applicherebbe.
Host *.hostname.com
User myuser
IdentityFile ~/.ssh/myidentity
Host blah
HostName complicated.hostname.com
Tuttavia, la digitazione ssh blahapplica solo la seconda regola (e non il file utente o identità della prima).
Ho due domande:
Risposte:
Dalla ssh_configpagina man:
Per ogni parametro, verrà utilizzato il primo valore ottenuto. I file di configurazione contengono sezioni separate da specifiche "Host" e tale sezione viene applicata solo agli host che corrispondono a uno dei modelli indicati nelle specifiche. Il nome host corrispondente è quello indicato sulla riga di comando.
Poiché viene utilizzato il primo valore ottenuto per ciascun parametro, dovrebbero essere fornite più dichiarazioni specifiche dell'host vicino all'inizio del file e impostazioni predefinite generali alla fine.
Inoltre, mi assicurerei di capire queste 2 sezioni se non sei chiaro su come funzionano l'host e i PATTERN. È in corso solo 1 livello di corrispondenza. Questa funzione è molto basilare nelle sue capacità regex, ma è ancora potente una volta che lo hai scoperto.
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.
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"
Il problema con il tuo approccio è che il modello che corrisponde alla prima sezione Host non corrisponde alla seconda. In genere faccio qualcosa del genere:
Host *
User myuser
IdentityFile ~/.ssh/myidentity
Host blah
HostName complicated.hostname.com
Una cosa che di solito le persone non accettano con queste regole è che possono ripetere. Quindi quello che faccio spesso è avere più sezioni e le rompo usando quelle Host *di.
Host *
User user1
Host blah1
HostName complicated1.hostname.com
Host blah2
HostName complicated2.hostname.com
Host *
User user2
Host *che seguono la seconda che verranno abbinate useranno user2 come utente predefinito, a meno che non lo specifichino esplicitamente.
Host *viene raggiunto il 2 °, si applica la regola del "primo valore ottenuto per ogni parametro utilizzato" e quindi questa e tutte le Userdefinizioni seguenti vengono ignorate. Un'eccezione a questa regola sono le IdentityFileparole chiave, tra l'altro.
SSH applica tutte le sezioni che corrispondono al nome host fornito sulla riga di comando (ovvero le HostNameregole che incontra non influiscono sui successivi controlli delle condizioni). Se CanonicalizeHostnameabilitato, riapplicherà nuovamente i file di configurazione al termine, utilizzando il nome host aggiornato. (Alcune versioni di SSH lo hanno fatto indipendentemente CanonicalizeHostnamee il tuo esempio funzionerebbe con quelle versioni; ma questo è considerato un bug dagli sviluppatori SSH. Vedi # 2267. )
Il che significa che puoi usare CanonicalizeHostnameper far funzionare il tuo esempio, aggiungendo
Host *
CanonicalizeHostname yes
CanonicalizeFallbackLocal no
che non eseguirà alcuna canonicalizzazione ma consentirà di eseguire un secondo passaggio con il nome host aggiornato. (Nota che non renderà ancora l'analisi della configurazione "ricorsiva", ripeti solo una volta. Quindi se cambi il nome host due volte, non funzionerebbe.)
Host nickname; Hostname hostnamestanze non sono più in grado di fornire il soprannome. Funzionerà se aggiungi la CanonizalizeHostname yesparola chiave in ogni blocco di nickname, ma questo raddoppia la dimensione dei blocchi di nickname e sembra brutto.
Dalla pagina man
Per ogni parametro, verrà utilizzato il primo valore ottenuto. I file di configurazione contengono sezioni separate da specifiche '' Host '' e tale sezione viene applicata solo agli host che corrispondono a uno dei modelli indicati nelle specifiche. Il nome host corrispondente è quello indicato sulla riga di comando.
Poiché viene utilizzato il primo valore ottenuto per ciascun parametro, dovrebbero essere fornite più dichiarazioni specifiche dell'host vicino all'inizio del file e impostazioni predefinite generali alla fine.
Prova a cambiare l'ordine delle voci.