SSH Autenticazione chiave pubblica vs nome utente / password per l'accesso API

Ci sono molte differenze.

In primo luogo, impostando il tuo server API per accettare nome utente / password (al contrario di consentire solo l'accesso tramite chiavi, che è sempre una best practice da fare) puoi potenzialmente ridurre la sua sicurezza in generale, come, ora, gli utenti con debolezza le password sul sistema (o, peggio, i servizi che si installano che possono avere password predefinite con hardcoded) renderanno possibile la violazione del server. Gli attacchi di forza bruta sono improvvisamente un'opzione per coloro che vogliono entrare nel sistema (il che, se si esegue un server SSH su un IP pubblico, si è garantiti per vedere quasi immediatamente). Disabilitare il login ssh tramite password e richiedere chiavi di accesso è semplice come impostare "PasswordAuthentication no" nel proprio sshd_config e riavviare il servizio sshd (o il proprio server). Lo faccio su ogni box Linux che costruisco come uno dei primi passi. Inoltre, ciò incoraggia l'impostazione di una password molto lunga e casuale, dal momento che (se si imposta / etc / sudeoer correttamente) non la userai mai per niente. :)

In secondo luogo, con l'opzione ssh key, puoi facilmente impostare il file authorized_keys in modo tale che:

1. Consenti solo l'accesso da un IP specifico; e
2. Consenti solo all'utente / script di accesso di eseguire un determinato comando.

In questo modo, anche se qualcuno compromette la tua casella cliente, la chiave rubata non può essere utilizzata per accedere al tuo server da qualsiasi altra parte del mondo, e , se lo hai impostato correttamente, non può nemmeno essere usato per accedere dal tuo client per qualcosa di diverso da quello che hai permesso. Ad esempio, lo uso per impostare account / chiavi che non possono fare nulla tranne rsync con determinate opzioni da una determinata cartella. Quindi, anche se la chiave venisse rubata, l'attaccante non guadagnerebbe altro che essere in grado di eseguire il comando che la macchina client si sta eseguendo comunque, e solo dall'IP del client, da nessun'altra parte. Ad esempio, l'ottenimento della chiave non ha consentito all'utente malintenzionato di compromettere il server API. Potresti essere in grado di limitare un account basato su password per eseguire solo un determinato comando o solo il login da un determinato IP, ma non l'ho mai visto e non so quanto sia facile.

In terzo luogo, quando si desidera concedere l'accesso al proprio server API a un'altra persona / sistema in futuro e si desidera utilizzare le password, si incorre nel problema di distribuzione delle chiavi (in modo abbastanza ironico). Vale a dire, devi avere un canale sicuro per scambiare la password iniziale dell'account in modo che l'utente possa accedere. Con le chiavi SSH, tutto ciò che devono fare è inviarti via email la loro chiave pubblica (che non è qualcosa che ha bisogno di sicurezza), e ( se ti fidi che l'email provenga da loro, quali sono i modi per assicurarti), e puoi dare loro l'accesso.

Quindi spero che questo ti abbia convinto che c'è un valore nell'usare le chiavi (e, in realtà, non dovresti usare l'accesso solo per password su nulla, le chiavi o 2FA per i servizi pubblici sono l'unica strada da percorrere :-) ). Saluti.

Why is the SSH authorization considered better? I mean if somebody gets access to my linux machine, then they can read both username/password OR the SSH key and they can then copy these information to their own laptop.

Sì, è vero, se qualcuno ottiene l'accesso completo alla tua macchina, sei nei guai in ogni caso.

Am I missing something here?

Sì. Tutte le situazioni in cui un utente malintenzionato non ha già ottenuto l'accesso completo al computer. Ci sono attacchi facilmente implementabili che sono possibili con l'autenticazione username / password che non è possibile con le chiavi SSH.

Bene, se si rinuncia all'idea di nome utente / password (che non è affatto sicuro per questo uso) è possibile implementare un ambiente chroot per il ssh-client a cui connettersi. utilizzando la crittografia a chiave pubblica ECDSA o RSA (si spedisce la chiave privata con l'app e si memorizzano le chiavi autorizzate al di fuori del chroot).

Specialmente se si crea una "casella personale" per i client in cui scrivere, o si crea un file speciale FIFO / LIFO con solo accesso in scrittura dall'ambiente chroot. puoi lasciare che il client scriva in sicurezza sul server senza alcun accesso in lettura di sorta.

Se si tratta solo di un file che si desidera caricare, utilizzare il client sFTP incorporato di ssh. Ciò significherebbe che puoi caricare un file direttamente, senza dare accesso alla shell in tutto l'ambiente chroot.

Se si attiva la connessione ssh attraverso uno script sul "client" non è necessario avere un file ssh.config. Puoi semplicemente specificare gli argomenti della riga di comando che desideri nello script.

Per quanto riguarda il motivo per cui una chiave è migliore, per quanto riguarda la sicurezza, dobbiamo solo vedere come il sistema SSH utilizza i tasti:

• SSH-client chiede il server SSH (quale versione e tipi di scambio / autenticazione chiave supportati)
• Il server SSH risponde con funzionalità e token di chiave pubblica.
• Il client SSH risponde con un "token di crittografia" codificato segreto (un'operazione del token di chiave pubblica con qualche magia di crittografia) che è firmato con la chiave privata.
• SSH-server autentica la firma (la chiave pubblica decrittografa il messaggio) e convalida il token di crittografia, quindi risponde al proprio token di crittografia basato, usando metodi simili come il client.
• SSh-client convalida il token di crittografia ricevuto.
• SSH-server imposta un tunnel sicuro usando le nuove chiavi. che avvia la shell.

• ssh-client imposta l'endpoint del tunnel sicuro e avvia il proxy shell.

  yay connessione ssh stabilita.

Ti suggerisco di leggere su SSH e le chiavi e il chroot per capire meglio cosa stai cercando di fare.