Sembra che si escludano a vicenda, dato che disabilitare uno mi dà l'altro e viceversa. L'autenticazione a due fattori per i miei server ssh sembra davvero bella, quindi c'è un modo per farlo?
Sembra che si escludano a vicenda, dato che disabilitare uno mi dà l'altro e viceversa. L'autenticazione a due fattori per i miei server ssh sembra davvero bella, quindi c'è un modo per farlo?
Con le recenti versioni di Fedora e RHEL 6, puoi utilizzare RequiredAuthentications2 pubkey,password per richiedere l'autenticazione della password e di pubkey. Di solito questo è necessario per richiedere token di autenticazione a 2 fattori e pubkey, non la password dell'utente.
Aggiornamento: ora su RHEL / CentOS 7, e su qualsiasi sistema con una versione recente di OpenSSH, puoi usare:
AuthenticationMethods "publickey,password" "publickey,keyboard-interactive"
È anche possibile utilizzare la direttiva Abbina per escludere IP o Utenti.
È possibile avere l'autenticazione della chiave pubblica e della password sullo stesso server. Se l'autenticazione della chiave pubblica non riesce, verrà eseguita l'autenticazione della password.
Come richiedere entrambi, sembra sciocco e controproducente, e controllando man sshd_config non c'è un'opzione per farlo.
La tua chiave privata ssh dovrebbe avere una passphrase sicura. Quindi, se un utente malintenzionato ottiene la tua chiave privata, non può ancora fare nulla senza prima ottenere la passphrase. Se hanno compromesso la passphrase (molto probabilmente con un keylogger, o da una forzatura brutale di una passphrase estremamente debole) possono banalmente anche afferrare / forzare con forza qualsiasi password memorizzata.
Se vuoi davvero, puoi configurare qualcosa con say ForceCommand (ad esempio, solo consentire l'autenticazione a chiave pubblica e quindi indirizzare l'utente a una shell che richiede una password). Non lo consiglio.
Un'alternativa migliore se vuoi limitare l'esposizione, è avere una configurazione del firewall per limitare gli IP che possono raggiungere la porta ssh; possibilmente con una VPN aggiuntiva in esecuzione su un server da qualche parte se potrebbe essere necessario eseguire il tunnel da un altro computer ad un certo punto. Puoi anche usare qualcosa come knockd per aprire un buco in un firewall dopo un particolare pattern di knock-out, sebbene riconosca che chiunque intercettazioni sul traffico potrebbero riprodurre lo schema di battito per aprire una porta.
(cross posting SO answer con una soluzione aggiornata a questi giorni)
Se leggi la pagina di manuale per sshd_config(5) , c'è l'opzione AuthenticationMethods , che prende l'elenco dei metodi che devi passare prima che ti venga concesso l'accesso. La configurazione richiesta è:
AuthenticationMethods publickey,password
Questo metodo dovrebbe funzionare con tutti i sistemi Linux correnti con recenti openssh (openssh-6, openssh-7).
L'unica eccezione che conosco è RHEL 6 (openssh-5.3), che richiede l'impostazione di un'opzione diversa con gli stessi valori (come descritto nell'altra risposta):
RequiredAuthentications2 publickey,password
Ho esaminato questo aspetto un po 'di più e ho trovato il seguente.
Potresti usare PAM per l'autenticazione a due fattori, ma in questo modo non utilizzerai le chiavi SSH perché utilizzerai due fattori diversi.
Ad esempio, puoi utilizzare google con l'autenticazione a due fattori e utilizzare pam per l'autenticazione, come descritto in
L'unica soluzione che ha funzionato per me è avere quanto segue in / etc / ssh / sshd_config (testato con CentOS7):
PubkeyAuthentication yes
AuthenticationMethods publickey password
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
Che significa avere PAM abilitato, abilitare tutte le linee che riguardano la chiave publik e, infine, disporre di AuthenticationMethods che elenca correttamente entrambi i metodi. Tieni presente che, nonostante ciò che era scritto da Jakuje , non devi aggiungere una virgola tra publickey e password dopo AuthenticationMethods.