Impara gli Ins e Out di OpenSSH sul tuo PC Linux

Abbiamo esaltato le virtù di SSH numerose volte, sia per la sicurezza che per l'accesso remoto. Diamo un'occhiata al server stesso, ad alcuni importanti aspetti di "manutenzione" e ad alcuni accorgimenti che possono aggiungere turbolenza a una corsa altrimenti fluida.

Mentre abbiamo scritto questa guida con Linux in mente, questo può valere anche per OpenSSH in Mac OS X e Windows 7 via Cygwin.

Perché è sicuro

Abbiamo menzionato molte volte in che modo SSH è un ottimo modo per connettere e filtrare in modo sicuro i dati da un punto a un altro. Diamo una breve occhiata a come funzionano le cose in modo da avere un'idea migliore del perché le cose possono diventare strane a volte.

Quando decidiamo di iniziare una connessione con un altro computer, utilizziamo spesso protocolli facili da utilizzare. Telnet e FTP vengono entrambi in mente. Inviamo informazioni a un server remoto e quindi riceviamo 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 sicuri, giusto? Sbagliato!

Se pensiamo al nostro processo di connessione come posta, quindi usare FTP e Telnet e simili non è come usare buste postali standard. È più come usare le cartoline. Se qualcuno accade di intervenire 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 informazioni uguali e impersonare un corrispondente o l'altro. Questo è noto come un attacco "man-in-the-middle" e non solo compromette il tuo account, ma chiama in causa ogni messaggio inviato e il file ricevuto. Non puoi essere sicuro che tu stia parlando con il mittente o no, e anche se lo sei, non puoi essere sicuro che nessuno guardi tutto da in mezzo.

Ora, diamo un'occhiata alla crittografia SSL, il tipo che rende l'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 guardato. È più sicuro in generale, e l'autorità centrale - Verisign è uno, per il nostro esempio HTTPS - si assicura che la persona a cui stai inviando posta per check-out. Lo fanno non consentendo cartoline (credenziali non criptate); invece ordinano buste reali.

Infine, diamo un'occhiata a SSH. Qui, l'installazione è leggermente diversa. Non abbiamo un autenticatore centrale qui, ma le cose sono ancora al sicuro. Questo perché invii lettere a qualcuno di cui già conosci l'indirizzo, ad esempio chiacchierando con loro al telefono, e stai usando una matematica davvero stravagante per firmare la tua busta. Lo consegni a tuo fratello, fidanzata, papà o figlia per portarlo all'indirizzo e solo se le partite di matematica di fantasia del ricevente ritengono che l'indirizzo sia quello che dovrebbe essere. Poi, ricevi una lettera indietro, anche protetta da occhi indiscreti da questa fantastica matematica. Infine, invii le tue credenziali in un'altra busta segretamente incantata con l'algoritmo alla destinazione. Se la matematica non corrisponde, possiamo supporre che il destinatario originale si sia trasferito e dobbiamo confermare nuovamente il loro indirizzo.

Con la spiegazione fintanto che è, pensiamo che lo taglieremo lì. Se hai qualche approfondimento, 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 la matematica magica) e conferma l'indirizzo del destinatario. È una descrizione piuttosto dettagliata dell'indirizzo, ed è basata su una matematica complicata che salteremo proprio sopra. Ci sono un paio di cose importanti da togliere a questo, però:

Poiché non esiste un'autorità centrale, la vera sicurezza risiede nella chiave dell'host, nelle chiavi pubbliche e nelle chiavi private. (Queste ultime due chiavi sono configurate quando ti viene dato l'accesso al sistema.)
Di solito, quando ci si connette a un altro computer tramite SSH, la chiave host viene memorizzata. Questo rende le azioni future più veloci (o meno verbose).
Se la chiave host cambia, molto probabilmente sarai avvisato e dovresti essere cauto!

Poiché la chiave host viene utilizzata prima dell'autenticazione per stabilire l'identità del server SSH, è necessario verificare la chiave prima di connettersi. Verrà visualizzata 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 è possibile confermare la chiave host (impronta ECDSA sopra). In imprese interamente online, spesso si troverà su un sito di accesso sicuro. Potrebbe essere necessario (o scegliere di!) Telefonare al reparto IT per confermare questo tasto per telefono. Ho persino sentito di alcuni posti in cui la chiave è sul tuo badge di lavoro o sulla speciale lista "Numeri di emergenza". Inoltre, se si dispone dell'accesso fisico al computer di destinazione, è anche possibile verificare autonomamente!

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). Ci concentreremo su quello oggi. Ecco il comando che puoi eseguire sul server SSH a cui hai accesso:

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

