Qual è la differenza tra authorized_keys e authorized_keys2?

Volevo solo un breve riassunto delle differenze tra loro e perché ce ne sono due?

In OpenSSH prima della versione 3, la pagina man di sshd diceva:

Il file $ HOME / .ssh / authorized_keys elenca le chiavi RSA consentite per l'autenticazione RSA nei protocolli SSH 1.3 e 1.5 Analogamente, il file $ HOME / .ssh / authorized_keys2 elenca le chiavi DSA e RSA consentite per l'autenticazione con chiave pubblica ( PubkeyAuthentication) nel protocollo SSH 2.0.

L' annuncio di rilascio per la versione 3 afferma che authorized_keys2 è obsoleto e tutte le chiavi devono essere inserite nel file authorized_keys.

L'uso di authorized_keys2 per il protocollo 2 è stato deprecato dal 2001 .

[ via ]

Inizialmente la differenza era per la differenziazione della versione.

Ma non preoccuparti più, poiché ora è 2possibile ignorarlo.

Un motivo davvero valido per utilizzare authorized_keys2 è se si dispone di un VPS con Arvixe in cui il team di supporto tecnico sovrascrive continuamente il authorized_keysfile.

Mi è piaciuto anche che esistesse un secondo file authorized_keys.

Uso e distribuisco il mio file autorizzato_chiave su più computer, limitando il mio accesso in modo che solo la mia casa principale possa accedere ad altri account. Ma questo generalmente significa che è lo stesso su tutti i miei account e viene sovrascritto se è diverso. Ho anche visto altri programmi di configurazione del computer sovrascriverlo continuamente (Puppet).

Tuttavia, quando accedo al nodo anteriore di un cluster di cumputing di grandi dimensioni, mi piace inserire le chiavi nel file authorized_keys2, in modo che il nodo anteriore possa accedere agli altri nodi del cluster, ma non abbia accesso a nessun altro computer. cioè l'ho usato come "file di autorizzazione locale", separato da un "file di autorizzazione distribuito".

Diventa particolarmente importante quando vengono utilizzate case condivise (come in genere si trovano in un cluster).

È un vero peccato che ora sia deprezzato.

Un'alternativa che sarebbe piacevole sarebbe un meccanismo di inclusione, o una sottodirectory "authorized_keys.d", o un 'usa queste chiavi per questo host'.