Quanto è sicuro l'autenticazione basata su chiave ssh

When I logged on this morning I ran netstat -plant and found a couple of established connections on port 22 from China and France.

Per quanto tempo li hai visti?

Se si dispone di un server SSH su Internet, le persone lo esamineranno costantemente e tenteranno attacchi di dizionario di password comuni. Quindi i sistemi si connetteranno, provano più password e hanno dei ritardi forzati tra i tentativi poiché il sistema vuole limitare gli attacchi di forza bruta.

Tutto ciò significa che le connessioni TCP "sono state stabilite" per secondi o addirittura minuti. Non sono sessioni SSH autenticate, sono solo connessioni TCP.

Ecco, guarda:

$ netstat -tn | grep :22 | egrep -v "[my address]"
tcp        0   1080 192.168.1.2:22         123.183.209.136:25690   ESTABLISHED
tcp        0      1 192.168.1.2:22         123.183.209.136:40117   FIN_WAIT1

un paio di minuti dopo:

$ netstat -tn | grep :22
tcp        0   1080 192.168.1.2:22         123.183.209.136:48456   ESTABLISHED

Nella prima istantanea vediamo che c'è una sessione stabilita e una ancora viene abbattuta. Un paio di minuti dopo, c'è una nuova sessione (notare che la porta del client è cambiata in 48456). Quindi questa persona sta costantemente aprendo una connessione TCP, cercando di autenticare, e quando quella connessione viene interrotta per troppi tentativi, ne aprono un'altra.

I find it hard to believe that a 4096 bit rsa key can be cracked within the space of one evening.

Are there any exploits / vulnerabilities that can be used to circumvent key-based authentication with OpenSSH?

Is key-based auth the best option to allow access with SSH? What are the alternatives?

Non spaventarti ancora. Guarda le connessioni; a meno che non ne vedi uno per un periodo di tempo significativo, probabilmente non devi preoccuparti.

Puoi anche controllare last output per vedere se qualcuno sta effettuando l'accesso e correlare il loro indirizzo di origine (ad esempio, non preoccuparti per gli accessi dal login tu da):

$ last
gowenfawr pts/0        192.168.1.3      Thu Aug  3 18:55   still logged in
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:29 - 03:29  (00:00)
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:19 - 03:29  (00:09)
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:04 - 03:06  (00:02)
gowenfawr pts/1        192.168.1.3      Wed Aug  2 19:44 - 21:09  (01:25)

wtmp begins Wed Aug  2 19:44:26 2017

Sebbene, naturalmente, se qualcuno ha compromesso il tuo sistema, non puoi fidarti di last o netstat comunque.

Le chiavi RSA sono sufficientemente sicure per il futuro prevedibile e 4096 bit potrebbero anche essere eccessivo .

Se sei preoccupato, potresti provare a configurare qualcosa come fail2ban, ma se non autorizzi l'autenticazione tramite password e hai le chiavi RSA con > = 2048 bit stai bene.

Mi aspetto che se controlli i tuoi registri di autenticazione troverai molti errori di autenticazione da quegli indirizzi, ed è abbastanza normale. In questo momento il mio server ssh pubblico ha un log di autenticazione di 14 MB, con oltre 82.000 tentativi di accesso falliti per root:

sudo grep -i root /var/log/auth.log -c
82023

Fintanto che lo hai impostato correttamente, la chiave non è stata incrinata.

Se vengono visualizzati solo su netstat, probabilmente si trovano solo nel prompt di accesso SSH.

Assicurati di disabilitare le password di testo in chiaro nel tuo file /etc/ssh/sshd_config per evitare i normali accessi alle password. Assicurati di avere un altro modo per entrare nel tuo server se perdi le chiavi.

PermitRootLogin deve essere impostato su no . Non dovresti accedere come root, specialmente su SSH. Utilizza un altro account con accesso sudo.

L'autenticazione con chiave SSH è il modo migliore per autenticare un server SSH, in particolare un server SSH esposto a Internet. Esiste anche un software che implementa l'autenticazione a due fattori per gli accessi SSH utilizzando Google Authenticator. Questo è qualcosa che vale la pena esaminare.