L'output dovrebbe restituire qualcosa di simile a questo:

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 è il bit-length della chiave, quindi la chiave stessa e infine il file in cui è memorizzato. Confronta quella porzione centrale con ciò che vedi quando ti viene richiesto di accedere da remoto. Dovrebbe corrispondere, e tu sei tutto pronto. Se così non fosse, allora potrebbe accadere qualcos'altro.

Puoi vedere tutti gli host a cui 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 si guarda, cercare di prestare attenzione a come vengono memorizzate le chiavi. Sono memorizzati con il nome del computer host (o indirizzo web) 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 ciò che viene registrato nel file known_hosts.

Il sistema è stato reinstallato / riconfigurato.
Le chiavi host sono state modificate manualmente a causa di protocolli di sicurezza.
Il server OpenSSH 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 altro computer.
Il sistema è stato compromesso in un modo tale che la chiave host è cambiata.

Molto probabilmente, il problema è uno dei primi tre e puoi ignorare il cambiamento. Se il lease IP / DNS è cambiato, potrebbe esserci un problema con il server e si potrebbe essere indirizzati a un altro computer. Se non sei sicuro di quale sia la ragione del cambiamento, probabilmente dovresti assumere che sia l'ultimo della lista.

Come OpenSSH gestisce host sconosciuti

OpenSSH ha un'impostazione per come gestisce gli host sconosciuti, riflessa nella variabile "StrictHostKeyChecking" (senza virgolette).

A seconda della configurazione, le connessioni SSH con host sconosciuti (le cui chiavi non sono già presenti nel file known_hosts) possono essere utilizzate in tre modi.

StrictHostKeyChecking è impostato su no; OpenSSH si connetterà automaticamente a qualsiasi server SSH indipendentemente dallo stato della chiave dell'host. Questo non è sicuro e non è raccomandato, tranne se stai aggiungendo un gruppo di host dopo una reinstallazione del tuo sistema operativo, dopodiché lo cambierai.
StrictHostKeyChecking è impostato per chiedere; OpenSSH mostrerà le nuove chiavi host e chiederà conferma prima di aggiungerle. Impedirà alle connessioni di passare a chiavi host modificate. Questo è l'impostazione predefinita.
StrictHostKeyChecking è impostato su yes; L'opposto di "no", ciò impedirà la connessione a qualsiasi host che non sia già presente nel file known_hosts.

È possibile modificare facilmente questa variabile sulla riga di comando utilizzando il seguente paradigma:

ssh -o 'StrictHostKeyChecking [opzione]' utente @ host

Sostituisci [opzione] con "no", "chiedi" o "sì". Ricorda che ci sono singole virgolette che circondano questa variabile e le sue impostazioni. Sostituisci anche utente @ host con il nome utente e il nome host del server a cui ti stai connettendo. Per esempio:

ssh -o 'StrictHostKeyChecking ask' [email protected]

Host bloccati a causa di chiavi modificate

Se si dispone di un server a cui si sta tentando di accedere e la chiave è già stata modificata, la configurazione predefinita di OpenSSH impedirà l'accesso. È possibile modificare il valore StrictHostKeyChecking per quell'host, ma ciò non sarebbe interamente, completamente, paranoicamente sicuro, vero? Invece, possiamo semplicemente rimuovere il valore offendente dal nostro file known_hosts.

Questa è decisamente una brutta cosa da avere sul tuo schermo. Fortunatamente, il nostro motivo per questo era un sistema operativo reinstallato. Quindi, ingrandiamo la linea di cui abbiamo bisogno.

Eccoci. Guarda come cita il file che dobbiamo modificare? Ci dà persino il numero di linea! Quindi, apriamo il file in Nano:

Ecco la nostra chiave offendente, nella riga 1. Tutto ciò che dobbiamo fare è premere Ctrl + K per tagliare l'intera linea.

È molto meglio! Quindi, ora premiamo Ctrl + O per scrivere (salvare) il file, quindi Ctrl + X per uscire.

Ora invece riceviamo un bel prompt, al quale possiamo semplicemente rispondere con "sì".

Creazione di nuove chiavi host

Per la cronaca, non c'è davvero un motivo in più per cambiare la chiave dell'host, ma se mai ne trovi la necessità, puoi farlo facilmente.

Innanzitutto, passare alla directory di sistema appropriata:

cd / etc / ssh /

Questo di solito è dove sono le chiavi globali dell'host, anche se alcune distribuzioni li hanno posizionati altrove. In caso di dubbi, controlla la tua documentazione!

Successivamente, elimineremo tutte le vecchie chiavi.

sudo rm / etc / ssh / ssh_host_ *

In alternativa, è possibile spostarli in una directory di backup sicura. Solo un pensiero!

Quindi, possiamo dire al server OpenSSH di riconfigurare se stesso:

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 luoghi difficili. L'avviso / errore "Remote Host Identification Has Changed" è qualcosa che getta via molti utenti, anche quelli che hanno familiarità con la riga di comando.