In che modo la crescente lunghezza della chiave dell'host SSH aumenta la sicurezza

Question

In che modo la crescente lunghezza della chiave dell'host SSH aumenta la sicurezza

#1 da (10 voti)
#2 da (3 voti)
#3 da (0 voti)

8

Ho letto su alcune guide su "come proteggere i server SSH" che è una buona cosa aumentare ServerKeyBits dal valore predefinito di 768 a 2048.

La maggior parte di queste guide sembra essere per l'amministratore del server entry level / novice (che io sono) per proteggersi rapidamente dai tentativi di login ssh di scripting brute force root e cose del genere, e sto cercando di capire il punto di ogni misura di sicurezza.

Ho letto su come funziona l'autenticazione a chiave pubblica, in particolare per SSH v2. Non ho mai visto nulla sulla chiave host del server SSH utilizzata nel processo di autenticazione del client, per cui intendo dimostrare che il client è affidabile.

Sembra essere usato solo per assicurare che l'host a cui un client si connette sia lo stesso a cui è connesso in passato - che non sia un impostore.

Mi sto chiedendo, praticamente parlando, perché è un grosso problema aumentare la chiave dell'host fino al 2048. Rende più difficile per un utente malintenzionato forzare in qualche modo la chiave dell'host privato? Anche se un utente malintenzionato fosse in grado di capire la chiave dell'host privato, in modo che un client / o l'amministratore fosse in grado di accedere all'host falso, quale sarebbe il vantaggio per l'aggressore?

Anche incluso in queste guide è l'impostazione

PasswordAuthentication no

quindi l'utente non dovrebbe nemmeno aspettarsi di inserire una password comunque. Se fossero così inconsapevoli di cose da inserire una password quando di solito non devono farlo, non accetteranno solo ciecamente una diversa chiave host? Quindi se l'hacker aveva la password, allora cosa? L'autenticazione della password è comunque disabilitata sul server, quindi non sarebbero ancora in grado di accedere. Da quello che ho letto, l'utente malintenzionato non sarebbe stato in grado di ottenere alcuna informazione utile dal client nel processo di autenticazione anche se il client si fida della identità dei server.

Mi sento come se mi mancasse qualcosa di importante su come funziona l'autenticazione SSH a chiave pubblica, perché non capisco perché avere una chiave host lunga sembra così importante. Rende più difficile in qualche modo compromettere le credenziali dei clienti? Cosa potrebbe realmente accadere se la chiave dell'host privato è compromessa?

Grazie

authentication ssh public-key-infrastructure ssh-host-key

posta user2726974 09.11.2013 - 04:09

fonte

3 risposte

Leggi altre domande sui tag authentication ssh public-key-infrastructure ssh-host-key

In che modo l'utente riceve il certificato del server? È un token di sessione sufficiente per le applicazioni critiche

score 10 · Answer 1

C'è una parte cruciale di confusione nella tua domanda, che le risposte qui non hanno evidenziato: ServerKeyBits non ha nulla a che fare con la chiave host. Di fatto, oggi è per lo più irrilevante, poiché si applica solo alla versione 1 del protocollo SSH, che è obsoleto da molti anni e non dovrebbe più essere utilizzato.

Se hai familiarità con la configurazione di un server OpenSSH, dovrebbe anche essere chiaro dal punto di vista operativo che un'impostazione di configurazione sshd non può di per sé aumentare la dimensione della chiave host, che si trova in un file su disco (ad esempio / etc / ssh /ssh_host_rsa_key{.pub}) e viene generato una volta e separatamente.

La "chiave server" nel protocollo 1 è una seconda chiave RSA, distinta dalla chiave host, utilizzata per ottenere la segretezza in avanti. È effimero, generato dal server all'avvio, sostituito periodicamente (una volta all'ora per impostazione predefinita) e mai scritto sul disco. Il client crittografa la chiave di sessione simmetrica con la chiave del server e la invia al server; questo messaggio è autenticato sottoscrivendolo con l'hostkey. Nel protocollo 2, invece, la riservatezza diretta è implementata con Diffie-Hellman.

Quindi, una chiave server sufficientemente strong è importante perché se un utente malintenzionato può recuperarla, può leggere sessioni SSH registrate o manomettere quelle correnti (poiché ha la crittografia della sessione e le chiavi MAC). E come una risposta precedente ha sottolineato, 768 bit per una chiave RSA sono troppo brevi per gli standard odierni.

score 3 · Answer 2

Risposta breve: la chiave dell'host è la chiave pubblica del server e questa chiave viene utilizzata per stabilire il segreto condiviso (chiave di crittografia simmetrica) e quindi è importante che sia sufficientemente strong da sopportare contro l'attacco a forza bruta.

In dettaglio: In primo luogo è necessario capire come funziona la crittografia asimmetrica o la crittografia a chiave pubblica-privata. Ogni sistema ha una coppia di chiavi composta da chiave privata e pubblica. Come suggerisce il nome, la chiave pubblica deve essere resa pubblica o, in altre parole, può essere distribuita al mondo senza implicazioni di sicurezza, mentre la chiave privata deve essere tenuta segreta e solo il sistema può utilizzarla. Il concetto matematico sottostante con questa configurazione è, se un messaggio è crittografato con una chiave pubblica, quindi può essere decifrato solo con la chiave privata corrispondente e viceversa.

Questa crittografia asimmetrica viene utilizzata in caso di SSH per stabilire una sessione protetta, che utilizza la crittografia simmetrica. La chiave per questa crittografia simmetrica ( K_sys ) viene scambiata utilizzando la crittografia della chiave pubblica-privata. Inoltre tutta la comunicazione tra client-server è crittografata usando questo K_sys.

Poiché tutta la segretezza della comunicazione dipende dalla segretezza di K_sys , è della massima importanza che la crittografia a chiave pubblica-privata sia sicura, poiché viene utilizzata per condividere la chiave segreta. E per garantire una segretezza sufficiente, la forza chiave è uno dei parametri importanti da considerare. Avendo

Informazioni aggiuntive: La chiave RSA a 768 bit era bruteforce con successo nel 2010 e si prevedeva che con gli avanzamenti computazionali a 1024 bit diventerebbero deboli nelle prossime decennio. Quindi, è consigliabile aumentare la forza chiave fino al 2048 nel prossimo futuro.

score 0 · Answer 3

Also included in these guides is setting
PasswordAuthentication no
so the user shouldn't even be expecting to enter a password anyway. If they were so unaware of things to enter a password when they usually don't have to, wouldn't they just blindly accept a different host key anyway? Then if the attacker had the password, then what? Password authentication is disabled on the server anyway, so they still wouldn't be able to log in.

Questo è precisamente il punto in cui si disabilita l'autenticazione della password, quindi un utente malintenzionato non può accedere se ha una password utente. In particolare, stai cercando di evitare di consentire l'accesso al tuo computer tramite account utente con password non sicure, ad es. account di prova.