Perché utilizzare il file .PEM nel processo ssh

Entrambe le squadre stanno facendo la stessa cosa

Il team A ha utilizzato ssh-keygen, per creare una coppia di chiavi privata / pubblica, che ha memorizzato la parte privata su $HOME/.ssh/id_rsa e ha aggiunto la chiave pubblica al file authorized_keys sul server. Quindi, quando sshing sul server, per impostazione predefinita legge la chiave privata da lì, quindi accede al server senza inserire alcuna password.

Il team B ha chiamato il file in modo diverso (probabilmente utilizzava il parametro -f ) e utilizza -i ogni volta, altrimenti non lo troverebbe ssh.

In ogni caso, ssh ha bisogno del file della chiave privata (o accede direttamente al file privato o la chiave è già caricata in un agente ssh), solo il punto in cui si trova è diverso. Ci sono alcuni altri nomi di file chiave che tenta di default se esistono, e potresti specificare una posizione diversa su ~/.ssh/config (anche chiavi diverse per ciascun host se lo desideri!), Quindi non è necessario inserire esplicitamente la chiave nome file per ogni analisi.

(In entrambi i casi, la chiave potrebbe essere protetta con una passphrase, ma nessuno dei team sembra farlo)

Quindi, per rispondere alle tue domande:

What is benefit of using .Pem file?

Stai anche utilizzando il file chiave, è stato appena effettuato l'accesso in modo trasparente, quindi non c'è alcun vantaggio reale in ciò che fanno.

How is it better than the ssh model that we are using?

meglio è un termine soggettivo, ma IMHO è effettivamente meglio che dichiarare esplicitamente la chiave è non richiesto. Non posizionare la chiave nella posizione automatica sarebbe preferibile solo se si desidera utilizzare coppie di chiavi diverse e assicurarsi che non venga utilizzata automaticamente. Ma anche allora, per qualsiasi server a cui sono comunemente connesso, configurerei ssh per scegliere il file chiave corretto.

La corretta configurazione di ssh per la connessione semplifica l'utilizzo di configurazioni complesse, come l'accesso a una macchina interna che salta attraverso un host di bastion intermedi o esegue semplicemente un rsync (che non ha parametro -i diretto da passare al programma sottostante †)

† Considero molto più pulito fare rsync file server.com: rispetto a RSYNC_CONNECT_PROG='ssh -i /my/keyfile %H' rsync file server.com: ).

Sei in conflitto con più problemi e dovresti iniziare fermandoti a parlare di ".PEM files", il formato del file è per lo più irrilevante rispetto a quanto segue.

ssh funziona con le chiavi: chiavi allegate agli utenti e chiavi allegate ai server. Quando è iniziata, era la classica crittografia asimmetrica, ogni parte (server e utenti) ha almeno un paio di chiavi private + pubbliche e tutto ciò viene utilizzato per autenticare chi si connette a cosa.

Funziona bene ed è ancora probabilmente la chiave ssh di default più utilizzata.

Tuttavia potresti riscontrare principalmente problemi di gestione (invece che problemi tecnici) quando hai troppi host o utenti e vuoi un controllo a grana fine: ogni server deve essere configurato con un set specifico di chiavi utente e gli utenti devono conoscere un insieme specifico di chiavi del server se vogliono evitare il principio TOFU. Potresti anche volere più sicurezza intorno alle chiavi, essere in grado di revocare l'accesso facilmente, ecc.

Quindi ciò che è stato aggiunto in OpenSSH (versione 5.4 nel 2010 per la disponibilità iniziale e poi la versione 5.6 in per il supporto completo) è la possibilità di utilizzare non solo chiavi nude ma certificati X.509. I certificati X.509 incapsulano una chiave pubblica (dove si avrebbe la chiave privata in un file separato) con alcuni altri metadati, come le date di validità o altri vincoli per utilizzare questo certificato, e sono forniti da una specifica autorità di certificazione.

Per i server, l'uso di certificati significa che in pratica si ottiene lo stesso modello di oggi su HTTPS. Dove potrebbe essere più interessante è per le chiavi dell'utente. Ad esempio, non è necessario configurare il server con il set specifico di chiavi utente a cui è consentito connettersi, è sufficiente configurare il server per accettare tutti i certificati firmati da una CA specifica, che è interna e che controlli, con alcuni specifici vincolo. Quindi puoi semplicemente rilasciare ai tuoi utenti alcuni certificati con i vincoli specifici di cui hanno bisogno per connettersi ai server di cui hanno bisogno per connettersi.

Netflix ha un meccanismo elaborato come quello di cui hanno parlato. I loro sviluppatori hanno un modo per richiedere automaticamente nuovi certificati, di durata molto breve (nell'ordine dei minuti, quando la connessione SSH è aperta, non importa se il certificato scade durante questo, rimane aperta), in modo che possano connettersi a qualsiasi host.

Guarda questa loro presentazione, che potrebbe darti qualche idea sul perché i certificati possano essere utili: link o il video corrispondente: link

Hanno anche "aperto" il software di cui hanno bisogno per questa architettura: link