È davvero sicuro connettersi a un server tramite SSH dagli hotel durante un viaggio?

È davvero sicuro connettersi a un server utilizzando SSH dagli hotel durante un viaggio?

Server :
- CentOS 7
- Autorizzazione solo tramite chiave RSA - Autenticazione password negata
- Porta non standard

Workstation :
- Ubuntu 14
- password utente
- password per utilizzare la chiave RSA (metodo standard)

Forse sarà una buona idea conservare metà della chiave RSA privata su una chiavetta USB e aggiungere automaticamente (tramite script) questa metà a ~ / .ssh / private_key prima di connettersi?

Internet avverrà tramite WIFI negli hotel o via cavo in un appartamento in affitto.

UPD
Mi dispiace per non essere chiaro all'inizio. Intendo sicurezza in due aspetti qui:

Sicurezza della sola connessione SSH attraverso una rete non attendibile.
Sicurezza di un computer con la chiave necessaria per la connessione SSH: se viene rubato, come proteggere il server ...

security physical-security

— Sergey Serov
fonte

Quale mezza chiave RSA? La parte pubblica della chiave host ssh? La metà della parte privata della chiave ssh dell'utente?

— andol,

metà della mia chiave RSA privata ovviamente :) e automaticamente tramite script per aggiungere questa metà a ~ / .ssh / private_key prima di connettersi al server.

— Sergey Serov,

Sei già più sicuro della maggior parte della gente perché stai usando Linux. Dal momento che stai eseguendo versioni recenti, dovresti avere nuove versioni di OpenSSH che supportano una crittografia più forte. Dopo aver seguito tecmint.com/5-best-practices-to-secure-and-protect-ssh-server potresti giocare limitandoti a criptovalute

— pulcini,

@chicks "più sicuro della maggior parte della gente perché stai usando Linux" è una cosa sciocca da dire. SSH è SSH, indipendentemente dal fatto che sia in esecuzione su Linux, Unix (il Mac) o Windows. E potremmo indicare un sacco di difetti di sicurezza estremamente gravi in Linux nella storia recente (Heartbleed, chiunque?). Solo dicendo, lasciamo le sciocche guerre di fiamma del sistema operativo a margine a cui appartengono perché distrae dalle domande e dai problemi reali. Grazie! ;-)

— Craig,

@chicks Immagino sia quello che stavo cercando di trasmettere. Molti problemi di sicurezza in tutti i sistemi operativi e Microsoft ha fatto enormi passi avanti da quando ha iniziato la sua iniziativa di "informatica affidabile * diversi anni fa. Penso solo che la cosa" sei più sicura perché Linux "distolga la conversazione dal problema attuale ( rispettosamente) ;-)

— Craig

Risposte:

Quindi, per quanto riguarda la creazione di una connessione SSH su una connessione esplicitamente non attendibile.

Supponendo che tu abbia già una voce ~ / .ssh / known_hosts da una connessione precedente, sì, dovresti essere in grado di connetterti senza preoccuparti di ciò che la rete è sicura o meno. Lo stesso vale se si dispone di altri mezzi per verificare la chiave host ssh.

Se non ti sei mai connesso al server prima, né hai avuto nessun altro modo di verificare la chiave host ssh, allora potresti voler essere più attento riguardo alla rete che usi per connetterti.

— Andol
fonte

Grazie!! Quindi è sicuro connettersi al server tramite SSH anche tramite qualsiasi rete Wi-Fi pubblica?

— Sergey Serov,

In realtà, questa risposta si applica a qualsiasi situazione in cui si desidera inviare a un server remoto SSH e qualsiasi parte del percorso non è sotto il vostro pieno controllo (quindi praticamente qualsiasi cosa oltre a quella di un host locale appena installato o tramite un cavo cross-link )

— Hagen von Eitzen,

