SSH: autenticazione a due fattori

30

Al momento ho un Ubuntu Server 12.04 con OpenSSH insieme a Samba e alcuni altri servizi. Al momento ho impostato l'autenticazione con chiave pubblica e mi chiedo se è possibile impostare l'autenticazione a due fattori? Ho esaminato Google Authenticator che attualmente utilizzo con il mio account Gmail.

Ho trovato un modulo PAM che sembra compatibile ma sembra che tu sia costretto a usare una password e il codice generato.

Mi chiedo se esiste un modo per utilizzare l'applicazione Google Authenticator (o qualcosa di simile) insieme alla mia chiave pubblica per l'autenticazione nel mio server SSH?

— Asino di cemento
fonte

La maggior parte dei commenti sembrano essere segnalazioni di bug che menzionano l'impossibilità di utilizzare l'autenticazione PAM e la chiave pubblica con OpenSSH. Ho anche trovato parti che menzionano la ridondanza mentre sto usando una passphrase con la mia chiave. Con tutte le soluzioni che sembrano consentire solo Google Authenticator e una password non una chiave pubblica. Potrei mancarmelo completamente, ma non vedo come implementarli entrambi.

— Concrete Donkey,

Non sono sicuro del motivo per cui questo ha un -1, questa è una domanda molto interessante e anch'io vorrei sapere la risposta (non che probabilmente lo userò, ma anche così, buono da mettere nelle banche della conoscenza)

— Mark Henderson

@Pierre Stai cercando di richiedere sia l'autenticazione con chiave pubblica sia un Google OTP?

— mgorven

@mgorven Sì, stavo cercando di impostare sia la chiave pubblica che Google OTP. Ho sentito alcune persone dire che è sufficiente avere una passphrase sui conteggi delle chiavi come due fattori, ma sono preoccupato per il malware che ruba la chiave non crittografata dalla memoria. Preferirei utilizzare due dispositivi completamente separati per l'autenticazione, sono leggermente paranoico.

— Concrete Donkey,

Questo è destinato a diventare ufficialmente implementato in 6.2: bugzilla.mindrot.org/show_bug.cgi?id=983#c59

— Tobias Kienzler

8

Red Hat ha aggiunto una patch a OpenSSH in RHEL (e quindi CentOS) 6.3 per richiedere più meccanismi di autenticazione, quindi puoi fare qualcosa del genere:

RequiredAuthentications2 publickey,keyboard-interactive

Vedi le note di rilascio per ulteriori dettagli.

Sfortunatamente questa funzione non sembra essere in OpenSSH upstream né Ubuntu 12.04, quindi a meno che tu non voglia trovare la patch e ricompilare OpenSSH, temo che tu sia sfortunato.

— mgorven
fonte

Devo dire che apprezzo lo sforzo che hai fatto per trovarmi una risposta, ho sicuramente provato ad esaminare alcune pagine dei risultati di Google, ma tutti hanno implicato ciò che hai detto che dovevo usare solo una password e un OTP. Probabilmente creerò una VM CentOS per giocare con la funzione.

— Concrete Donkey,

@Pierre Non che molto sforzo, sapevo di questa funzione prima ;-)

— mgorven

Ho trovato il bug corrispondente e alcune note aggiuntive . Il bug include la patch come allegato.

— Robie Basak,

Ed ecco un bug openssh upstream . Sembra che funzionalità simili saranno presto a monte in openssh.

— Robie Basak, il

openssh 6.2 è arrivato nella versione di sviluppo di Ubuntu, quindi salvo eventuali disastri questo supporto sarà nella versione 13.10 prevista. Utilizza upstream AuthenticationMethodsper specificare più metodi richiesti, in modo da poter richiedere sia una chiave ssh che PAM, con PAM che fa la fine di Google Authenticator.

— Robie Basak,

8

Stai cercando Duo Security

— Ajith
fonte

1

Questo. Sì. Adoro questa cosa!

— LVLAaron,

Sicuramente - Duo è facile da configurare per Unix / Linux (link in answer), OpenVPN ( duosecurity.com/docs/openvpn_as ) o qualsiasi servizio a due fattori basato su OATH TOTP o gestione della password LastPass. Qualsiasi servizio compatibile con Google Authenticator (che utilizza TOTP) può essere utilizzato con l'app mobile di Duo o un token hardware che supporta TOTP.

— RichVel,

5

Puoi utilizzare sia il modulo PAM di Google Authenticator che le chiavi pubbliche, ma solo una alla volta verrà utilizzata per una determinata autenticazione. Cioè, se un utente accede con una chiave pubblica autorizzata, non sarà richiesto alcun token.

Oppure, per dirlo diversamente: i token sono richiesti solo per l'autenticazione della password, non per le chiavi SSH.

Questa limitazione non viene dal modulo Google Authenticator, ma da SSH, che implementa l'autenticazione a due fattori (via ChallengeResponseAuthentication) per PAM, ma non chiama PAM quando viene fornita una chiave pubblica valida.

