Connettiti a un server virtuale tramite SSH e SFTP. Connessione al server tramite SSH e SFTP Connessione tramite ssh tramite putty

Cos'è SSH e perché ne hai bisogno?

Secure Shell (SSH) è un protocollo di rete che fornisce funzioni shell a una macchina remota attraverso un canale sicuro. SSH è dotato di vari miglioramenti della sicurezza, tra cui l'autenticazione utente/host, la crittografia e l'integrità dei dati, rendendo impossibili attacchi comuni come l'intercettazione, lo spoofing DNS/IP, la falsificazione dei dati e il dirottamento della connessione, ecc. Utenti FTP, telnet o rlogin che utilizzano un protocollo che trasferisce i dati in testo non crittografato si consiglia vivamente di passare a SSH.

OpenSSH è un'implementazione open source del protocollo SSH che ti consente di crittografare la tua connessione di rete attraverso una serie di programmi. Se desideri avere SSH su Linux, puoi installare OpenSSH, che consiste in un server OpenSSH e pacchetti client.

I pacchetti server/client OpenSSH vengono forniti con le seguenti utilità:

  • Server OpenSSH: sshd (demone SSH)
  • Client OpenSSH: scp (copia remota sicura), sftp (trasferimento file sicuro), slogin/ssh (accesso remoto sicuro), ssh-add (completamento chiave privata), ssh-agent (agente di autenticazione), ssh-keygen (gestione chiave di autenticazione ).
Installazione del server e client OpenSSH su Linux

Se desideri installare il server/client OpenSSH e configurare il server OpenSSH per l'avvio automatico, segui le seguenti istruzioni, che variano a seconda della distribuzione.

Debian, Ubuntu o Linux Mint

$ sudo apt-get install openssh-server openssh-client

Sui sistemi basati su Debian, una volta installato, OpenSSH si avvierà automaticamente all'avvio. Se per qualche motivo il server OpenSSH non si avvia automaticamente all'avvio del sistema, è possibile eseguire il comando seguente per aggiungere esplicitamente ssh all'avvio del sistema.

$ sudo update-rc.d impostazioni predefinite ssh

Fedora o CentOS/RHEL 7

$ sudo yum -y installa openssh-server openssh-clients $ sudo systemctl avvia il servizio sshd $ sudo systemctl abilita sshd.service

CentOS/RHEL6

$ sudo yum -y install openssh-server openssh-clients $ sudo service sshd start $ sudo chkconfig sshd on

ArcoLinux

$ sudo pacman -Sy openssh $ sudo systemctl avvia il servizio sshd $ sudo systemctl abilita sshd.service

Configurazione di un server OpenSSH

Se desideri configurare il server OpenSSH, puoi modificare il file di configurazione a livello di sistema situato in /etc/ssh/sshd_config.

Ci sono un paio di opzioni OpenSSH che potrebbero interessare:
Per impostazione predefinita, sshd è in ascolto sulla porta 22 e ascolta le connessioni ssh in entrata. Modificando la porta predefinita per ssh, puoi prevenire vari attacchi hacker automatizzati.
Se il tuo computer ha più di un'interfaccia di rete fisica, potresti voler verificare quale è associata a sshd, per questo puoi utilizzare l'opzione ListenAddress. Questa opzione aiuta a migliorare la sicurezza limitando l'SSH in entrata solo a un'interfaccia specifica.

HostKey /etc/ssh/ssh_host_key

L'opzione HostKey determina dove si trova la chiave host personale.

PermitRootLogin n

Opzione PermitRootLogin: indica se root può accedere al sistema tramite ssh.

Consenti utenti alice bob

Utilizzando l'opzione ConsentiUsers è possibile disabilitare selettivamente il servizio ssh per determinati utenti Linux. È possibile specificare più utenti, separati da spazi.

Dopo che /etc/ssh/sshd_config è stato modificato, assicurati di riavviare il servizio ssh.

Per riavviare OpenSSH su Debian, Ubuntu o Linux Mint:

$ sudo /etc/init.d/ssh riavviare

Per riavviare OpenSSH su Fedora, CentOS/RHEL 7 o Arch Linux:

$ sudo systemctl riavvia sshd.service

Per riavviare OpenSSH su CentOS/RHEL 6:

$ sudo servizio sshd riavvio

Come connettersi a SSH

Connessione a SSH da Linux

Gli utenti Linux non hanno bisogno di installare programmi aggiuntivi.

Connessione a SSH da Windows

Nascosto agli ospiti

.

Cygwin è molto più di un semplice client SSH. È un potente combinatore che supporta molti comandi Linux. Ad esempio, Cygwin semplifica la creazione di certificati SSL (proprio come Linux). In Windows, per creare certificati autofirmati devi ballare con un tamburello. Cygwin è molto comodo da usare cURL (non è necessario installare nulla separatamente), ecc. Coloro che non hanno la riga di comando e i programmi Linux su Windows troveranno uno sbocco in Cygwin.

Installare Cygwin è facile. Andiamo a

Nascosto agli ospiti

E scarica

Nascosto agli ospiti

Nascosto agli ospiti

Verrà scaricato un piccolo file: questo è il programma di installazione. Installatore grafico. Sebbene contenga un gran numero di opzioni, sono tutte abbastanza semplici e molte sono familiari ad altri programmi di installazione grafica. Se qualcosa non è chiaro, basta cliccare su “Avanti”. Forse solo la seguente finestra può creare confusione:

Tutti gli elementi disponibili per l'installazione sono qui presentati. Non abbiamo bisogno di capirli adesso. Perché quelli più popolari sono già contrassegnati per l'installazione. E se in futuro dovesse mancare qualcosa, potrai installare facilmente ciò di cui hai bisogno.

Connessione SSH (comune a Linux e Windows)

Gli utenti Linux aprono la console, gli utenti Windows digitano Cygwin.

SSH necessita delle seguenti informazioni per connettersi:

  • IP o nome host
  • numero di porta
  • Nome utente
  • password utente
Due di questi parametri SSH può indovinare: nome utente e numero di porta. Se non viene specificata una porta, si presuppone la porta predefinita. Se non viene specificato un utente, verrà utilizzato lo stesso nome del sistema da cui viene effettuata la connessione. Ad esempio, l'indirizzo host per la connessione è 192.168.1.36. Se compongo

Ssh192.168.1.36

Vedo quanto segue

Alex@MiAl-PC ~ $ ssh 192.168.1.36 Impossibile stabilire l'autenticità dell'host "192.168.1.36 (192.168.1.36)". L'impronta digitale della chiave ECDSA è SHA256:sIxZeSuiivoEQ00RXAQHxylxuEA8SC5r/YPhL8wfp8s. Sei sicuro di voler continuare a connetterti ( si No)?

Poiché mi collego all'host per la prima volta, si tratta di un host sconosciuto. Mi chiedono se voglio continuare. Sto chiamando :

Avvertenza: aggiunto permanentemente "192.168.1.36" (ECDSA) all'elenco degli host conosciuti. [e-mail protetta] la password:

Ok, l'host 192.168.1.36 è stato aggiunto all'elenco degli host familiari. Mi viene richiesta una password per l'utente Alex. Poiché non esiste un utente di questo tipo sul server con SSH, ma faccio clic CTRL+C(per interrompere) e inserire il comando insieme al nome utente del sistema remoto. L'utente viene inserito prima dell'indirizzo della macchina remota ed è separato dall'indirizzo dal simbolo @. Il simbolo @ in inglese si legge come at e può essere tradotto come “in”. Quelli. registrazione [e-mail protetta] può essere interpretato come "utente mial sulla macchina 192.168.1.36".

Ssh [e-mail protetta]

L'invito Alex@MiAl-PC è stato sostituito dall'invito mial@mint. Ciò significa che siamo già sulla macchina remota, cioè abbiamo già effettuato la connessione. Se è necessario specificare una porta (se diversa da quella standard), è necessario specificarla dopo l'opzione -p. Ad esempio in questo modo:

Ssh [e-mail protetta]-p10456

Dopo la connessione, veniamo accolti da qualcosa del genere:

Linux mint 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 I programmi inclusi con il sistema Debian GNU/Linux sono software libero; gli esatti termini di distribuzione per ciascun programma sono descritti nei singoli file in /usr/share/doc/*/copyright. Debian GNU/Linux viene fornito con ASSOLUTAMENTE NESSUNA GARANZIA, nella misura consentita dalla legge applicabile. Ultimo accesso: mar 16 giugno 15:32:25 2015 da 192.168.1.35

Ne consegue che la macchina remota è Linux Mint, con kernel 3.16, versione a 64 bit. Altre informazioni importanti sono l'ora dell'ultimo accesso e l'indirizzo IP da cui ha avuto origine la connessione. Se l'ora e l'IP non ti sono familiari e sei l'unico utente, il tuo sistema è compromesso e devi intraprendere le azioni appropriate.

Digitiamo alcuni comandi per assicurarci dove siamo e chi siamo: pwd, [B]nome -a eccetera.:

Per terminare la sessione (disconnettersi), comporre

Oppure fare clic CTRL+D.

Accedi a SSH senza inserire una password

Innanzitutto, è semplicemente più conveniente. In secondo luogo, è più sicuro.

Per prima cosa dobbiamo creare le chiavi RSA. Se sei un utente Linux, allora stai bene. Se sei un utente Windows, ma non hai ascoltato il mio consiglio e hai scelto PuTTY, allora hai un problema e pensa tu stesso a come risolverlo. Se hai Cygwin, anche tutto è in ordine.

Se sei riuscito ad accedere al sistema remoto, disconnettiti. Successivamente, componi il numero

Ssh-keygen -t rsa

Ci viene chiesto un nome per il file, non dobbiamo inserire nulla, verrà utilizzato il nome predefinito. Richiede anche una password. Non inserisco la password.

Ora sul computer remoto dobbiamo creare una directory .ssh. L'esecuzione del comando su una macchina remota verrà discussa di seguito. Per ora basta copiare il comando, senza dimenticare di cambiare l'indirizzo IP e il nome utente con i propri:

Ssh [e-mail protetta] mkdir.ssh

Ora dobbiamo copiare il contenuto del file id_rsa.pub sul computer remoto. Questo è molto semplice da fare (non dimenticare di modificare i dati con i tuoi):

Cat .ssh/id_rsa.pub | ssh [e-mail protetta]"cat >> .ssh/authorized_keys"

Ora facciamo semplicemente il login e non ci chiedono più nessuna password. E adesso sarà sempre così.

Esecuzione di comandi su un server remoto senza creare una sessione di shell

Oltre ad aprire una sessione di shell su un sistema remoto, ssh consente anche di eseguire comandi individuali sul sistema remoto. Ad esempio, per eseguire il comando tree su un host remoto denominato remote-sys e visualizzare i risultati sul sistema locale, dovresti fare quanto segue:

Albero del sistema remoto Ssh

Il mio vero esempio:

Ssh [e-mail protetta] albero

Usando questa tecnica puoi fare cose interessanti, come eseguire un comando ls su un sistema remoto e reindirizzare l'output su un file sul sistema locale:

Ssh remote-sys "ls *" > dirlist.txt

Esempio reale:

Ssh [e-mail protetta]"ls *" > dirlist.txt cat dirlist.txt

Nota le virgolette singole nel comando precedente. Questo perché non vogliamo che l'espansione del percorso venga eseguita sul computer locale; perché abbiamo bisogno di questa esecuzione su un sistema remoto. Inoltre, se vogliamo reindirizzare l'output standard su un file sul computer remoto, possiamo inserire l'istruzione di reindirizzamento e il nome del file tra virgolette singole:

Ssh remote-sys "ls * > dirlist.txt"

Trasferimento dell'output standard dal computer locale al computer remoto tramite ssh

Un'opzione altrettanto interessante per l'esecuzione dei comandi viene fornita leggermente più in alto:

Cat .ssh/id_rsa.pub | ssh [e-mail protetta]"cat >> .ssh/authorized_keys"

  • Il comando cat legge e visualizza il contenuto del file .ssh/id_rsa.pub, situato sul computer locale, riga per riga.
  • | (pipe) passa ciò che apparirebbe sullo standard output a un altro comando.
  • Invece di un comando che elabori le stringhe che gli vengono passate, viene stabilita una connessione al sistema remoto (ssh [e-mail protetta]).
  • Il sistema remoto riceve righe per le quali viene fornito il comando cat >> .ssh/authorized_keys. Quelli. il contenuto dell'output standard viene scritto riga per riga nel file .ssh/authorized_keys situato sul computer remoto.
Apertura di un programma di grafica situato su un computer remoto

Il prossimo trucco richiede due computer Linux. Sfortunatamente, nemmeno Cygwin è in grado di gestire questo trucco. Inoltre, entrambi i sistemi Linux devono avere un'interfaccia utente grafica.

Tunneling con SSH

Quando si stabilisce una connessione con un host remoto tramite SSH, tra le altre cose che accade è la creazione di un tunnel crittografato tra il sistema locale e quello remoto. In genere, questo tunnel viene utilizzato per garantire che i comandi digitati sulla macchina locale vengano trasmessi in modo sicuro a una macchina remota e che anche il risultato venga inviato indietro in modo sicuro.

Oltre a questa funzionalità di base, il protocollo SSH consente di inviare la maggior parte dei tipi di traffico attraverso un tunnel crittografato, creando una sorta di VPN (rete privata virtuale) tra il sistema locale e quello remoto.

Forse la funzionalità più comunemente utilizzata è la capacità di trasmettere il traffico dei sistemi X Window. Su un sistema che esegue un server X (si tratta di macchine dotate di un'interfaccia utente grafica), è possibile eseguire un programma client X (un'applicazione grafica) su un sistema remoto e vedere i risultati del suo funzionamento sul sistema locale. È facile da fare. Ad esempio, voglio connettermi all'host remoto remote-sys e su di esso voglio eseguire il programma xload. Allo stesso tempo, potrò vedere l'output grafico di questo programma sul computer locale. Questo è fatto in questo modo:

Ssh -X remote-sys xload

Esempio reale:

Ssh-X [e-mail protetta] gedit

Quelli. SSH inizia con l'opzione -X. E poi il programma si avvia semplicemente. Guarda lo screenshot.

Sono su Kali Linux. Ho effettuato l'accesso con successo a un computer remoto tramite SSH. Successivamente ho eseguito il programma gedit. Questo programma potrebbe non essere nemmeno su Kali Linux, ma sicuramente è su Linux Mint, che è quello a cui mi sono connesso. Posso vedere il risultato di questo programma sullo schermo come se il programma fosse in esecuzione localmente. Ma ancora una volta, voglio che tu capisca questo, non esiste alcun programma gedit in esecuzione sul computer locale. Se voglio salvare il risultato di gedit (o qualsiasi altro programma aperto in questo modo), risulta che funziona nell'ambiente del computer remoto, vede il suo file system, ecc. Questo è comodo quando vuoi configurare il computer remoto utilizzando un'interfaccia grafica.

Imparerai come trasferire un'immagine dall'intero desktop nello stesso articolo più avanti, nella sezione “Come configurare VNC tramite SSH”.

Su alcuni sistemi, questo trucco richiede l'utilizzo dell'opzione -Y invece dell'opzione -X.

Copia da/verso un computer remoto (scp e sftp)

scp

Il pacchetto OpenSSH include anche due programmi che utilizzano un tunnel SSH crittografato per copiare file sulla rete. Primo programma - scp("copia protetta") - usato più spesso, come il programma simile cp per copiare i file. La differenza più evidente è che l'origine del file può essere l'host remoto seguito da due punti e dalla posizione del file. Ad esempio, se volessimo copiare un documento chiamato document.txt dalla nostra directory home a remote-sys nella directory di lavoro corrente sul nostro sistema locale, potremmo fare questo:

Scp remote-sys:document.txt . documento.txt 100% 177 0,2 KB/s 00:00

Esempio reale:

# cancella il file sulla macchina locale se esiste rm dirlist.txt # crea un file sulla macchina remota ssh [e-mail protetta]"ls * > dirlist.txt" # controlla la sua presenza ssh [e-mail protetta]"ls -l" # copialo sulla macchina locale scp [e-mail protetta]:dirlist.txt. # controlla il suo contenuto cat dirlist.txt

  • [e-mail protetta]- nome utente e host remoto,
  • . (punto) significa che il file deve essere copiato nella directory di lavoro corrente sul server remoto, ma il nome del file rimarrà lo stesso, ovvero nfile.txt
  • Nota:

    Per copiare un file da B ad A quando si accede a B:
    scp /percorso/del/file nomeutente@a:/percorso/della/destinazione
    Copiare un file da B ad A quando si è effettuato l'accesso ad A:
    scp nomeutente@b:/percorso/del/file /percorso/della/destinazione

    sftp

    Il secondo programma per copiare file su SSH è sftp. Come suggerisce il nome, si tratta di un sostituto sicuro del programma FTP. sftp funziona come il programma ftp originale. Tuttavia, invece di inviare testo in chiaro, utilizza un tunnel SSH crittografato. Un vantaggio importante di sftp rispetto a ftp è che non richiede un server FTP in esecuzione su un host remoto. Richiede solo un server SSH. Ciò significa che qualsiasi macchina remota connessa tramite un client SSH può essere utilizzata anche come server simile a FTP. Ecco una sessione di esempio:

    Alex@MiAl-PC ~ $ sftp [e-mail protetta] Connesso a 192.168.1.36. sftp> ls dirlist.txt newfile.txt nfile.txt temp Video Documenti Download Immagini Musica Modelli desktop pubblici sftp> lls dirlist.txt nfile.txt sftp> ls temp temp/TakeMeHome sftp> cd temp/ sftp> get TakeMeHome Recupero /home / mial/temp/TakeMeHome a TakeMeHome sftp> ciao

    Il protocollo SFTP è supportato da molti file manager grafici che possono essere trovati nelle distribuzioni Linux. Utilizzando sia Nautilus (GNOME) che Konqueror (KDE), possiamo inserire URI (collegamenti) che iniziano con sftp:// nella barra di salto e lavorare con file situati su un sistema remoto che esegue un server SSH.

    Ciao! Mi interessa la domanda: come connettermi tramite SSH al tuo computer di casa tramite Internet. Ho un server FreeSSHd installato a casa. A quanto ho capito, devo in qualche modo aprire la porta 22 sull'IP esterno? Alex

    Sì, spesso se ne presenta la necessità. Ho parlato di molte cose in quell'articolo, ma qui parleremo esclusivamente di SSH, dato che Alex ci ha gentilmente fornito questa opportunità. Inoltre, io stesso sono incredibilmente interessato a SSH, e qui è anche su Windows... mmm.

    Cos'è SSH e perché è necessario?

    Il punto è che SSH lo è S sicuro SH ell. Protocollo per l'accesso sicuro alla shell di controllo. Pertanto, fornisce l'accesso specifico alla riga di comando, poiché Shell viene tradotto come conchiglia e qui nel significato shell di controllo del testo. Ma in generale, questo protocollo si distingue per il fatto che consente il passaggio di qualsiasi altro traffico al suo interno, e in forma crittografata. Pertanto, il protocollo di connessione sicura del file system si chiama SFTP e viene eseguito su SSH. Ma può eseguire il tunneling di qualsiasi altra connessione, sia essa HTTP o anche RDP. In sostanza si tratta di una “VPN in ginocchio”.

    Qui Alex ha già fatto metà del lavoro: ha installato e lanciato FreeSSHd sul suo computer di casa. Ciò ti consente di connetterti a Windows tramite SSH. In questo caso, “permette” è detto in modo molto forte. Perché questa soluzione funziona in qualche modo su Windows. In primo luogo, non ha un'interfaccia testuale decente: una riga di comando per il controllo.

    Almeno quello normale - cmd - ti consente di fare poco con la macchina remota. C'è anche Powershell: questa è una soluzione più moderna e potente. Freesshd ti consente di cambiare la console in PowerShell, ma non sono riuscito a connettermi ad essa. Mi sono connesso a CMD, ma è completamente inutilizzabile:

    In secondo luogo, nel caso di FreeSSHd non sono riuscito a connettermi a un computer Windows nemmeno tramite una rete locale, per non parlare della connessione tramite Internet. O meglio, è possibile connettersi, ma il servizio si blocca e va in crash; non potrai gestire l’host Windows in questo modo.

    Pertanto, presumo che Alex avesse bisogno di un server ssh su Windows per connettersi al file system o usarlo come VPN, proxy qualcosa su SSH. Anche se dubito che FreeSSHd lo consentirà. Perché in terzo luogo: non salva nemmeno le impostazioni; quando riavvii il servizio, tutto va storto. In generale, spero davvero che Alex ci dica nei commenti perché ne aveva bisogno.

    In quale altro modo puoi eseguire SSH su Windows?

    Esiste una soluzione più praticabile: Powershelserver. Sebbene abbia anche dei bug, almeno non si blocca. Pertanto, consiglierei di utilizzarlo per connettersi tramite SSH ai server Windows.

    Innanzitutto, funziona stabilmente senza arresti anomali. E attraverso di esso puoi davvero controllare Windows tramite PowerShell.

    Tutte le impostazioni vengono salvate normalmente. Sono disponibili le stesse funzioni di FreeSSHd e anche di più: puoi usare SCP: copia file su SSH.

    Ma la cosa più chic è la console! Funziona, signori!

    Mi sono connesso facilmente, senza problemi con l'aggiunta di utenti (questo deve essere fatto in freesshd). E quel semplice comando per visualizzare la tabella di routing ha funzionato perfettamente e ha fornito le informazioni necessarie. Frisssh mi è "caduto" proprio quando ho provato a visualizzare netstat -rn

    Qui puoi davvero vedere che i caratteri russi non vengono visualizzati. Quindi è facile configurarlo con noi, devo solo impostare la codifica di cui ho bisogno su PowerShellserver, riavviare, riconnettermi...

    Impostazione della codifica in Powershellserver

    Ora disponiamo di SSH completo e possiamo gestire completamente Windows tramite la console.

    Microsoft creerà la propria soluzione SSH

    A proposito, Microsoft ha annunciato già in estate il suo sviluppo nativo Supporto SSH per Powershell nelle nuove versioni di Windows. Ci sono annunci di notizie su Habré e su pcweek (e altro ancora). Pertanto, non possiamo che guardare con impazienza a questo evento epocale, poiché rappresenterà davvero una svolta per il lavoro reti eterogenee.

    Non ho controllato le altre funzioni: sftp e scp, ma per qualche motivo sono sicuro che funzioneranno benissimo.

    Come aprire una porta SSH dall'esterno?

    Quindi, siamo arrivati ​​​​alla cosa segreta per cui questo articolo è stato iniziato in primo luogo. Risponderò alla domanda del lettore.

    Inoltro porta su un router o modem

    Per connettersi a un computer dall'esterno è necessario eseguire effettivamente il NAT o, in un caso particolare, . La modalità di esecuzione dipende dal dispositivo utilizzato come gateway. Potrebbe trattarsi di un modem ADSL o . Nella maggior parte dei casi, istruzioni dettagliate per il tuo dispositivo possono essere facilmente trovate tramite query come "port forwarding Modello del dispositivo" o "inoltro porta Modello del dispositivo»

    Questo è quello che appare sul mio router domestico Zyxel Keenetic Lite:

    Ed ecco come appare su un modem ADSL con le funzionalità del router Linksys WAG200G a portata di mano:

    Inoltre con alcuni provider ciò potrebbe non essere tecnicamente possibile perché non forniscono il "bianco".

    Inoltro di una porta a un server remoto utilizzando un tunnel SSH

    In questo caso, l'unico modo disponibile per connettersi tramite SSH è da una macchina Windows locale (la stessa a cui vogliamo connetterci tramite SSH) a un server remoto. In questo caso, devi avere accesso SSH ad alcuni server su Internet.

    Configurazione di un tunnel SSH "inverso".

    Tale inoltro può essere eseguito facilmente utilizzando un semplice client SSH Putty (esiste anche). Quindi puoi connetterti a questo server molto remoto tramite la porta inoltrata.

    È essenzialmente un loop qui. Apriamo una sessione SSH da Windows a un server remoto e all'interno di questa connessione eseguiamo il tunneling della porta SSH di Windows Powershellserver (o FreeSSHd) stesso alla porta locale 3322 del server remoto. E nella stessa sessione ora ci ricolleghiamo a Windows su Powershell tramite la stessa porta 3322... Spero che tu non sia confuso. Ma... Questa è magia, amici! :) I tunnel SSH sono un mondo speciale, con il loro aiuto puoi fare cose incredibili, aprire porte tali che tutte le guardie di sicurezza piangerebbero amaramente se all'improvviso scoprissero tutto questo... Ma vabbè.

    Bene, se hai bisogno di condividere la porta SSH di Windows con il mondo, è sufficiente specificare ip_server:3322 come destinazione nelle impostazioni del tunnel inverso. Potrai connetterti a Windows tramite SSH da qualsiasi luogo in cui sia possibile accedere a questo stesso server.

    Come verificare se la porta è stata inoltrata correttamente?

    Molto semplice. Devi controllare se è aperto. Nel caso di SSH, la porta aperta risponderà con un messaggio sulla sua versione. Il modo più semplice per controllare una porta è l'utilità telnet.

    Basta digitare sulla riga di comando, separati da spazi:

    dominio telnet_o_porta IP

    Se la porta è disponibile, vedrai qualcosa di simile a questo:

    Risposta SSH se la porta è disponibile

    Se per qualche motivo la porta non è disponibile, vedrai "connessione rifiutata" o "timeout della connessione". Nel primo caso sarà istantaneo e significa che la porta è chiusa da un firewall.

    Nel secondo caso, sembrerà un "blocco" e può durare fino a diversi minuti: il client Telnet tenterà di stabilire una connessione. Ciò può anche significare il blocco da parte di un firewall, ma di tipo diverso. O semplicemente che l'host specificato non è disponibile o che la porta su di esso è chiusa.

    Se sei riuscito a connetterti tramite Telnet, premi la combinazione di tasti Ctrl+] e accedi esentato, quindi Invio. Altrimenti non potrai interrompere la sessione e dovrai aprire una nuova finestra della console se ne avrai ancora bisogno.

    Questo articolo è contrassegnato come incompiuto. Vedi nota a fine articolo.

    Questo articolo è dedicato al client e al server di un terminale sicuro (secure shell) in Ubuntu, alla loro configurazione e utilizzo. SSH è uno speciale protocollo di rete che consente di ottenere l'accesso remoto a un computer con un elevato grado di sicurezza della connessione. Puoi leggere ulteriori informazioni sul protocollo ssh.

    Descrizione dei principi di funzionamento e delle applicazioni utilizzate

    Fondamentalmente, SSH è implementato sotto forma di due applicazioni: un server SSH e un client SSH. Ubuntu utilizza un'implementazione gratuita di un client e server SSH - OpenSSH. Durante la connessione, il client viene sottoposto a una procedura di autorizzazione con il server e tra loro viene stabilita una connessione crittografata. Il server OpenSSH può funzionare sia con i protocolli ssh1 che ssh2. Il protocollo ssh1 è attualmente considerato non sicuro e il suo utilizzo è altamente sconsigliato. Ometto volutamente vari dettagli tecnici del protocollo, poiché lo scopo principale di questa guida è descriverne la configurazione e l'utilizzo. Ci sono molti articoli su Internet sul protocollo stesso, sui principi del suo funzionamento, sugli algoritmi di crittografia, ecc., Ad esempio, puoi leggerlo in dettaglio.

    Installazione

    Installare OpenSSH Puoi usare il comando da terminale:

    sudo apt-get install ssh

    Il metapacchetto ssh contiene sia un client che un server, ma molto probabilmente installerà solo il server, poiché il client è già incluso in Ubuntu per impostazione predefinita.

    Ottimizzazione del server

    Durante l'installazione, il server SSH viene aggiunto automaticamente all'avvio. Puoi controllarne l'avvio, l'arresto o il riavvio utilizzando i comandi:

    sudo servizio ssh stop| inizio| ricomincia

    Il file di configurazione principale per un server SSH è il file /etc/ssh/sshd_config, che può essere letto o modificato solo dal superutente. Dopo ogni modifica a questo file, è necessario riavviare il server ssh per applicare tali modifiche.

    Esempio di configurazione del server SSH predefinito in Ubuntu:

    # Un esempio di configurazione di un server open-ssh con commenti russi # #..2010. # # # # # # Convenzioni: # # Per "default" si intende il comportamento di sshd quando # # la direttiva non è specificata esplicitamente. Vale la pena notare che in Ubuntu # # il file sshd_config contiene già una serie di impostazioni che # # sono le impostazioni predefinite specificatamente per Ubuntu. # # Tali impostazioni sono specificate in questo file. # # # ############################################### ############# ################ Impostazioni indirizzo/porta, ecc. ########### ####################################### # ###################### # # ## Porta ###################### ### ############################# # # # Porta utilizzata. È possibile specificarne diverse, ad esempio: # # Porta 22 # # Porta 23 # # Porta 24 # # Si consiglia di utilizzare una porta non standard, perché # # lo standard viene spesso scansionato dai bot alla ricerca di potenziali # # buchi. Può essere omesso se specificato # # tramite un indirizzo. Vedi anche il parametro ListenAddress. # # # Porta 22 # # ## Indirizzo di ascolto ######################################## ### # # # Indirizzo di rete su cui il server è in ascolto. L'indirizzo può # # essere scritto in questo modo: # # ListenAddress host|IPv4_addr|IPv6_addr # # ListenAddress host|IPv4_addr:port # # ListenAddress :port # # Se non viene specificata alcuna porta, sshd ascolterà su questo indirizzo e # # su quello porta specificata nell'opzione Porta. Se # # utilizzerai ListenAddress senza specificare una porta, l'opzione # # Port deve precedere l'opzione ListenAddress. Se non # # specificato, per impostazione predefinita ascolta su tutti gli indirizzi # # locali. È possibile specificare più indirizzi. # # # ## IndirizzoFamiglia ############################################ # # # Specifica quale famiglia di indirizzi IP dovrebbe essere # # utilizzata da sshd. Opzioni possibili: # # “any” - any # # “inet” (solo IPv4) # # “inet6” (solo IPv6) # # Default - “any”. # IndirizzoFamiglia inet # # ## UsaDNS ########################################## # ######## # # # Specifica se sshd deve controllare il nome host e # # utilizzare quel nome host per verificare l'indirizzo IP inviato dal client rispetto # # ricevuto dal DNS. # # Il valore predefinito è "sì". # # # ############################################### ############# ############# Impostazioni di accesso utente ############## ####### ################################################## ### # # # Consentire/non consentire un utente è determinato dalle direttive # # DenyUsers, PermetteUsers, DenyGroups e EnableGroups. # # in questo caso il controllo procede dall'alto verso il basso lungo la catena: # # ## DenyUsers ## # # || # # ## ConsentiUtenti ## # # || # # ## NegaGruppi ## # # || # # ## Permetti Gruppi ## # # Sono accettati solo nomi di utenti e gruppi, gli identificatori numerici # # (UserID) non vengono riconosciuti. Corretta # # registrazione di più utenti/gruppi a turno, separati da # # spazi. Se scritto nella forma utente@host, allora # # l'utente e l'host vengono controllati separatamente, ciò consente # # di limitare l'accesso a determinati utenti da # # determinati host. Vale la pena ricordare che le direttive # # DenyUsers e EnableUsers prendono come parametro il nome # # dell'utente, mentre DenyGroups e EnableGroups prendono il nome # # del gruppo. Vedi PATTERNS in man ssh_config per ulteriori # # informazioni sui moduli per la registrazione dei nomi di utenti e gruppi. # # # ## Nega utenti ############################################ ### # # # Elenco degli UTENTI che NON POSSONO utilizzare sshd. # # Predefinito - non specificato = nessuno è bannato. Quelli. se # # viene specificato un utente qui, gli verrà negato l'accesso # # al server ssh. # # # ## Consenti utenti ############################################ ## # # # Elenco degli UTENTI che POSSONO utilizzare sshd, # # Per impostazione predefinita - non specificato = consentito a tutti. Quelli. se # # viene specificato almeno un utente, l'accesso ssh al server # # è disponibile solo per quell'utente. # # # ## DenyGroups ############################################ ## # # # Elenco dei GRUPPI che NON dovrebbero essere utilizzati da sshd. # # Predefinito - non specificato = nessun gruppo è proibito. # # Questo è se viene specificato almeno un gruppo, agli utenti # # inclusi in questo gruppo verrà negato l'accesso al server ssh # #. # # # ## ConsentiGruppi ############################################ # # # # Elenco dei GRUPPI che sshd PUÒ utilizzare. # # Predefinito - non specificato = consentito a tutti. Quelli. se # # viene specificato almeno un gruppo, solo gli utenti# # inclusi in esso potranno accedere al server ssh.# # # ################### # ################################################# ### Opzioni che determinano lo stato della connessione ############# ############################# ####### ######################### # # ## TCPKeepAlive ############# ######### ######################### # # # Indica se il sistema deve inviare messaggi TCP al client # # per mantenere la connessione. Se invii questi pacchetti, # # puoi determinare se la connessione è interrotta. Tuttavia, anche questo # # significa che la connessione potrebbe essere interrotta in caso di # # momentanea interruzione del routing e # # questo è molto fastidioso per alcuni. D'altra parte, se # # tali messaggi non vengono inviati, le sessioni sul server possono # # durare indefinitamente, creando utenti “fantasma” # # e divorando le risorse del server. Il valore predefinito è "sì",# # cioè inviare tali messaggi. Per disabilitare l'invio # # di tali messaggi, impostare il valore su "no". In precedenza questa opzione # # si chiamava KeepAlive. Vale la pena notare che # # esistono modi più sicuri per verificare lo stato di # # una connessione (vedi sotto). # # # TCPKeepAlive sì # # ## ClientAliveCountMax ###################################### # # # Imposta il numero di messaggi ai client che sshd # # invia di seguito senza ricevere alcuna risposta # # dal client. Se la soglia viene raggiunta e # # il client non risponde, sshd disconnetterà il client, terminando la # # sessione ssh. Vale la pena notare che l'uso di tali messaggi # # è completamente diverso dalla direttiva TCPKeepAlive. # # I messaggi da/verso i client vengono inviati su un canale # # crittografato e pertanto non sono soggetti a spoofing. I messaggi # # TCPKeepAlive sono soggetti a spoofing. Il meccanismo client attivo # # è particolarmente utile nei casi in cui il server e il client necessitano # # di sapere quando la connessione è diventata inattiva. Il valore # # predefinito è 3. Nel caso in cui ClientAliveInterval # # sia impostato su 15 e ClientAliveCountMax venga lasciato sul valore # # predefinito, i client che non rispondono verranno disconnessi dopo circa # # 45 secondi. Questa direttiva funziona solo per # # il protocollo ssh2. # # # ## ClientAliveInterval ######################################## # # # Imposta l'intervallo di tempo in secondi. Se non c'è comunicazione con il client durante # # questo intervallo, sshd # # invia un messaggio su un canale crittografato richiedendo # # una risposta dal client. Il valore predefinito è 0, ovvero # # non inviare messaggi di questo tipo. Questa direttiva funziona # # solo per il protocollo ssh2. # # # ############################################### ############# ################ Opzioni generali di autenticazione ################ ## ################################################## ######## # # ## AuthorizedKeysFile ##################################### # # # # Specifica un file che contiene le chiavi pubbliche # # utilizzate per autenticare gli utenti. La direttiva # # può contenere token del formato %M, che vengono inseriti durante il processo # # di creazione della connessione. # # Sono definiti i seguenti token: # # %% - sostituito con il letterale "%" # # %h - sostituito con la directory home # # dell'utente autenticato # # %u - sostituito con il nome dell'utente autenticato # # Pertanto, il file chiave può essere specificato come # # in modo assoluto (ovvero un file condiviso con chiavi) e # # dinamicamente, a seconda dell'utente (ovvero un file # # per ciascun utente). # # L'impostazione predefinita è ".ssh/authorized_keys". # # Esempio di un file di chiavi nella cartella home dell'utente: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Esempio di un file condiviso: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # Vedere la descrizione del file Authorized_keys per maggiori informazioni. # # # ## ChallengeResponseAuthentication ############################ # # # Specifica se consentire l'autenticazione challenge-response # # ). Sono supportati tutti i # # tipi di autenticazione da login.conf. Il valore predefinito è "sì", # # i.e. permettere. # # Su Ubuntu: disabilitato per motivi di sicurezza. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ######################### # # # Specifica come il server deve ottenere il nome host del client # # quando uno schema di autenticazione basato sulla verifica dell'host. # # Se impostato su "yes", sshd # # utilizzerà il nome host fornito dal client quando verifica una corrispondenza nei file # # ~/.shosts, ~/.rhosts o /etc/hosts.equiv. # # (eseguendo la risoluzione DNS inversa) Se impostato su "no"# # - sshd risolverà il nome dalla connessione TCP stessa. # # L'impostazione predefinita è "no". # # # ## IgnoreRhosts ############################################ # # # Impedisce l'uso dei file .rhosts e .shosts # # nell'autenticazione basata sull'host. # # (RhostsRSAAuthentication o HostbasedAuthentication). # # I file /etc/hosts.equiv e /etc/ssh/shosts.equiv sono ancora # # in uso. # # L'impostazione predefinita è "sì". # # # IgnoreRhosts sì # # ## IgnoreUserKnownHosts ##################################### # # # Indica se sshd deve ignorare l'utente # # file "host noti" ~/.ssh/known_hosts durante il # # processo di autenticazione basato sull'host # # (RhostsRSAAuthentication o HostbasedAuthentication). # # L'impostazione predefinita è "no". # # # ## PermitBlacklistedKeys ################################### # # # Indica se sshd deve essere accettato chiavi inserite nella lista nera # # come compromesse (chiavi # # note come compromesse (vedi ssh-vulnkey)). Se impostato su “sì” - # # i tentativi di autenticazione con tali chiavi verranno registrati # # e accettati, se impostato su “no” - # # i tentativi di autenticazione verranno rifiutati. # # L'impostazione predefinita è "no". # # # ## PermettiPasswordVuote ######################################## # # # In caso di autenticazione consentita con l'utilizzo di una password, # # indica se è possibile accedere con una password vuota. # # L'impostazione predefinita è "no". # # # PermitEmptyPasswords no # # ## PermitRootLogin ######################################## # # # # Indica se è possibile effettuare il login ssh come superutente # # (root). Può assumere i seguenti valori: # # “sì” - il superutente può accedere. Viene applicato lo # # schema di autenticazione globale corrente. # # # # “senza password” - il superutente può accedere. # # L'autenticazione della password verrà disabilitata. # # # # “solo comandi forzati” - il superutente potrà accedere utilizzando # # l'autenticazione basata su una chiave pubblica e # # solo se passa il comando richiesto per essere eseguito. # # Questo è utile per eseguire backup, # # anche quando il login normale (cioè non tramite ssh) # # è disabilitato. Tutti gli altri # # metodi di autenticazione per il superutente verranno bloccati.# # # # “no” - il superutente non può utilizzare ssh per # # accedere. # # # # Il valore predefinito è "sì". # # # PermitRootLogin sì # # ## Protocollo ######################################## ######## # # # Specifica quale protocollo sshd dovrebbe utilizzare. # # I possibili valori di '1' e '2' sono rispettivamente ssh1 e ssh2 # #. È possibile la scrittura simultanea, in questo caso # # i valori devono essere separati da virgole. # # L'impostazione predefinita è "2.1". # # Vale la pena notare che l'ordine dei protocolli nelle voci # # non determina la priorità, perché il client sceglie quale # # tra diversi protocolli proposti dal server # # utilizzare. La voce "2,1" è assolutamente identica # # alla voce "1,2". # # # Protocollo 2 # # ## UsaPAM ######################################## ########## # # # Abilita l'interfaccia PAM (Pluggable Authentication Module # # interfaccia). Se impostato su "sì", tutti i tipi di autenticazione # # oltre all'elaborazione del modulo sessione e account # # L'autenticazione PAM sarà utilizzato in base a # # challenge-response (ChallengeResponseAuthentication e # # PasswordAuthentication) Perché # # L'autenticazione challenge-response in PAM generalmente svolge lo stesso ruolo # # dell'autenticazione della password, è necessario disabilitare # # PasswordAuthentication o # # ChallengeResponseAuthentication. Vale la pena notare che # # se la direttiva UsePAM è abilitata, non sarà possibile eseguire # # sshd come utente diverso da root. # # Il valore predefinito è no". # # # UsePAM sì # # ## PasswordAuthentication ################################### # # # Indica se abilitato se l'autenticazione utilizzando # # password. # # L'impostazione predefinita è "sì". # # # ## Chiave host ############################################ ##### # # # Specifica il file contenente la chiave host privata # # utilizzata da SSH. Il valore predefinito è /etc/ssh/ssh_host_key # # per il protocollo ssh1 e /etc/ssh/ssh_host_rsa_key e # # /etc/ssh/ssh_host_dsa_key per il protocollo ssh2. È # # interessante notare che sshd non utilizzerà un file # # accessibile a chiunque non sia l'utente. Puoi # # utilizzare più file con chiavi, le chiavi sono “rsa1” - # # per il protocollo ssh1 e “dsa”/“rsa” per il protocollo ssh2. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # # ############################### ### ############################# ########## Opzioni del protocollo SSH versione 1 (ssh1) ### ########## ##################################### ### #################### # È FORTEMENTE SCONSIGLIATO utilizzare il protocollo ssh1.# # Il protocollo ssh2 è molto più sicuro di ssh1 # ### ######## ########################################## ####### # # ## Intervallo di rigenerazione chiave ################################# # # # Per Protocollo ssh1 - una volta a una certa ora # # viene generata automaticamente una nuova chiave temporanea del server # # (se ne è stata utilizzata una). Questo viene fatto per # # impedire che le sessioni intercettate vengano decrittografate per poter # # successivamente accedere alla macchina con i parametri di queste sessioni e # # rubare le chiavi. Tale chiave non è memorizzata da nessuna parte (è memorizzata nella # # RAM). Questa direttiva specifica la # # durata della chiave in secondi, dopodiché verrà # # generata nuovamente. Se il valore è impostato su 0 - # # la chiave non verrà generata nuovamente. # # Il valore predefinito è 3600 (secondi). # # # KeyReerationInterval 3600 # # ## RhostsRSAAuthentication ################################## # # # Indica se l'autenticazione basato su file # # rhosts o /etc/hosts.equiv insieme all'autenticazione host # # riuscita tramite RSA. # # Rilevante solo per il protocollo ssh1. # # L'impostazione predefinita è "no". # # # RhostsRSAAuthentication no # # ## RSAAuthentication ######################################## ## # # # Indica se è consentita l'autenticazione RSA "pura". # # Rilevante solo per il protocollo ssh1. # # L'impostazione predefinita è "sì". # # # Autenticazione RSAA sì # # ## ServerKeyBits ######################################## ### # # # Definisce il numero di bit nella chiave temporanea del server per # # il protocollo ssh1. Il valore minimo è 512. # # Il valore predefinito è 1024. # ServerKeyBits 768 # # ################################# # ############################ ############ Opzioni del protocollo SSH versione 2 (ssh2) ## ## ######## ######################################## ### ################### # # ## Cifratori ####################### ## ###################### # # # Indica gli algoritmi di crittografia consentiti per # # il protocollo ssh2. Più algoritmi devono essere # # separati da virgole. Algoritmi supportati: # # “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, # # “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “ arcfour128”, ## “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”. # # Per impostazione predefinita: # # aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, # # arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, # # aes192-ctr, aes256 -ctr # # # ## HostbasedAuthentication ################################### # # # Indica se l'autenticazione è abilitato, in base alla # # verifica dell'host. rhosts o /etc/hosts.equiv viene controllato, # # e, in caso di successo, combinato con un controllo riuscito # # della chiave pubblica, l'accesso è consentito. Questa direttiva # # è uguale alla direttiva RhostsRSAAuthentication e # # è adatta solo per il protocollo ssh2. # # L'impostazione predefinita è "no". # # # HostbasedAuthentication no # # ## MAC ######################################## ############ # # # Indica un algoritmo MAC valido (codice di autenticazione del messaggio # #). L'algoritmo MAC viene utilizzato # # dal protocollo ssh2 per proteggere l'integrità dei dati. Più algoritmi # # devono essere separati da virgole. # # Predefinito: # # hmac-md5,hmac-sha1, [e-mail protetta] ,hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication ########################## ########## # # # Indica se è consentita l'autenticazione basata sulla # # chiave pubblica. Rilevante solo per il protocollo ssh2. # # L'impostazione predefinita è "sì". # # # PubkeyAuthentication sì ############################################# # ################ #################### Opzioni GSSAPI ########### ## ############# ################################### ## ######################### # # ############ Applicabile solo per il protocollo ssh2 #### #### ### # # ## GSSAPIAuthentication ###################################### ## # # # Indica se l'autenticazione dell'utente # # è basata o meno su GSSAPI. L'impostazione predefinita è "no", ovvero proibito. # # # ## GSSAPIKeyExchange ######################################### # # # Indica se è consentito lo scambio di chiavi basato su # # GSSAPI. Lo scambio di chiavi tramite GSSAPI non si basa sulle # # chiavi ssh per verificare l'identità dell'host. # # Il valore predefinito è "no" - i.e. lo scambio è vietato. # # # ## GSSAPICleanupCredentials ################################ # # # Specifica se distruggere automaticamente # # la cache dell'utente di credenziali di autenticazione al termine della # # sessione. # # L'impostazione predefinita è "sì" - ad es. deve essere distrutto. # # # ## GSSAPIStrictAcceptorCheck ################################ # # # Specifica quanto deve essere rigoroso il controllo dell'identità # # client durante l'autenticazione tramite GSSAPI. # # Un valore "yes" fa sì che il client effettui l'autenticazione al # # servizio host ricevente sull'host corrente. Il valore "no" # # consente al client di autenticarsi utilizzando qualsiasi chiave di servizio # #. # # L'impostazione predefinita è "sì". # # Vale la pena notare che impostandolo su "no" potrebbe # # funzionare solo con rare librerie GSSAPI Kerberos. # # # ############################################### ############# ################### Opzioni Kerberos ################ ########## ######################################## ### ################### # # ## Autenticazione Kerberos ####################### ### ######## # # # Indica se la password # # fornita dall'utente per l'autenticazione # # (PasswordAuthentication) richiede la convalida nel KDC Kerberos. # # Per utilizzare questa opzione, il server deve # # verificare che il KDC sia vero. (Il server necessita di un # # servtab Kerberos che consenta la verifica dell'identità # # del KDC) # # Il valore predefinito è "no". # # # ## KerberosGetAFSToken ######################################### # # # Se AFS è attivo e l'utente ha ricevuto un TGT Kerberos 5, # # se tentare di ottenere un token AFS prima che l'utente # # possa accedere alla propria cartella home. # # L'impostazione predefinita è "no". # # # ## KerberosOrLocalPasswd ################################### # # # Indica cosa fare nel caso di se l'autenticazione # # tramite Kerberos fallisce. Se # # value = "yes", la password verrà verificata utilizzando # # qualsiasi meccanismo di autorizzazione locale aggiuntivo, # # ad esempio /etc/passwd. # # L'impostazione predefinita è "sì". # # # ## KerberosTicketCleanup ################################### # # # Indica se terminare automaticamente il file con # # cache dei ticket utente alla fine della sessione. # # L'impostazione predefinita è "sì". # # # ############################################### ############# ################# Opzioni di reindirizzamento ################## # ## ############################################### ## ############# # # ## Consenti inoltro agente ############################## #### ### # # # Indica se consentire o disabilitare il reindirizzamento # # ssh-agent. Il valore predefinito è "sì", ovvero consenti. # # Vale la pena notare che disabilitare il reindirizzamento non # # aumenterà la sicurezza finché gli utenti inoltre # # verrà negato l'accesso alla shell, poiché possono sempre installare # # i propri agenti analoghi. # # # ## Permetti TcpForwarding ###################### # ############### # # # Indica se abilitare o disabilitare il reindirizzamento TCP. # # Il valore predefinito è "sì", ovvero consenti. Vale la pena notare che # # che entrambi nella Nel caso di EnableAgentForwarding, disabilitare # # il reindirizzamento non aumenterà la sicurezza finché # # gli utenti avranno accesso alla console, perché potranno # # installare le loro controparti. # # # # # ## GatewayPorts ######### ## ################################# # # # Specifica se consentire agli host remoti l'accesso alle # # porte inoltrate. Per impostazione predefinita, sshd ascolta # # le connessioni alle porte inoltrate solo sull'interfaccia di loopback # # locale. Ciò impedisce ad altri # # host remoti di connettersi alle porte inoltrate. È possibile # # utilizzare GatewayPorts per consentire a sshd di # # eseguire questa operazione. La direttiva può assumere 3 valori: # # "no" - solo loopback. # # "sì" - qualsiasi indirizzo. # # "clientspecified" - indirizzi specificati dal client. # # # ## PermitOpen ############################################ ### ## # # # Indica dove è consentito il port forwarding TCP. # # La specifica di un reindirizzamento deve assumere una delle # # seguenti forme: # # PermitOpen host:porta # # PermitOpen IPv4_addr:porta # # PermitOpen:porta # # È possibile specificare più voci separandole con spazi. # # L'argomento “qualsiasi” può essere utilizzato per rimuovere tutte le # # restrizioni sul port forwarding. Per impostazione predefinita, è consentito qualsiasi # # reindirizzamento. # # # ## PermitTunnel ############################################ # # # Indica se è consentito il reindirizzamento dei dispositivi tun. # # Può assumere i valori: # # “yes” # # “point-to-point” (3° livello di rete) # # “ethernet” (2° livello di rete) # # “no” # # Il valore “yes” consente sia “point -to-point” # # e “ethernet” contemporaneamente. L'impostazione predefinita è "no". # # # ############################################### ############# ################## Opzioni di registrazione ################# ### ############################################### ## ############# # # ## SyslogFacility ############################## ## ########## # # # Imposta il codice dell'oggetto log per scrivere messaggi su # # syslog da sshd. Valori possibili: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # Il valore predefinito è AUTH. # # # SyslogFacility AUTH # # ## LogLevel ######################################## ######## # # # Imposta il livello di dettaglio del registro sshd. # # Opzioni possibili: # # SILENZIOSO # # SILENZIOSO # # FATALE # # ERRORE # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # L'impostazione predefinita è INFO. # # DEBUG e DEBUG1 sono equivalenti tra loro. # # DEBUG2 e DEBUG3 impostano i livelli più alti di debug # # output. La registrazione a livello DEBUG minaccia # # la privacy dell'utente e non è consigliata. # # # INFO livello registro # # ########################################### ################# ################### Reindirizzamento X11 ############ ######## ########################################## # ################### # # ## Inoltro X11 ######################### ### ################ # # # Indica se il sottosistema grafico X11 # # è abilitato. Può assumere i valori “sì” o “no”. # # L'impostazione predefinita è "no". # # Attenzione: abilitare il semplice reindirizzamento X11 è # # un grosso rischio sia per il server che per i client, perché In # # tale reindirizzamento, il display proxy sshd # # accetta connessioni da qualsiasi indirizzo. Utilizzare # # la direttiva X11UseLocalhost per limitare l'accesso al # # server di reindirizzamento di X. Vale la pena notare che # # disabilitare il reindirizzamento non garantirà che # # gli utenti non saranno in grado di reindirizzare X11, perché avendo # # accesso alla console installano sempre il proprio # # reindirizzamento. Il reindirizzamento X11 verrà # # automaticamente disabilitato se la direttiva UseLogin # # è abilitata. # # # X11Inoltro sì # # ## X11UseLocalhost ######################################## # # # # Indica se sshd deve limitare l'ambito dell'inoltro # # X11 a un indirizzo di loopback locale o # # deve consentire qualsiasi indirizzo. Per impostazione predefinita, sshd # # imposta il server di reindirizzamento X11 su un indirizzo locale # # e imposta la parte del nome host della variabile di ambiente DISPLAY # # su "localhost". Vale la pena notare che # # alcuni client X11 meno recenti potrebbero non funzionare con queste # # impostazioni. L'impostazione predefinita è "sì", ovvero il reindirizzamento # # è limitato dal localhost, il valore - “no” - disabilita # # le restrizioni. # # # ## XAuthLocation ############################################ # # # Specifica il percorso completo del programma xauth. # # Il valore predefinito è /usr/bin/X11/xauth. # # # ## X11DisplayOffset ######################################### # # # Indica il numero del primo display disponibile per sshd come reindirizzamento # # X11. Questo viene fatto in modo # # che le X reindirizzate non si sovrappongano a quelle # # reali. Il valore predefinito è 10. # # # X11DisplayOffset 10 # # ####################################### ## ###################### ################### Varie opzioni ##### ## ################### ############################# ##### ############################ # # ## LoginGraceTime ############ ####### ######################### # # # Tempo dopo il quale il server disconnette # # l'utente se non è riuscito a farlo accedi # # in modo soddisfacente. Valore 0: consente all'utente # # di accedere a tempo indeterminato. L'impostazione predefinita è 120 (secondi). # # # LoginGraceTime 120 # # ## MaxAuthTries ######################################## ### #### # # # Indica il numero massimo di tentativi di autenticazione # # consentiti per connessione. # # Una volta che il numero di tentativi falliti supera la metà del valore # # specificato, tutti i tentativi successivi verranno # # registrati. Il valore predefinito è 6. # # # ## MaxSessions ###################################### ####### # # # Specifica il numero massimo di connessioni simultanee # # per ciascuna connessione di rete. Il valore predefinito è 10. # # # ## MaxStartups ######################################## ###### # # # Specifica il numero massimo di connessioni simultanee # # non autorizzate a sshd. Se # # il numero di connessioni supera il limite, tutte le connessioni aggiuntive # # verranno interrotte fino al completamento delle connessioni # # attuali con autorizzazione riuscita # # o fino alla scadenza del periodo di tempo specificato nella direttiva # # LoginGraceTime. Il valore predefinito è 10. # # Facoltativamente, è possibile impostare le connessioni per il ripristino anticipato # # specificando tre valori come parametro, separati # # da due punti "start:rate:full" (ad esempio: "10:30 :60"). # # sshd rifiuterà un tentativo di connessione con una probabilità pari a # # “rate/100” (i.e. nel nostro esempio - 30%) se ci sono già # # “start” (10) connessioni non autorizzate. # # La probabilità aumenta linearmente e qualsiasi # # tentativo di connessione verrà rifiutato se il numero di connessioni # # non autorizzate raggiunge il “pieno” (60). # # # ## Compressione ############################################ # # # # Indica se la compressione dei dati è abilitata. Può essere # # "sì" - la compressione è abilitata. # # "ritardato" - la compressione viene ritardata finché # # l'utente non viene autenticato con successo. # # "no" - la compressione è disabilitata. # # L'impostazione predefinita è "ritardato". # # # ## UsaAccedi ############################################ #### # # # Indica se il login deve essere utilizzato per una # # sessione interattiva. Il valore predefinito è no". # # Vale la pena notare che il login non è mai stato utilizzato per # # eseguire comandi remoti. Tieni inoltre presente che # # l'utilizzo di login renderà impossibile l'utilizzo # # della direttiva X11Forwarding, poiché login non sa cosa # # fare con xauth. Se la direttiva # # UsePrivilegeSeparation è abilitata, verrà disabilitata dopo # # autorizzazione. # # # ## UsePrivilegeSeparation ###################################### # # # Specifica se sshd dovrebbero separare i privilegi. Se sì # # allora verrà creato prima un processo figlio non privilegiato # # per il traffico di rete in entrata. Dopo aver ottenuto con successo l'autorizzazione # #, verrà creato un altro processo con i privilegi # # dell'utente registrato. Lo scopo principale della # # separazione dei privilegi è prevenire l'abuso dei diritti di accesso. # # Il valore predefinito è "sì". # # # UsaPrivilegeSeparation sì # # ## StrictModes ######################################## ### ##### # # # Indica se sshd deve controllare le modalità di accesso e # # di proprietà delle cartelle e dei file dell'utente prima # # di consentire all'utente di effettuare il login. Questo di solito è dovuto al fatto che # # i principianti spesso rendono i propri file scrivibili # # da chiunque. L'impostazione predefinita è "sì". # # # StrictModes sì # # ## AcceptEnv ######################################## ####### # # # Specifica quali variabili d'ambiente passate # # dal client verranno accettate. Vedi l'opzione SendEnv nel client. # # Vale la pena notare che il passaggio di variabili è possibile solo # # per il protocollo ssh2. Le variabili sono specificate per nome, # # possono essere usate maschere ('*' e '?'). È possibile specificare # # più variabili separate da spazi o dividere AcceptEnv in # # più righe. Fai attenzione: alcune # # variabili d'ambiente possono essere utilizzate per aggirare # # gli ambienti utente proibiti. Utilizzare questa # # direttiva con attenzione. Per impostazione predefinita, non sono accettate # # variabili di ambiente utente. # # # AcceptEnv LANG LC_* # # ## PermitUserEnvironment ################################### # # # Specifica se sshd deve accettare # # ~/.ssh/environment e l'opzione Environment= in # # ~/.ssh/authorized_keys. L'impostazione predefinita è "no". È # # interessante notare che abilitare l'elaborazione dell'ambiente può dare # # agli utenti la possibilità di aggirare le restrizioni in alcune # # configurazioni che utilizzano meccanismi come # # LD_PRELOAD. # # # # # ## PidFile ########################################## # ####### # # # Specifica un file contenente l'ID processo # # (ID processo, PID) del demone SSH. # # Predefinito - /var/run/sshd.pid # # # # # ## StampaUltimoLog ############################# # ############## # # # Specifica se sshd deve visualizzare la data e l'ora # # dell'ultima sessione quando l'utente accede in modo interattivo. # # L'impostazione predefinita è "sì". # # # PrintLastLog sì # # ## PrintMotd ######################################## ####### # # # Specifica se sshd deve visualizzare /etc/motd # # quando un utente accede in modo interattivo. Su alcuni # # sistemi (ad esempio Ubuntu) queste informazioni vengono # # visualizzate anche dalla shell. # # Il valore predefinito è "sì". # # # PrintMotd no # # ## Banner ######################################## ########## # # # Indica quale file contiene un banner di testo che # # verrà mostrato all'utente PRIMA della # # procedura di autenticazione. L'opzione è disponibile solo per il protocollo ssh2.# # Per impostazione predefinita - non mostra nulla. # # Su Ubuntu, il file issue.net contiene la frase Ubuntu (versione), # # ad esempio, per karmic è "Ubuntu 9.10". Può # # essere utilizzato per disorientare possibili aggressori, # # scrivendo lì, ad esempio, "Il mio router Internet D-Link" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ###### ##### ############################### # # # Se specificato, fornisce il percorso per # # essere sottoposto a chroot dopo l'autenticazione. Il percorso e tutto il suo # # contenuto devono corrispondere alle cartelle # # di proprietà del superutente e non essere # # scrivibili da altri utenti. # # Il percorso può contenere etichette che vengono sostituite durante il # # processo di autenticazione: # # %% - sostituito con il valore letterale "%" # # %h - sostituito con la directory home # # dell'utente autenticato # # %u - sostituito con il nome dell'utente autenticato # # chroot -la cartella dovrebbe contenere tutti i file e le # # cartelle necessari per la sessione dell'utente. Una sessione # # interattiva richiede come minimo: # # una shell, solitamente sh # # dispositivi di base in /dev come: # # null, zero, stdin, stdout, stderr, arandom e tty # # per una sessione di trasferimento dati utilizzando sftp no # # sono necessarie impostazioni aggiuntive se viene utilizzato il processo del server # # sftp interno. Vedi Sottosistema per # # ulteriori informazioni. Per impostazione predefinita, chroot non viene eseguito. # # # ## Comando forzato ############################################ # # # Causa l'esecuzione del comando specificato. Ignora # # qualsiasi comando inviato dal client o scritto su # # ~/.ssh/rc. Il comando viene chiamato dalla # # shell dell'utente con l'opzione -c. Adatto per lanciare una shell, # # un comando o un sottosistema. Molto utile all'interno di un blocco # # Match. Il comando originariamente emesso dal client è archiviato # # nella variabile di ambiente SSH_ORIGINAL_COMMAND. Se # # specifichi il comando "internal-sftp", verrà avviato # # il server sftp interno, che non necessita dei file e delle cartelle # # aggiuntivi descritti nella direttiva ChrootDirectory. # # # ## Sottosistema ############################################ ### # # # Definisce e configura un sottosistema esterno (ad esempio # # demone di trasferimento file). # # Gli argomenti sono il nome e il comando (con possibili # # argomenti) che verrà eseguito quando si richiederanno # # i sottosistemi. Il comando sftp-server avvia il sottosistema di trasferimento file "sftp" - # #. Inoltre, puoi specificare # # “internal-sftp” come sottosistema, che avvierà # # il server sftp interno. Ciò può semplificare notevolmente la configurazione # # quando si utilizza la direttiva # # ChrootDirectory. Per impostazione predefinita, non viene chiamato alcun sottosistema # #. Rilevante solo per il protocollo ssh2. # # # Sottosistema sftp /usr/lib/openssh/sftp-server # # ################################# ############################ ##################### Incontro Blocca ############################ ##################### ## ##################################### # # # L'ho spostato appositamente alla fine di il file per renderlo più conveniente # # scrivi le regole di corrispondenza. # # MadKox. # # # # La direttiva Match rappresenta l'inizio di un blocco # # condizionale. Se tutti i criteri specificati nella riga # # Match vengono soddisfatti, vengono eseguite le direttive sulle righe successive del blocco, # # consentendo di ignorare i valori delle direttive globali nel file # # sshd_config nel caso in cui sia criteri per la direttiva # # Match. Per blocco si intendono tutte le righe che seguono la riga # # con il criterio (Corrispondenza - righe) fino alla riga di corrispondenza successiva # # o alla fine del file. L'argomento della direttiva Match è una o # # più coppie di criteri. Possibili tipi di voci: # # Utente # # Gruppo # # Host # # Indirizzo # # Le voci possono contenere valori singoli # # (ad esempio Utente=utente) o più valori # # separati da virgole (Utente=utente1 ,utente2). È possibile utilizzare anche le espressioni regolari descritte nella sezione # # PATTERNS del file ssh_config # #. Le voci nei criteri # # Indirizzo possono contenere indirizzi nella notazione CIDR # # (Lunghezza indirizzo/maschera, ad esempio "192.0.2.0/24" o # # "3ffe:ffff::/32"). Vale la pena notare che la lunghezza della maschera # # fornita deve corrispondere all'indirizzo e che un valore troppo # # lungo/corto per l'indirizzo non funzionerà. # # Match può utilizzare solo # # un insieme specifico di direttive come direttive: # # PermetteTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAuthentication # # MaxAuthTries # # MaxSessions # # PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #

    Puoi copiare il testo sopra nel tuo sshd_config e usarlo in seguito per la configurazione.

    Di per sé, un server SSH configurato in modo errato rappresenta un'enorme vulnerabilità nella sicurezza del sistema, poiché un possibile aggressore ha l'opportunità di ottenere un accesso quasi illimitato al sistema. Inoltre, sshd ha molte opzioni utili aggiuntive che è consigliabile abilitare per migliorare l'usabilità e la sicurezza.

    Porta, ListenAddress e AddressFamily

    Questi tre parametri determinano su quali porte e indirizzi il tuo server ascolterà le connessioni in entrata. Innanzitutto è opportuno limitare, se possibile, la famiglia di indirizzi elaborati a quelli effettivamente utilizzati, ovvero se si utilizza solo IPv4 disattivare IPv6 e viceversa. Questo può essere fatto utilizzando il parametro AddressFamily, ad esempio (per consentire IPv4 e negare IPv6):

    IndirizzoFamiglia inet

    In secondo luogo, è consigliabile cambiare la porta standard (22) su cui è in ascolto sshd. Ciò è dovuto al fatto che numerosi scanner di rete tentano costantemente di connettersi alla porta 22 e almeno di ottenere l'accesso forzando login/password dal loro database. Anche se l'autenticazione della password è disabilitata, questi tentativi intasano pesantemente i log e (in grandi quantità) possono influire negativamente sulla velocità del server ssh. Se per qualche motivo non vuoi cambiare la porta standard, puoi utilizzare varie utilità esterne per combattere i brute forcer, ad esempio fail2ban, e quelle integrate, come MaxStartups.
    È possibile impostare la porta come valore assoluto per tutte le interfacce utilizzando la direttiva Port oppure come valore specifico per ciascuna interfaccia utilizzando la direttiva ListenAddress. Per esempio:

    Porto 2002

    AscoltaIndirizzo 192.168.0.1:2003 AscoltaIndirizzo 192.168.1.1:2004

    Nega l'accesso remoto al superutente

    Per impostazione predefinita, l'accesso root è proibito tramite password (tramite chiave è possibile): l'opzione PermitRootLogin è impostata su without-password . Ma, dato che per impostazione predefinita in Ubuntu l'utente aggiunto durante l'installazione del sistema ha la capacità di risolvere tutte le attività amministrative tramite sudo, creare la possibilità di accesso root al sistema tramite ssh sembra irragionevole (anche con l'autenticazione tramite chiave). Si consiglia di spegnerlo completamente. questa opzione oppure utilizzala solo in modalità solo comandi forzati. Puoi disabilitare l'accesso root in questo modo:

    PermitRootLogin n

    Autenticazione della password

    L'autenticazione tramite password, consentita per impostazione predefinita, è praticamente il metodo di autorizzazione più primitivo in sshd. Da un lato ciò semplifica la configurazione e la connessione di nuovi utenti (l'utente deve solo conoscere il login/password del suo sistema), dall'altro la password può sempre essere indovinata e gli utenti spesso trascurano di creare password complesse e lunghe . Bot speciali scansionano costantemente i server ssh accessibili da Internet e tentano di accedervi forzando brutalmente accessi/password dal loro database. Si consiglia vivamente di non utilizzare l'autenticazione tramite password. Puoi disabilitarlo in questo modo:

    Autenticazione password n

    Se per qualche motivo desideri comunque utilizzare l'autenticazione tramite password, assicurati che nessuno possa accedere con una password vuota. Per fare ciò, imposta la direttiva PermitEmptyPasswords:

    PermitEmptyPassword n

    Protocolli SSH1 e SSH2

    Come già accennato, sshd può funzionare con i protocolli SSH1 e SSH2. Tuttavia, l'utilizzo di SSH1 non sicuro è altamente sconsigliato. Puoi forzare sshd a funzionare solo con il protocollo SSH2 in questo modo:

    Autenticazione basata su chiavi RSA SSH2

    Il metodo di autorizzazione preferito è l'autenticazione basata su chiavi RSA SSH2. Con questo metodo l'utente genera al suo interno una coppia di chiavi, di cui una chiave è segreta e l'altra pubblica. La chiave pubblica viene copiata sul server e viene utilizzata per verificare l'identità dell'utente. Per ulteriori informazioni sulla creazione di una coppia di chiavi e su come posizionarle sul server, vedere la descrizione del client SSH. Puoi abilitare l'autenticazione con chiave pubblica in questo modo:

    Autenticazione Pubkey sì

    Il server deve sapere dove cercare la chiave pubblica dell'utente. A questo scopo viene utilizzato un file specialeauthorized_keys. La sua sintassi potrebbe essere la seguente:

    # I commenti vengono scritti solo su una nuova riga # Aspetto generale delle voci nel file authentic_keys # [opzioni] key_type (ssh-rsa o ssh-dss) very_long_string_incomprensibile all'uomo comune [login@host] ssh-rsa AAAAB3Nza...LiPk == [e-mail protetta] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [e-mail protetta] comando="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== esempio.net consentopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh -dss AAAAB5...21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [e-mail protetta]

    È possibile specificare un file condiviso con chiavi oppure un file per ciascun utente. Quest’ultimo metodo è più comodo e sicuro perché, in primo luogo, è possibile specificare diverse combinazioni di tasti per ciascun utente e, in secondo luogo, limitare l’accesso alla chiave pubblica dell’utente. È possibile specificare un file con chiavi utilizzando la direttiva AuthorizedKeysFile:

    File di chiavi autorizzate %h/.ssh/my_keys

    per lo schema utente - file
    O

    FileAuthorizedKeys /etc/ssh/authorized_keys

    per uno schema con un file condiviso. Per impostazione predefinita, il client SSH cerca le chiavi nel file ~/.ssh/authorized_keys.

    Maggiori informazioni sulla sicurezza

    Altre impostazioni

    Utenti e gruppi.

    Se hai molti utenti che "vivono" sul tuo server e vuoi consentire l'accesso tramite ssh solo ad alcuni di essi, puoi utilizzare le direttive DenyUsers, EnableUsers, DenyGroups e EnableGroups. Per ulteriori informazioni su queste direttive, vedere i commenti nell'esempio sshd_config.

    Opzioni dello stato della connessione

    Per impostazione predefinita, tra i metodi per determinare lo stato della connessione, è abilitato solo il metodo di controllo della connessione TCP: TCPKeepAlive, tuttavia, sshd può determinare gli stati della connessione in modi più convenienti e sicuri. Consulta la sezione corrispondente nell'esempio sshd_config per maggiori dettagli.

    Prestazione. MaxStartups

    Port forwarding

    Reindirizzamento X11

    Sul server, nel file /etc/ssh/sshd_config, impostare il parametro (abilitato per impostazione predefinita):

    AvantiX11 sì

    Sul client, impostare i parametri nel file /etc/ssh/ssh_config (disabilitato per impostazione predefinita):

    ForwardAgent sì ForwardX11 sì

    Puoi eseguirlo sul client in questo modo: ssh yurauname@serverip firefox . Oppure vai prima su ssh yurauname@serverip e poi esegui, ad esempio, sudo synaptic .

    SFTP

    sshd ha un server SFTP integrato per impostazione predefinita. SFTP (SSH File Transfer Protocol) - Protocollo SSH per il trasferimento di file. È progettato per copiare ed eseguire altre operazioni sui file tramite una connessione affidabile e sicura. Come protocollo base per la connessione viene utilizzato di norma il protocollo SSH2. Per abilitare il supporto SFTP, aggiungi la riga a sshd_config

    Sottosistema sftp /usr/lib/openssh/sftp-server

    Per impostazione predefinita, il supporto SFTP è abilitato.

    Utilizzando criteri. Direttiva sulle partite

    Configurazione di un client SSH

    L'accesso tramite chiave è considerato il più sicuro e nella maggior parte dei casi questa funzionalità è abilitata sul lato server, quindi non sono richiesti diritti di superutente per utilizzarla. Sul computer client generiamo una chiave:

    ssh-keygen -t rsa

    Ci viene richiesto di inserire una password per proteggere il file chiave (risulta utile se il file cade nelle mani sbagliate). Se eseguiremo script tramite SSH, lo lasceremo vuoto. Trasferiamo la chiave pubblica al server con il comando

    Ssh-copy-id -i ~/ .ssh/ id_rsa.pub utente@ server

    Ecco, puoi entrare.

    Quando ssh è in esecuzione su una porta non standard:

    Ssh-copy-id -i ~/ .ssh/ id_rsa.pub "-p porta utente@server"

    Se si verifica un errore: Porta errata "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"

    prova a mettere i parametri tra virgolette:

    ID-copia-ssh "-i /home/utente/.ssh/id_rsa.pub "-p porta utente@server""

    È conveniente utilizzare l'utilità dello schermo quando ci si connette a un sistema remoto.

    Configurazione di una directory ssh remota in Nautilus

    Montaggio di una directory remota utilizzando sshfs

    Montaggio di una directory remota in una directory locale

    sshfs utente@ hostingserver.ru:/ home/ userdir ~/ sshfsdir

    Smontaggio

    Fusermount -u ~/ sshsfdir

    Alias ​​SSH

    Quando si utilizzano più server con parametri di accesso diversi (porta non standard, nome host lungo, login diverso da quello locale, ecc.), a volte è noioso inserire nuovamente tutte le impostazioni di connessione ogni volta. Per renderlo più semplice, puoi usare gli alias.

    Le impostazioni sono archiviate in ~/.ssh/config per un singolo utente e in /etc/ssh/ssh_config globalmente per tutti gli utenti.

    Configurazione di esempio. Possono essere descritti più server. Maggiori dettagli in uomo ssh_config(da non confondere con sshd_config)

    Host AliasName # Nome host arbitrario HostName 1.2.3.4 # È possibile specificare sia l'IP che il nome host (se DNS è in esecuzione) Utente YourUserName # Se l'utente non corrisponde all'utente locale Porta YourSSHPort # Se una porta non standard

    Dopodiché puoi connetterti al server con il comando

    ssh AliasName

    ssh-agente

    Diagnosi dei problemi di connessione

      Analisi del registro delle connessioni:

    ssh -vvv utente@host

      Analisi dei file di configurazione client e server.

    La posizione dei file di configurazione può essere trovata in

    Amico ssh amico sshd

    Utilizzando le smart card

    1. La creazione di un certificato e l'esportazione di una chiave pubblica, nonché la parte client su Windows + Putty SC, sono descritte sul sito Web: http://habrahabr.ru/post/88540/ Il componente aggiuntivo Key Manager descritto è disponibile solo nelle versioni precedenti di Firefox. Testato sulla versione 3.5 per Windows. Collegamento diretto al componente aggiuntivo: https://addons.mozilla.org/ru/firefox/addon/key-manager/

    2. Preparazione del server. Devi assicurarti che la tua configurazione sshd consenta l'autenticazione utilizzando le chiavi pubbliche. Per fare ciò, è necessario specificare il valore del parametro "PubkeyAuthentication" su "sì" nel file "sshd_config". Quindi aggiungiamo la nostra chiave pubblica ottenuta in precedenza (in una riga) al file “~/.ssh/authorized_keys”. Si tenga presente che il file “.ssh/authorized_keys” si trova nella directory home dell'utente che poi accederà utilizzando la chiave pubblica.

    3. Parte client su Linux. Dovrai ricostruire il pacchetto OpenSSH senza parametri. Si consiglia di specificare solo i prefissi di directory, ad esempio –prefix=/usr. Dovresti anche notare che i file di configurazione si troveranno in /usr/etc. Prima di iniziare, sono necessari i seguenti pacchetti: opensc-lite-devel, zlib-devel, openssl-devel. Installare il driver della smart card. Per comodità, nella configurazione ssh_config (da non confondere con sshd_config), specificare il percorso della libreria pkcs: PKCS11Provider=<путь к библиотеке>

    4. Sul client, eseguire ssh user@host. Se la smart card (token) è connessa, ti verrà richiesta una password e verrà effettuato l'accesso alla sessione SSH.

    Possibili problemi durante l'uso

    La solita combinazione di tasti Ctrl + S, utilizzata in molti editor per salvare le correzioni, quando si lavora in un terminale con un server ssh, porterà all'esecuzione del comando XOFF, che assomiglia superficialmente al blocco della sessione. Tuttavia non lo è. Il server continua ad accettare caratteri e comandi immessi, ma non li visualizza sullo schermo. Per uscire da questa situazione è sufficiente utilizzare la combinazione Ctrl + Q, riattivando così la modalità XON.

    Collegamenti

    Cioè, l'utente1 può essere registrato sia per se stesso - nel file /home/user1/.ssh/keys) sia per un altro utente, il che gli consentirà di accedere dal suo computer sia "sotto se stesso" che sotto "un altro"

    SSH (Secure Shell) è un protocollo di rete progettato per la gestione di server remoti e il trasferimento di dati su connessioni crittografate TCP. La maggior parte dei servizi di hosting, anche quelli virtuali, oggi forniscono l'accesso sia tramite FTP che SSH. Secondo me è fantastico, SSH è molto più comodo e sicuro da usare.

    Configurazione di SSH

    Il setup avverrà per un server dedicato, VDS, VPS su Debian, Ubuntu. Il file di configurazione si trova qui: /etc/ssh/sshd_config.
    Se hai un hosting regolare, tutto dovrebbe essere configurato come dovrebbe, vai alla sezione.

    Per impostazione predefinita, il demone SSHD (che è ciò a cui stiamo apportando modifiche) non necessita di alcuna impostazione e funziona correttamente. Faremo solo un paio di piccole modifiche per limitare l'accesso di persone indesiderate al server.

    A seguito di modifiche errate al file di configurazione, potresti perdere l'accesso al server tramite ssh, quindi assicurati di avere opzioni alternative per accedervi, ad esempio utilizzando il pannello di controllo di ISPManager.

    Come limitare l'accesso SSH

    Tutte le modifiche vengono apportate a /etc/ssh/sshd_config
    Affinché le modifiche abbiano effetto, è necessario

    Cambia porto

    Porta 9724

    Ora, al momento dell'autorizzazione, è necessario specificare 9724 invece della porta 22 standard.
    Il metodo è molto semplice ed efficace contro i bot hacker più semplici che bussano alle porte standard. La cosa principale qui è non creare un conflitto con altri servizi e scegliere un numero che ovviamente non è utilizzato.

    Disabilita la comunicazione utilizzando il vecchio protocollo

    Qui definiamo che la comunicazione è possibile solo utilizzando il protocollo v2

    Se non hai effettuato l'accesso radice, prima di tutti i comandi della console devi aggiungere sudo - sta per Sostituisci Utente e DO- sostituire l'utente e fare (sotto di lui). Ad esempio, ti consente di eseguire comandi come superutente radice.

    Ridurre il numero di tentativi di autorizzazione

    MaxAuthTries 2

    Numero di tentativi di password. Il valore predefinito è 6. Se la ricerca fallisce, la sessione di comunicazione viene terminata.

    Riduci i tempi di attesa dell'autorizzazione

    LoginGraceTime 30s

    Per impostazione predefinita, una sessione di autorizzazione può durare 120 secondi. Trascorso questo tempo finisce. 2 minuti per l'autorizzazione sono eccessivi; per tutto questo tempo il server mantiene aperta la connessione, il che è molto irrazionale. È sufficiente mezzo minuto.

    Chiudi l'accesso IP

    Prima di impostare le restrizioni IP, assicurati che in caso di errore nelle impostazioni e conseguente ban del tuo IP, avrai un modo alternativo per riottenere l'accesso al server

    Se solo hai bisogno dell'accesso, il modo più semplice e affidabile è bloccare l'accesso da qualsiasi luogo tranne che dal tuo IP o, se è dinamico, dall'intervallo IP.

    1. Apri /etc/hosts.allow e aggiungi SSHD lì: 192.168.1.1

      dove 192.168.1.1 è il tuo IP. Se disponi di un IP dinamico, definisci un IP con una maschera di sottorete e scrivi la tua sottorete invece dell'IP, ad esempio:

      SSHD: 192.168.0.0/16

    2. Apri /etc/hosts.deny e aggiungi lì: SSHD: ALL

    Un altro modo per limitare l'accesso tramite IP

    È possibile utilizzare la seguente direttiva:

    ConsentiUtenti = *@1.2.3.4

    Qui consentiamo solo l'accesso per IP 1.2.3.4

    Autorizzazione SSH tramite chiavi

    Sarà molto più sicuro, conveniente e corretto impostare l'autorizzazione ssh senza password. A questo scopo verrà utilizzata l'autorizzazione chiave.

    Quindi ecco le istruzioni.

    Hai acquistato subito il tuo primo VPS, o forse anche un server. Sicuramente hai un pannello web per amministrarlo. Ma gli amministratori rigidi passano sempre attraverso la console 😉 Pertanto, dobbiamo imparare come farlo. In questa lezione installeremo il programma PuTTY, ci collegheremo al server tramite il protocollo SSH e impareremo come determinare lo spazio occupato e libero sul server.

    Programma Putty per la connessione a un server tramite protocollo SSH

    Scarica Putty dal sito putty.org Per quanto mi riguarda, scarico la versione "Per Windows su Intel x86 - PuTTY: putty.exe"

    Decomprimi l'archivio e avvia il programma.

    Ecco come appare la finestra del programma dopo il lancio. Ho già inserito l'indirizzo IP del mio server nel campo “Nome host (o indirizzo IP)”:

    Inserisci il dominio o l'indirizzo IP del tuo server e fai clic sul pulsante "Apri". Si apre una finestra del prompt dei comandi. Ci chiede un nome utente e una password. Per prima cosa inserisci il tuo login, poi la tua password. Attenzione, quando si inserisce la password, i caratteri non vengono stampati sullo schermo, non vengono stampati nemmeno gli asterischi ***. Pertanto, inseriamo la password come alla cieca. Invio e premere Invio. Se la password è stata inserita correttamente, accederai alla console di gestione del server. Viene visualizzata una riga con l'ora dell'ultimo accesso e le informazioni sul sistema operativo.

    Comandi nella console

    pwd

    df

    Il comando df mostra la quantità di spazio libero e utilizzato sul server, su tutti i file system montati

    du

    Il comando du mostra quanto spazio occupa una cartella o un file.
    Comando di esempio:

    Du -h /casa/

    Questo comando mostrerà quanto spazio occupa la directory /home/.

    È tutto. La prima conoscenza con la connessione al server tramite SSH e il programma putty è finita. Utilizzando queste informazioni, puoi andare al server e vedere quanto spazio occupano i dati.



    
    Superiore