Quale sicurezza SSH è più strong? 2 Fattore o chiave pubblica

23

Per l'autenticazione SSH, che è più sicura?
2 Autenticazione fattoriale utilizzando un token USB / Google Authenticator (basato sul tempo)
OR
Chiave pubblica / privata con password

Oppure potrebbero essere entrambi utilizzati contemporaneamente? Se è possibile, ci sono dei lati negativi nell'utilizzo di un'autenticazione a più fattori come questa?

Inoltre, chiunque potrebbe pubblicare un esempio o un link per mostrare come potrei implementare sia la chiave pubblica che il fattore 2 insieme se è possibile. Grazie!

    
posta Lelouch Lamperouge 19.12.2012 - 04:32
fonte

3 risposte

25

Questo non è un problema "uno è meglio dell'altro". Entrambi aumentano l'onere di un utente malintenzionato di penetrare nel tuo sistema:

  • L'uso dei tasti (e l'applicazione forzata) aumenta la "qualità della password" ("mypassword123" vs "long_binary_asymetric_keypair_here"). Gli umani sono molto cattivi nel ricordare lunghe passphrase con una buona entropia.

  • L'utilizzo dell'autenticazione 2Factor garantisce che un utente malintenzionato debba controllare 2 proprietà: un meccanismo di password (password usuale, PK) e un altro che (di solito) non si trova nella stessa posizione fisica del primo . Con la modalità 2Factor il sistema che stai cercando di autenticare ti sfiderà una seconda volta dopo aver superato la prima sfida. Ma se entrambe le sfide sono sciocche / semplici / facili da interrompere l'intera cosa di 2Factor è inutile.

Quindi, entrambi i meccanismi si completano a vicenda.

Buon tutorial sulla parte 2Factor:

link

Combina questo con qualsiasi altro tutorial che spiega come utilizzare i tasti ssh (e ci sono molti negli interni). Il flusso dell'autenticazione è quindi il seguente:

  1. Meccanismo di attivazione del client per sbloccare la chiave ssh privata (password) sulla sua macchina
  2. Il client contatta il server per garantire la corrispondenza della chiave pubblica e privata. Da qui in poi il ssh-server non è più coinvolto nell'autenticazione.
  3. Il server indirizza il Cliente alla seconda sfida
  4. Il client risponde correttamente alla seconda sfida
  5. Il client ottiene l'accesso alla shell sul server
risposta data 19.12.2012 - 07:40
fonte
5

Oltre all'altra risposta, posso anche aggiungere che l'autenticazione basata su pubkey può essere a 2 fattori di per sé se la tua chiave privata è su una smartcard (ad esempio la scheda OpenPGP). Nella mia esperienza, l'aggiunta di google-authenticator a livello ssh rende la vita di amministrazione troppo ingombrante: devi inserire il codice ogni volta che devi scappare le cose. Il mio approccio preferito è ssh key su OpenPGP card e google-authenticator quando si fa sudo.

Questi due link ti saranno utili:

  1. Configurazione della scheda OpenPGP per gestire l'autenticazione ssh .
  2. Configurazione dell'infrastruttura di autenticatore google centralizzata .
risposta data 19.12.2012 - 16:00
fonte
-1

Il compromesso tra quanto è problematico mantenere l'autenticazione a due fattori o chiave pubblica e il livello di sicurezza che ciascuno fornisce dipende da come / da chi lo sta usando. Se l'utilizzo è limitato a un numero limitato di gestori di sistema del server che hanno familiarità con la sicurezza, in modo che non inquinino i processi consentendo l'accesso al loro accesso (PC, laptop, dispositivo mobile) per essere compromessi, allora uno di questi potrebbe risultare sicuro.

I vari report, articoli e blog che ho letto indicano che il mezzo più frequente per sconfiggere l'autenticazione a due fattori o la crittografia a chiave pubblica sta guadagnando l'accesso ad un accesso non sicuro al client - un PC lasciato acceso o senza protezione password usata per ottenere l'accesso root (o altre aree). Le password possono essere memorizzate sul dispositivo in un gestore di password o automaticamente inserite da un browser Web o annotate su carta in una scrivania.

Un altro mezzo di compromesso è quando le password e le chiavi non vengono cambiate dopo che un dipendente / associato lascia.

La maggior parte della forza bruta, gli attacchi di forza bruta distribuiti e altri attacchi esterni vengono efficacemente ostacolati dai metodi di autenticazione a due fattori o a chiave pubblica. Ciò viene migliorato se si utilizzano password ragionevolmente difficili e si richiede l'accesso con chiave pubblica crittografata con password (una forma di autenticazione a due fattori stessa).

È possibile utilizzare altri metodi, come l'uso di una porta SSH non standard, anche se esiste un argomento valido contro tale metodo. Un altro metodo è l'uso di porte non standard rotanti / casuali o l'uso di Port-knocking in cui tre o più porte devono essere colpite / bussate in sequenza prima che venga concesso l'accesso a un SSH o ad altre porte selezionate. Anche le porte knock-knock possono essere ruotate periodicamente.

Questi ultimi metodi di solito non sono giustificati perché è molto più probabile che si verifichino violazioni della sicurezza all'interno di un'organizzazione che ha implementato metodi di autenticazione a due fattori e / o chiave pubblica. Se la natura del lavoro / dei server richiede i più alti livelli di sicurezza, gli ulteriori livelli di sicurezza potrebbero avere senso.

Ho rivisto il film "The Imitation Game" 2014 ieri sera. Si tratta del cracking della macchina di crittografia nazista Enigma che ha richiesto di determinare tra alcune centinaia di milioni di possibili selezioni manuali. Il codice è stato rotto dalla macchina elettromeccanica di calcolo di Brit Alen Turing solo dopo aver trovato termini ripetuti nelle comunicazioni che potevano essere indovinati "Heil Hitler!" e altri termini nelle relazioni meteorologiche giornaliere. Questo è un modo molto lungo per descrivere la sicurezza dei server Linux e di altri sistemi protetti: sono altrettanto sicuri quanto le pratiche delle persone che li usano.

    
risposta data 07.09.2017 - 20:45
fonte

Leggi altre domande sui tag