Abbiamo esaltato più volte le virtù di SSH, sia per la sicurezza che per l'accesso remoto. Diamo un'occhiata al server stesso, ad alcuni importanti aspetti di "manutenzione" e ad alcune stranezze che possono aggiungere turbolenza a una corsa altrimenti fluida.
Sebbene abbiamo scritto questa guida pensando a Linux, questo può essere applicato anche a OpenSSH in Mac OS X e Windows 7 via Cygwin .
Perché è sicuro
Abbiamo menzionato molte volte come SSH sia un ottimo modo per connettersi in modo sicuro e eseguire il tunneling dei dati da un punto a un altro. Diamo uno sguardo molto breve a come funzionano le cose in modo da avere un'idea migliore del motivo per cui a volte le cose possono andare strane.
Quando decidiamo di avviare una connessione a un altro computer, spesso utilizziamo protocolli con cui è facile lavorare. Vengono in mente sia Telnet che FTP. Inviamo informazioni a un server remoto e quindi riceviamo la conferma della nostra connessione. Per stabilire un certo tipo di sicurezza, questi protocolli utilizzano spesso combinazioni di nome utente e password. Ciò significa che sono totalmente al sicuro, giusto? Sbagliato!
Se pensiamo al nostro processo di connessione come posta, usare FTP e Telnet e simili non è come usare buste postali standard. È più come usare le cartoline. Se qualcuno si trova nel mezzo, può vedere tutte le informazioni, inclusi gli indirizzi di entrambi i corrispondenti e il nome utente e la password inviati. Possono quindi modificare il messaggio, mantenendo le stesse informazioni e impersonare l'uno o l'altro corrispondente. Questo è noto come attacco "man-in-the-middle" e non solo compromette il tuo account, ma mette in discussione ogni messaggio inviato e file ricevuto. Non puoi essere sicuro se stai parlando con il mittente o meno, e anche se lo sei, non puoi essere sicuro che nessuno stia guardando tutto nel mezzo.
Diamo ora un'occhiata alla crittografia SSL, il tipo che rende HTTP più sicuro. Qui, abbiamo un ufficio postale che gestisce la corrispondenza, che controlla se il destinatario è chi afferma di essere e ha leggi che proteggono la tua posta dall'essere esaminata. È complessivamente più sicuro e l'autorità centrale - Verisign è una di queste, per il nostro esempio HTTPS - si assicura che la persona a cui stai inviando la posta effettui il check-out. Lo fanno non consentendo cartoline (credenziali non crittografate); invece richiedono buste reali.
Infine, diamo un'occhiata a SSH. Qui, la configurazione è leggermente diversa. Non abbiamo un autenticatore centrale qui, ma le cose sono comunque al sicuro. Questo perché stai inviando lettere a qualcuno di cui conosci già l'indirizzo - diciamo, chattando con loro al telefono - e stai usando una matematica davvero stravagante per firmare la tua busta. Lo consegni a tuo fratello, alla tua ragazza, al tuo papà o alla tua figlia perché lo porti all'indirizzo e solo se la matematica fantasia del destinatario corrisponde, presumi che l'indirizzo sia quello che dovrebbe essere. Quindi, ricevi una lettera indietro, anch'essa protetta da occhi indiscreti da questa fantastica matematica. Infine, invii le tue credenziali in un'altra busta segreta incantata algoritmicamente alla destinazione. Se la matematica non corrisponde, possiamo presumere che il destinatario originale si sia spostato e dobbiamo confermare nuovamente il suo indirizzo.
Con la spiegazione finché è, pensiamo di tagliarla lì. Se hai qualche informazione in più, sentiti libero di chattare nei commenti, ovviamente. Per ora, però, diamo un'occhiata alla caratteristica più rilevante di SSH, l'autenticazione dell'host.
Chiavi host
L'autenticazione dell'host è essenzialmente la parte in cui qualcuno di cui ti fidi prende la busta (sigillata con matematica magica) e conferma l'indirizzo del tuo destinatario. È una descrizione piuttosto dettagliata dell'indirizzo e si basa su alcuni calcoli complicati che salteremo subito. Tuttavia, ci sono un paio di cose importanti da tenere a mente:
- Poiché non esiste un'autorità centrale, la vera sicurezza risiede nella chiave host, nelle chiavi pubbliche e nelle chiavi private. (Questi ultimi due tasti vengono configurati quando ti viene concesso l'accesso al sistema.)
- Di solito, quando ti connetti a un altro computer tramite SSH, la chiave host viene memorizzata. Ciò rende le azioni future più veloci (o meno dettagliate).
- Se la chiave host cambia, molto probabilmente verrai avvisato e dovresti stare attento!
Poiché la chiave host viene utilizzata prima dell'autenticazione per stabilire l'identità del server SSH, assicurati di controllare la chiave prima di connetterti. Vedrai una finestra di dialogo di conferma come di seguito.
Non dovresti preoccuparti, però! Spesso quando la sicurezza è un problema, ci sarà un posto speciale in cui la chiave host (impronta digitale ECDSA sopra) può essere confermata. Nelle iniziative interamente online, spesso sarà su un sito di accesso protetto. Potrebbe essere necessario (o scegliere di!) Telefonare al reparto IT per confermare questo tasto al telefono. Ho persino sentito parlare di alcuni punti in cui la chiave si trova sul badge di lavoro o nell'elenco speciale "Numeri di emergenza". E, se hai accesso fisico alla macchina di destinazione, puoi anche controllare tu stesso!
Controllo della chiave host del sistema
Esistono 4 tipi di algoritmi di crittografia utilizzati per creare le chiavi, ma l'impostazione predefinita per OpenSSH all'inizio di quest'anno è ECDSA ( con alcune buone ragioni ). Oggi ci concentreremo su quello. Ecco il comando che puoi eseguire sul server SSH a cui hai accesso:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Il tuo output dovrebbe restituire qualcosa del genere:
256 ca: 62: ea: 7c: e4: 9e: 2e: a6: 94: 20: 11: db: 9c: 78: c3: 4c /etc/ssh/ssh_host_ecdsa_key.pub
Il primo numero è la lunghezza in bit della chiave, quindi è la chiave stessa e infine hai il file in cui è memorizzato. Confronta quella parte centrale con ciò che vedi quando ti viene chiesto di accedere da remoto. Dovrebbe corrispondere e sei pronto. In caso contrario, potrebbe succedere qualcos'altro.
Puoi visualizzare tutti gli host a cui ti sei connesso tramite SSH guardando il tuo file known_hosts. Di solito si trova in:
~ / .ssh / known_hosts
Puoi aprirlo in qualsiasi editor di testo. Se guardi, prova a prestare attenzione a come vengono archiviate le chiavi. Vengono memorizzati con il nome (o indirizzo web) del computer host e il suo indirizzo IP.
Modifica delle chiavi e dei problemi dell'host
Ci sono alcuni motivi per cui le chiavi host cambiano o non corrispondono a quanto registrato nel tuo file known_hosts.
- Il sistema è stato reinstallato / riconfigurato.
- Le chiavi host sono state modificate manualmente a causa dei protocolli di sicurezza.
- Il server OpenSSH è stato aggiornato e utilizza standard diversi a causa di problemi di sicurezza.
- Il lease IP o DNS è cambiato. Questo spesso significa che stai tentando di accedere a un computer diverso.
- Il sistema è stato compromesso in qualche modo tale che la chiave host è cambiata.
Molto probabilmente, il problema è uno dei primi tre e puoi ignorare la modifica. Se il lease IP / DNS è cambiato, potrebbe esserci un problema con il server e potresti essere indirizzato a una macchina diversa. Se non sei sicuro di quale sia il motivo del cambiamento, probabilmente dovresti presumere che sia l'ultimo della lista.
Come OpenSSH gestisce gli host sconosciuti
OpenSSH ha un'impostazione per come gestisce host sconosciuti, riflessa nella variabile "StrictHostKeyChecking" (senza virgolette).
A seconda della configurazione, le connessioni SSH con host sconosciuti (le cui chiavi non sono già nel tuo file known_hosts) possono andare in tre modi.
- StrictHostKeyChecking è impostato su no; OpenSSH si connetterà automaticamente a qualsiasi server SSH indipendentemente dallo stato della chiave host. Questo non è sicuro e non è consigliato, tranne se stai aggiungendo un gruppo di host dopo una reinstallazione del tuo sistema operativo, dopodiché lo cambierai di nuovo.
- StrictHostKeyChecking è impostato per chiedere; OpenSSH ti mostrerà le nuove chiavi host e chiederà conferma prima di aggiungerle. Impedirà alle connessioni di andare alle chiavi host modificate. Questa è l'impostazione predefinita.
- StrictHostKeyChecking è impostato su yes; L'opposto di "no", questo ti impedirà di connetterti a qualsiasi host che non sia già presente nel tuo file known_hosts.
È possibile modificare facilmente questa variabile dalla riga di comando utilizzando il seguente paradigma:
ssh -o 'StrictHostKeyChecking [option]' user @ host
Sostituisci [option] con "no", "chiedi" o "sì". Tieni presente che ci sono virgolette singole che circondano questa variabile e la sua impostazione. Sostituisci anche user @ host con il nome utente e il nome host del server a cui ti stai collegando. Per esempio:
ssh -o 'StrictHostKeyChecking chiedi' [email protected]
Host bloccati a causa di chiavi modificate
Se hai un server a cui stai tentando di accedere a cui è già stata modificata la chiave, la configurazione predefinita di OpenSSH ti impedirà di accedervi. Potresti modificare il valore StrictHostKeyChecking per quell'host, ma non sarebbe completamente, completamente, paranoicamente sicuro, no? Invece, possiamo semplicemente rimuovere il valore incriminato dal nostro file known_hosts.
Questa è decisamente una brutta cosa da avere sullo schermo. Fortunatamente, la nostra ragione per questo era un sistema operativo reinstallato. Quindi, ingrandiamo la riga di cui abbiamo bisogno.
Ci siamo. Vedi come cita il file che dobbiamo modificare? Ci dà anche il numero di riga! Quindi, apriamo quel file in Nano:
Ecco il nostro tasto offensivo, nella riga 1. Tutto quello che dobbiamo fare è premere Ctrl + K per tagliare l'intera riga.
È molto meglio! Quindi, ora premiamo Ctrl + O per scrivere (salvare) il file, quindi Ctrl + X per uscire.
Ora invece riceviamo un bel messaggio, al quale possiamo semplicemente rispondere con "sì".
Creazione di nuove chiavi host
Per la cronaca, non c'è davvero un motivo per cambiare la chiave host, ma se mai ne trovi la necessità, puoi farlo facilmente.
Innanzitutto, passa alla directory di sistema appropriata:
cd / etc / ssh /
Di solito è dove si trovano le chiavi dell'host globale, sebbene alcune distribuzioni le abbiano posizionate altrove. In caso di dubbio controlla la tua documentazione!
Successivamente, elimineremo tutte le vecchie chiavi.
sudo rm / etc / ssh / ssh_host_ *
In alternativa, potresti spostarli in una directory di backup sicura. Solo un pensiero!
Quindi, possiamo dire al server OpenSSH di riconfigurarsi:
sudo dpkg-reconfigure openssh-server
Verrà visualizzato un messaggio mentre il computer crea le nuove chiavi. Ta-da!
Ora che sai come funziona SSH un po 'meglio, dovresti essere in grado di tirarti fuori dai punti difficili. L'avviso / errore "Identificazione host remoto è cambiato" è qualcosa che sconcerta molti utenti, anche quelli che hanno familiarità con la riga di comando.
Per i punti bonus, puoi controllare Come copiare file da remoto su SSH senza inserire la password . Lì imparerai qualcosa in più sugli altri tipi di algoritmi di crittografia e su come utilizzare i file chiave per una maggiore sicurezza.
