Il manuale di Secure Shell SSH

Tutorial su questo magnifico protocollo che ha iniziato le sue avventure nel 1997, offrendo un'ampia varietà di strumenti che si distinguono per la loro sicurezza, essendo molto esteso lo dividerò in più voci cercando di coprire la cosa più importante sia a livello di client che di server.

Che cos'è il protocollo Secure Shell?Secure Shell o SSH è un protocollo di rete che consente lo scambio di dati su un canale sicuro tra due computer. SSH utilizza tecniche di crittografia che rendono illeggibili le informazioni che viaggiano attraverso il mezzo di comunicazione e nessuna terza persona può scoprire il nome utente e la password della connessione o quanto scritto durante l'intera sessione. SSH utilizza la crittografia a chiave pubblica per autenticare il computer remoto e consentirgli di autenticare l'utente, se necessario.

SSH viene solitamente utilizzato per avviare una sessione su una macchina remota, dove è possibile eseguire comandi, ma consente anche il tunneling, l'inoltro arbitrario di porte TCP e connessioni X11; I trasferimenti di file possono essere eseguiti anche utilizzando i protocolli SFTP o SCP associati.

Possiamo vedere che la sua grande attrattiva è la sua caratteristica più che sufficiente per sostituire il vecchio protocollo TELNET, che manca di crittografia delle informazioni, compromettendo i dati, comprese le credenziali di accesso.

Il server SSH, offre per impostazione predefinita la porta TCP 22. Un client SSH viene generalmente utilizzato per stabilire connessioni a un server sshd che accetta connessioni remote. Entrambi si trovano comunemente sulla maggior parte dei sistemi operativi moderni, inclusi Mac, Linux, Solaris e OpenVMS.

Il supporto di Windows per la sua versione Server dovrebbe essere rilasciato ufficialmente quest'anno, mentre a livello di cliente offre un'ampia varietà di opzioni che mettono in evidenza PuTTY rispetto alle altre.

Impara ad usare Putty

ApriSSHOpenSSH (Open Secure Shell) è un insieme di applicazioni che consentono comunicazioni crittografate su una rete, utilizzando il protocollo SSH. È stato creato come alternativa libera e aperta al protocollo SSH, è il più utilizzato sotto Linux e sarà quello che utilizzeremo nelle voci.

1. Installa Secure Shell SSH

In quasi tutte le distribuzioni la sua versione client è preinstallata mentre la sua versione server è disponibile tramite repository, la sua installazione dovrebbe essere molto semplice.

Debian, Ubuntu, Linux Mint e derivati

 sudo apt-get install openssh-server

Centos, Rhel, Fedora

 sudo yum install openssh-server

Arch-Linux

 pacman -Syu openssh

Verifichiamo che sia in esecuzione con:

 curl localhost: 22

In caso di funzionamento corretto dovrebbe restituire:

[colore = # 696969] [/Colore]

Connessione al server
Utilizzando il client possiamo connetterci al server che può essere remoto anche se abbiamo entrambe le versioni per connetterci internamente tramite localhost.

Il modo più semplice per connettersi sarebbe:

 ssh utente @ hostaddress

In caso di collegamento interno sarebbe:

 ssh utente @ localhost

Abbiamo un'ampia varietà di opzioni durante la connessione, ne spiegherò alcune molto utili, puoi elencare tutte le tue opzioni con:

 uomo ssh

Qui li mostriamo:

Opzioni SSH uomo
-CRichiedi la compressione dei dati risparmiando larghezza di banda o dati in caso di utilizzo di una rete mobile.

-lSpecificare l'utente con cui ci collegheremo.

-ECreare un file di registro in cui verrà deviato l'errore standard.

-FSelezioniamo un altro file di configurazione utile per i server con opzioni insolite.

-GNecessario per il tunneling della porta.

-ioScegliamo la cartella che utilizzeremo per una chiave privata alternativa.

-KAbilita quando si utilizzano le credenziali GSSAPI.

-nUsandolo insieme a X11 in questo modo tutto il log generato dall'applicazione viene deviato su /dev/null.

-oNecessario per utilizzare opzioni più avanzate come ServerAliveInterval 30.

-PSelezionare una porta diversa da 22 per connettersi all'host.

-vMostra tutti i passaggi necessari per stabilire la connessione.Puoi ottenere ancora più informazioni con -vv -vvv.

-XNecessario se vogliamo usare X11 Forwarding.

-YAbilita l'inoltro X11 sicuro.

Ci collegheremo al server test.solvetic.com con l'utente jcarrillo utilizzando una chiave privata diversa situata nella nostra cartella /home/jcarrillo/keys-aws utilizzando la porta 8022 della nostra istanza su AWS.

 Esempio → ssh -C -i “~ / keys-aws /” -p 8022 -l jcarrillo test.solvetic.com

Come possiamo vedere, è uno strumento ampio ma molto completo che merita più voci per poter coprire le sue funzioni necessarie per qualsiasi Sysadmin di livello intermedio o Professional.

Passiamo ora alla sua configurazione a livello client-server, generazione di chiavi pubbliche e private, utilizzo del port forwarding in situazioni reali, reindirizzamento dell'X Server tramite X11 Forwarding, utilizzo di scp, sftp, ssh-agent tra gli altri .

2. Proteggi il server SSH

Continuiamo con ApriSSH concentrandosi su proteggere il nostro server SSH, per evitare tutti i tipi di Attacchi che potrebbero compromettere il nostro Server. Tutte queste configurazioni verranno eseguite nel file sshd_config situato in / etc / ssh / che possiamo modificare con qualsiasi editor di testo nel mio caso vim:

 sudo vim / etc / ssh / sshd_config

Ora vediamo come modificarlo.

Modifica sshd_config
All'interno vedremo un tipico file di configurazione basato su "Opzione valore" Se una qualsiasi delle opzioni non viene trovata per impostazione predefinita, dobbiamo posizionare la riga completamente, in altri casi sarà solo cambiare da 0 a 1 da No a Sì o rimuovere il commento di una riga.

Modifica porta 22
È essenziale cambia la porta predefinita in una casuale molti script sono configurati per attaccare questa porta, si consiglia di cambiarla nel gamma da 1000 a 23000 assicurandosi che la porta non sia utilizzata da un altro servizio.

Né dovremmo usare porte come 2222, 8022 o 1022, sono comuni come 22 e molti script sono configurati per attaccarli.

porta 2345

Se abbiamo SELINUX abilitato dobbiamo utilizzare un comando aggiuntivo per consentire l'accesso dall'esterno alla nuova porta.

Semanage port -a -t ssh_port_t -p tcp 2345 #Modifica della porta 22 per sicurezza

Usa protocollo predefinito 2
Dobbiamo assicurarci che tutte le nostre connessioni siano effettuate secondo il Protocollo 2 poiché 1 presenta molte vulnerabilità.

Protocollo 2

È ora di inserire le credenziali
Sezione di ricerca "Autenticazione". Anche le tue prime due opzioni sono importanti. Il primo è il numero di secondi che l'utente remoto avrà a disposizione per accedere alla tua macchina. Imposta quel valore su alcuni secondi, non ci vorrà molto per accedere se conosciamo l'account e la password.

In questo modo evitiamo alcuni script che sfruttano quel tempo. Il valore tipico in termini di sicurezza è 30, anche se può essere anche inferiore.

AccediGraceTime 30

Disabilita l'accesso root
Questo È l'opzione più importante essere vittima di un attacco, hanno bisogno di 3 cose:

• Utente
• porta
• Parola d'ordine

Se disabilitiamo root, ne hanno già uno poiché root è un utente comune su tutti i sistemi. Oltre a questo, questo utente può provocare il caos avendo tutti i permessi abilitati.

PermitRootLogin no

Abilita l'accesso controllato
Possiamo controllare quale utente può accedere tramite SSH e persino inserire una clausola per connettersi solo da un determinato IP. È simile a ciò che offre AWS per connetterci alle tue istanze.

AllowUsers [email protected]

È importante consentire l'accesso solo agli utenti che necessitano dell'accesso remoto e, se possibile, limitarli a un IP noto.

Configura il numero di tentativi falliti
Se mettiamo la password sbagliata, il server ci dà diversi tentativi di reinserirla, questa deve essere limitata o potresti essere vittima di uno script di forza bruta, possiamo inserirla 2 o 3 volte.

MaxAuthTries 2

Numero di connessioni consentite contemporaneamente
Questo può variare a seconda di come si utilizza il server, ma l'ideale è averlo controllato, basta aggiungere il numero totale di utenti consentiti da SSH.

MaxStartups X

Dopo aver apportato tutte le modifiche al nostro file dobbiamo riavvia il nostro servizio sshd, Può variare a seconda del gestore del servizio.

SistemaD

 systemctl riavvia sshd

Upstart / Sysinit

 riavvio del servizio sshd

Tutti questi cambiamenti aggiungono un ulteriore livello di sicurezza ma dobbiamo tenere a mente:

• Usa password alfanumeriche.
• Utilizzo Autenticazione tramite chiavi pubbliche/private quando è possibile.
• Integra la sicurezza con SELINUX e firewall.
• Controlla l'accesso a cui gli utenti devono accedere in remoto.

Autenticazione delle chiavi pubbliche/private SSH

Attualmente in uso Chiavi SSH È un requisito indispensabile, questa autenticazione è ampiamente utilizzata dagli amministratori per automatizzare le attività tra vari server ed è persino utilizzata dagli sviluppatori per accedere a SCM come GIT, GITHUB, GITLAB tra gli altri.

Offre grande sicurezza e la possibilità di creare attività automatizzate basato su script come a Di ritorno o Replica modifiche a più nodi contemporaneamente.

Quando si usa una chiave SSH (pubblico e privato), possono connettersi facilmente a uno o più server, senza dover inserire una password ogni volta. È possibile configurare le tue chiavi senza una passphrase, tuttavia sarebbe imprudente, se qualcuno ottenesse la tua chiave, potrebbe usarla. Parleremo di come generare le Chiavi, distribuirle e utilizzare ssh-agent per ottenere una maggiore Sicurezza.

Generazione di chiavi senza passphrase
Prima di tutto, assicurati di avere installato OpenSSH, non è necessario, il server solo il client.

Iniziamo generando una chiave di tipo DSA con sicurezza a 1024 bit, più che sufficiente anche se puoi andare oltre e generare una chiave di tipo RSA con un limite di 4096.

 ssh-keygen -b 1024 -t dsa

Ci chiederà la posizione in cui salverà le chiavi predefinite ~ / .ssh

 Inserisci il file in cui salvare la chiave (/home/test/.ssh/id_dsa)

Quindi chiederà una frase per ora non ne useremo nessuna e la lasceremo in bianco e ci dirà che la chiave è stata creata e ci riflette.

L'immagine sarà sempre diversa, viene generata casualmente, quindi se andiamo nella cartella .ssh dobbiamo avere 2 file

id_dsa -----> Chiave privata (non condividerla con nessuno, è come il tuo TDC).
id_dsa.pub ----> È quello che condividiamo per connetterci.

Condividi chiave pubblica
Nel caso in cui desideriamo condividere la chiave pubblica in SCM o Chef, Puppet, Jenkins, visualizziamo il file della chiave pubblica, lo copiamo e lo incolliamo dove corrisponde.

 più id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAACBAN6SEI4Qqzb23pJYRXIAtPmGJHln5hFdthFq43ef + ifR29v2IknXCFwefKK8jorSDiUEY / 1F / yp0xao mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s + fx + + L22sV7GkCHPxAAAAFQCyF1Gdh3 xQiW3mf3y4IX654O82SLGl7Vhh5UsvG8r8d8pV6R Cap4xr / J44xDDn 0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP + + + 03anWgyoZqSPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4 Hxo4Y5skKihnPMtB bFNbP / 2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiBVVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNCBIvCO3uQYOozyzNGBhqHE7FVq 1oXguj + + + 2GAQ UGNkee96D2by S7daieIKNmFer2hO / SBxzepMrWAiIUnUsP5irmYspkjGlQxP + hxw = test @ solvetic 

Nel caso in cui desideri condividerlo per accedere a un server, ti consiglio sempre di utilizzare ssh-copy-id è incluso in OpenSSH ed è molto facile da usare:

 ssh-copy-id user @ remote-server-ip -i specifica la posizione della chiave da usare.

Ci sono altri modi come:

 ssh utente @ remote-server-ip \ 'cat >> .ssh/authorized_keys2' <.ssh/id_dsa.pub

 scp ~ / .ssh / id_dsa.pub utente @ remote-server-ip

D'ora in poi le chiavi sono collegate e devi solo entrare nell'host.

 ssh -l utente remote-server-ip

Questa volta non richiederà alcuna password e possiamo usare script senza interazione.

Genera passphrase e associa a ssh-agent
Il Sicurezza della chiave SSH Si basa sulla nostra chiave privata che funziona come una carta di accesso, ma se qualcuno ruba la nostra chiave, sarà in grado di accedere a tutti i luoghi in cui abbiamo accesso. Ma quando si genera una passphrase possiamo avere un livello extra, non solo la chiave è necessaria, ma non abbiamo bisogno di introdurre la nostra frase.

Questa volta creeremo una chiave rsa con maggiore sicurezza configurando una frase.

 ssh-keygen -b 4096 -t rsa -C "Chiave con passphrase" # -C Aggiungi un commento. 

Essendo una frase possiamo usare spazi, punti e caratteri speciali

 esempio ---> Questa è la mia nuova chiave con Fr @ S3.

Condividiamo la nuova chiave:

 scp ~ / .ssh / id_rsa.pub utente @ remote-server-ip

Questa volta abbiamo bisogno della chiave e della Passphrase, ma inserirla più volte è noioso, ma possiamo completarla con ssh-agent, dobbiamo avviarla.

 ssh-agente

Aggiungiamo la nostra chiave

 ssh-add Inserisci la passphrase per /home/user/.ssh/id_rsa: # Inseriamo la frase che abbiamo configurato. 

Ora possiamo connetterci a qualsiasi server che utilizza la nostra chiave senza dover inserire la nostra frase d'accesso.

Consiglio questo metodo se si è al di fuori della intranet, client e server in punti diversi su Internet, e non utilizzeremo attività automatizzate, ma piuttosto ci collegheremo al server per scopi di amministrazione remota, è meglio indicare una password o molto lunga passphrase (15 o più caratteri, maiuscole, minuscole, numeri e simboli) alla chiave pubblica.

Per di qua sarà praticamente impossibile essere hackerati con questo metodo, poiché non solo l'hacker dovrà conoscere la password ma dovrà disporre di un certificato pubblico valido sul server per potersi autenticare. (Naturalmente supponendo che il server non sia mai stato compromesso e sia completamente aggiornato e con la massima sicurezza possibile).

Ti è piaciuto e hai aiutato questo Tutorial?Puoi premiare l'autore premendo questo pulsante per dargli un punto positivo