— ℝaphink
fonte

Questo era corretto, ma ora è cambiato. openssh 6.2 aggiunge un AuthenticationMethodsparametro di configurazione che può capovolgerlo. Ora puoi richiedere entrambi.

— Robie Basak,

3

Questa domanda è del 2012. Da allora, SSH è cambiato e il protocollo SSH2 è stato implementato.

Nelle versioni più recenti di SSH (> = 6.2), man sshd_config menziona:

AuthenticationMethods
       Specifies the authentication methods that must be successfully completed for a user to be
       granted access.  This option must be followed by one or more comma-separated lists of
       authentication method names.  Successful authentication requires completion of every method
       in at least one of these lists.

       For example, an argument of ``publickey,password publickey,keyboard-interactive'' would
       require the user to complete public key authentication, followed by either password or key-
       board interactive authentication.  Only methods that are next in one or more lists are
       offered at each stage, so for this example, it would not be possible to attempt password or
       keyboard-interactive authentication before public key.

       This option is only available for SSH protocol 2 and will yield a fatal error if enabled if
       protocol 1 is also enabled.  Note that each authentication method listed should also be
       explicitly enabled in the configuration.  The default is not to require multiple authentica-
       tion; successful completion of a single authentication method is sufficient.

Questa pagina http://lwn.net/Articles/544640/ menziona anche la possibilità di utilizzare contemporaneamente una chiave pubblica e un'autenticazione PAM.

— liquidità
fonte

2

So che questa domanda è un po 'stantia, ma per il bene delle persone future (me compreso) che stanno cercando una soluzione, si parla anche di usare l'opzione ForceCommand nel file sshd_config per eseguire uno script che quindi esegue l'autenticazione. C'è uno script di esempio qui è possibile modificare un po 'per le vostre esigenze, anche se in questo esempio lo chiama dal file authorized_keys invece di farla a livello di sistema con ForceCommand di sshd_config.

— Amazingant
fonte

1

Ottieni un YubiKey e segui questa guida http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, questo è il modo migliore per implementare Yubikey sul tuo server per l'accesso SSH. La guida sopra ti consente di usare public-key + yubikey mentre se vai con la guida ufficiale ( http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM ), non funziona con public- chiave.

Saluti, VIP

— vagarwal
fonte

0

Se imposti una passphrase sulla tua chiave privata, hai già l'autenticazione a due fattori. Per accedere le persone dovrebbero:

qualcosa che hai - la tua chiave privata
qualcosa che conosci: la passphrase per la tua chiave privata

— Bart B
fonte

3

Due password non effettuano l'autenticazione a due fattori. La chiave in sé non è un "qualcosa che hai" valido perché non è una cosa, ma solo un'informazione. La cosa deve essere non copiabile, o almeno non banalmente copiabile, per essere utilizzata come fattore di autenticazione.

— MadHatter supporta Monica il

2

Non sono completamente d'accordo. Se chiavi e certificati non sono "qualcosa che hai", quali sono? Non sono sicuramente "qualcosa che conosci" (hai l'abitudine di imparare dalla tua chiave SSH?), E assolutamente non "qualcosa che sei". Queste sono le uniche tre scelte, quindi con un processo di eliminazione, sono sicuramente "qualcosa che hai".

— Bart B,

1

Sono d'accordo; per me, il problema è nella massima (qualcosa che hai | sai | sono). L'idea di autenticazione a due fattori è di richiedere membri di due classi con proprietà diverse; qualcosa che sai è facile da trasportare, ma può essere conosciuto da qualcun altro nello stesso momento in cui lo conosci; quindi aggiungiamo un secondo fattore diverso. Il "qualcosa che hai" è diverso solo se non è visitabile (o difficile da copiare). Altrimenti, certo, non è qualcosa che conosci, ma non è qualitativamente diverso da qualcosa che conosci , perché qualcun altro può averlo contemporaneamente a te.

— MadHatter supporta Monica il

2

Sono assolutamente d'accordo sul fatto che una coppia di chiavi protetta da password è un grande miglioramento della sicurezza rispetto al semplice nome utente + password. Purtroppo, non sono d'accordo sul fatto che una coppia del genere contenga come due fattori, e probabilmente dovremo essere d'accordo su questo.

— MadHatter supporta Monica il

3

Se si dispone di una chiave privata crittografata con passphrase, si dimostra solo una cosa al server: che il client conosce la chiave privata. Non dimostra al server che conosci la tua passphrase; il server non è nemmeno a conoscenza dell'esistenza della tua passphrase. Pertanto è solo "qualcosa che conosci" (poiché il tuo cliente lo sa) e solo un fattore. Se un attaccante viene a conoscenza di una sola cosa (la tua chiave privata), allora sei compromesso. Questo è un fattore. Sostenere che la tua passphrase e chiave privata contano come due fattori è solo un esercizio di sofferenza. Ciò che conta è ciò che accade sul filo.

— Robie Basak il