Vale la pena notare che se il client non conosce la chiave host, sarà possibile un attacco MITM completo se si utilizza l'autenticazione con password. Ma se viene utilizzata l'autenticazione basata su chiave, l'attaccante sarà solo in grado di impersonare il server. L'attaccante non sarà in grado di autenticarsi anche sul server reale. È difficile per un utente malintenzionato fornire una rappresentazione convincente del server in quel caso, quindi potresti essere in grado di notare che qualcosa non va prima che sia troppo tardi. In breve: l'autenticazione con chiave pubblica è molto più sicura dell'autenticazione con password .

— Kasperd,

@kasperd: Bene, se il client di connessione ha abilitato l'inoltro dell'agente, anche l'autenticazione con chiave pubblica può fornire l'esperienza MITM completa. Sì, l'autenticazione con chiave pubblica è sicuramente preferibile alle password normali, in qualsiasi giorno.

— andol,

@kasperd: Beh, posso facilmente immaginare qualcuno che sta solo scoprendo l'inoltro dell'agente, ma non capendolo completamente, mettendo qualcosa come "Host * \ n \ tForwardAgent yes" nella sua ~ / .ssh / config. Le persone fanno tutti i tipi di cose folli :-)

— andol,

Nella seconda parte della domanda sembra che tu sia preoccupato per il furto del tuo notebook e, con esso, le tue chiavi private per l'accesso SSH senza password ai tuoi server.

Si noti che questo può essere facilmente risolto (problema delle chiavi private) memorizzando le chiavi private "crittografate" con una "passphrase": possono essere inizialmente crittografate, mentre si generano con l' utilità ssh-keygen , fornendo una passphrase alla fine di il processo di generazione o, se non li hai già programmati, usando l' utility ssh-keygen con -popzione. Una volta crittografata la chiave, ad ogni accesso ti viene chiesto di inserire la relativa passphrase e .... se corretta, tutto procederà normalmente.

Inoltre, se non si desidera inserire la passphrase ogni volta che si avvia il client ssh, è possibile utilizzare ssh-agent : può tenere traccia, in memoria, di chiavi private non crittografate. È possibile semplicemente eseguire ssh-add puntando al file contenente la chiave crittografata e, dopo aver richiesto la passphrase, la chiave viene aggiunta al set gestito dall'agente ssh. Successivamente, ogni volta che il client SSH richiede una chiave protetta da passphrase, l'agente ssh fornisce in modo trasparente la relativa chiave privata non crittografata al client ssh. Quindi, per te, non è necessario inserirlo in modo interattivo.

Si noti che ssh-agent può gestire molte chiavi e ovviamente è possibile "ottimizzare" il proprio notebook / desktop per avviare l' ssh-addutilità (per popolare il set di chiavi ssh-agent) al momento del login / avvio.

Inoltre, se qualcuno dovesse rubare il tuo laptop, le tue chiavi private non sono probabilmente l'unico contenuto "sensibile" che distribuirai: tieni presente che con le odierne distribuzioni desktop Linux è MOLTO facile impostare un notebook basato su "crittografato" "file system (l' /homeantipasto, ma l'intero /se necessario). Quindi, per favore, considera anche questo.

Tutto quanto sopra, ovviamente, NON si applica se NON fai affidamento sul TUO TUO notebook.

PS: per quanto riguarda la tua possibilità di memorizzare le due metà della chiave privata non crittografata su supporti diversi: ti consiglio vivamente di non farlo, poiché mantenere le due parti di contenuto sensibile in una forma non crittografata è molto, molto peggio, che tenere due copie complete di tutto il contenuto, crittografate!

— Damiano Verzulli
fonte

La prima parte della tua domanda ha già ricevuto risposta dalla risposta precedente. Come per la tua seconda parte, consiglierei di aggiungere un secondo fattore al tuo login ssh usando pam_google_authenticator. È abbastanza facile da installare e configurare su qualsiasi distribuzione. Nel caso in cui la chiave privata che stai portando in giro venga rubata, non possono accedere al tuo server senza la password TOTP di una volta da Google Authenticator.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— Arul Selvan
fonte