Potenziali sessioni SSH dirottate e best practice SSH

Sto andando fuori di testa al momento. Sto SSHing in un server remoto che ho recentemente commissionato. Lo sto facendo come root. Ho installato fail2ban e nel registro c'era una quantità enorme di IP vietati.

L'ultima volta che ho effettuato l'accesso ho notato che il mio terminale era davvero in ritardo, quindi la mia connessione a Internet si è interrotta. Quando l'ho riacquistato dopo circa 5 minuti sono tornato al server e ho fatto un 'chi' e ho realizzato che c'erano due utenti root connessi. Avrei pensato che se la mia connessione avesse terminato il processo dall'ultima sessione sarebbe stato fermato sul server?

La connessione si è conclusa con una 'Scrittura fallita: tubo rotto' quando mi sono disconnesso per la prima volta. Ho ucciso la sessione bash con l'altra radice. Non so molto sulla sicurezza di SSH, ma le sessioni potrebbero essere dirottate? c'è un modo per controllare questo? Devo continuare ad accedere tramite ssh quali precauzioni dovrei prendere? Se in qualche modo stavo attraversando un proxy per raggiungere il mio server (come un uomo nel mezzo dell'attacco) potrebbero dirottare la mia sessione SSH?

Gli accessi root probabilmente stanno facendo penzolare sessioni di shell che una volta eri tu. Probabilmente anche il tuo server sta ottenendo dDOS con tutti i tentativi di accesso che lo martellano.

Blocca SSH. Non consentire l'accesso come root, e quelle richieste che stanno tentando di forzare questa macchina falliranno immediatamente (prendendo molte meno risorse). Accedi come un utente normale ed eleva le autorizzazioni tramite sudo, una pratica che dovresti fare comunque. Limitare anche l'accesso SSH a un elenco di IP client in modo che i computer non salati non possano nemmeno provare ad accedere.

Utilizzare le chiavi SSH anziché le password per l'accesso dell'utente. Sono più facili da gestire e possono essere protetti da password autonomamente nel caso in cui accidentalmente si dia una chiave privata nel posto sbagliato (dandoti il ​​tempo di sostituirli e invalidare quello vecchio). Come @EEAA menzionato nei commenti, è necessario disabilitare anche l'autenticazione basata su password se si desidera limitare i client all'utilizzo solo delle chiavi anziché delle password e delle chiavi.

Se i clan mongoli continuano a battere le mura della tua città, magari sposta SSH in un altro porto alto (sotto il 1024, come sottolineato da @AustinBurke - in modo da utilizzare un porto privilegiato) invece di 22. Ciò ridurrà il traffico su quel porto se questo è un problema per te (e la maggior parte dei robot non è molto elegante, quindi tenteranno solo il 22). Non impedirà alle cose di provare la porta 22 o persino di scansionare il tuo computer per vedere quale porta è in ascolto su SSH, e nella maggior parte dei casi è un inconveniente inutile. Ma può essere d'aiuto.

Altri potrebbero essere in grado di fornire ulteriori suggerimenti, ma si tratta di misure di sicurezza piuttosto generiche per un server SSH pubblico.