Vi presentiamo alla vostra attenzione un nuovo corso del team Il codeby- "Penetration Test di applicazioni Web da zero". Teoria generale, preparazione dell'ambiente di lavoro, fuzzing passivo e impronte digitali, fuzzing attivo, vulnerabilità, post-sfruttamento, strumenti, ingegneria sociale e altro ancora.

Cos'è SSH e a cosa serve

Secure Shell (SSH) è un protocollo di rete che fornisce funzionalità di shell a una macchina remota su un canale protetto. SSH offre vari miglioramenti alla sicurezza, tra cui l'autenticazione dell'utente/host, la crittografia dei dati e l'integrità dei dati, il che rende impossibili attacchi popolari come intercettazioni, spoofing DNS/IP, falsificazione dei dati e dirottamento della connessione, ecc. Per gli utenti ftp, telnet o rlogin che utilizzano un protocollo che trasferisce i dati in chiaro, si consiglia vivamente di passare a SSH.

OpenSSH è un'implementazione open source del protocollo SSH che crittografa una connessione di rete utilizzando una suite 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 (aggiunta di chiavi private), ssh-agent (agente di autenticazione), ssh-keygen (gestione delle chiavi di autenticazione ).

Installazione di server e client OpenSSH su Linux

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

Debian, Ubuntu o Linux Mint

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

Sui sistemi basati su Debian, subito dopo l'installazione, 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 senza ambiguità ssh all'avvio all'avvio del sistema.

$ sudo update-rc.d ssh defaults

Fedora o CentOS / RHEL 7

$ sudo yum -y install openssh-server openssh-clients $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service

CentOS / RHEL 6

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

Arch Linux

$ sudo pacman -Sy openssh $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service

Configurazione del server OpenSSH

Se vuoi configurare il server OpenSSH, puoi modificare il file di configurazione a livello di sistema che si trova in /etc/ssh/sshd_config.

Ci sono un paio di opzioni OpenSSH che potrebbero interessarti:

Per impostazione predefinita, sshd ascolta sulla porta 22 e ascolta le connessioni ssh in entrata. Modificando la porta predefinita per ssh, puoi prevenire vari attacchi di hacker automatizzati.

ListenAddress 192.168.1.1

Se la tua macchina ha più di un'interfaccia di rete fisica, potresti voler controllare quale è correlata a sshd, puoi usare l'opzione ListenAddress per farlo. Questa opzione aiuta a migliorare la sicurezza limitando SSH in entrata solo attraverso un'interfaccia specifica.

HostKey / etc / ssh / ssh_host_key

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

PermitRootLogin no

Opzione PermitRootLogin - Se root può accedere tramite ssh.

Consenti Utenti alice bob

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

Dopo aver modificato /etc/ssh/sshd_config, assicurati di riavviare il servizio ssh.

Per riavviare OpenSSH su Debian, Ubuntu o Linux Mint:

$ sudo /etc/init.d/ssh restart

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

$ sudo systemctl riavvia sshd.service

Per riavviare OpenSSH su CentOS/RHEL 6:

$ sudo service sshd riavvio

Come connettersi a SSH

Connessione a SSH da Linux

Gli utenti Linux non devono installare software aggiuntivo.

Connettiti a SSH da Windows

Per Windows, molte persone consigliano e utilizzano con successo PuTTY. Non ho nulla contro questo programma, ma preferisco e raccomando personalmente Cygwin.

Cygwin non è solo un client SSH. È una potente combinazione che supporta molti comandi di Linux. Ad esempio, è molto facile creare certificati SSL in Cygwin (proprio come in Linux). In Windows, devi ballare con un tamburello per creare certificati autofirmati. 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.

L'installazione di Cygwin è semplice. Vai al sito Web ufficiale e scarica la versione a 32 o 64 bit.

Viene scaricato un piccolo file: questo è il programma di installazione. Il programma di installazione è grafico. Sebbene contenga un gran numero di opzioni, sono tutte abbastanza semplici e molte sono familiari da altri programmi di installazione grafici. Se qualcosa non è chiaro, fai clic su "Avanti". Forse solo la seguente finestra può creare confusione:

Ecco tutti gli articoli disponibili per l'installazione. Non abbiamo bisogno di capirli adesso. Poiché quelli più richiesti sono già contrassegnati per l'installazione. E se manca qualcosa in futuro, puoi facilmente installare quello necessario.

Connessione SSH (comune per Linux e Windows)

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

SSH ha bisogno delle seguenti informazioni per connettersi:

• IP o nome host
• numero di porta
• Nome utente
• password utente

SSH può assumere due di questi parametri: nome utente e numero di porta. Se non viene specificata alcuna porta, viene utilizzata la porta predefinita. Se non viene specificato alcun utente, viene 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 scrivo

Ssh 192.168.1.36

vedo quanto segue

[e-mail protetta]~ $ 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 la connessione?

Dal momento che mi sto connettendo all'host per la prima volta, è un host sconosciuto. Mi chiedono se voglio continuare. sto scrivendo sì:

Avvertimento: aggiunto in modo permanente "192.168.1.36" (ECDSA) all'elenco degli host conosciuti. [e-mail protetta]"s 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 tale utente sul server con SSH, ma clicco Ctrl + C(da rompere) 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 viene letto 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]

Invito [e-mail protetta] ha dato il via a un invito [e-mail protetta] Ciò significa che siamo già su una macchina remota, cioè abbiamo già una connessione. Se è necessario specificare una porta (se è diversa da quella standard), è necessario specificare la porta dopo l'opzione -p. Ad esempio così:

Ssh [e-mail protetta]-p 10456

Dopo la connessione, siamo accolti con qualcosa come il seguente saluto:

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; i termini esatti di distribuzione per ogni 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 Jun 16 15:32:25 2015 da 192.168.1.35

Implica che la macchina remota sia Linux Mint, con kernel 3.16, versione a 64 bit. Importanti anche le informazioni sull'ora dell'ultimo login 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 l'azione appropriata.

Digitiamo alcuni comandi per assicurarci dove siamo e chi siamo: pwd, uname -a eccetera.:

Per terminare la sessione (disconnettersi), digitare

Oppure premere Ctrl + D.

Accedi a SSH senza inserire una password

Innanzitutto, è solo 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 come risolverlo. Se hai Cygwin, allora va tutto bene.

Se sei riuscito ad accedere al sistema remoto, disconnettiti. Quindi digita

Ssh-keygen -t rsa

Ci viene chiesto il nome del file, non è necessario inserire nulla, verrà utilizzato il nome predefinito. Viene richiesta anche la password. Non inserisco una password.

Ora sulla macchina remota, dobbiamo creare la directory .ssh. Di seguito verrà descritta l'esecuzione del comando su una macchina remota. Per ora, copia semplicemente il comando, ricordandoti di cambiare l'indirizzo IP e il nome utente con i tuoi:

Ssh [e-mail protetta] mkdir .ssh

Ora dobbiamo copiare il contenuto del file id_rsa.pub sulla macchina remota. È molto facile farlo (non dimenticare di cambiare i dati con i tuoi):

Gatto .ssh / id_rsa.pub | ssh [e-mail protetta]"gatto >> .ssh / chiavi_autorizzate"

Ora ci limitiamo ad accedere e non ci chiediamo più la password. E ora 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 l'esecuzione di singoli comandi sul sistema remoto. Ad esempio, per eseguire il comando dell'albero su un host remoto denominato remote-sys e visualizzare i risultati sul sistema locale, procedere come segue:

ssh albero di sistema remoto

Il mio esempio di vita reale:

Ssh [e-mail protetta] albero

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

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

Un vero esempio:

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

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

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

Invio di stdout dalla macchina locale a ssh remoto

Una versione altrettanto interessante dell'esecuzione dei comandi è mostrata poco sopra:

Gatto .ssh / id_rsa.pub | ssh [e-mail protetta]"gatto >> .ssh / chiavi_autorizzate"

• Il comando cat legge e visualizza riga per riga il contenuto del file .ssh / id_rsa.pub sulla macchina locale.
• | (pipe) passa ciò che dovrebbe apparire su stdout a un altro comando.
• Invece di un comando che avrebbe dovuto elaborare le righe passate, viene stabilita una connessione al sistema remoto (ssh [e-mail protetta]).
• Il sistema remoto riceve le righe per le quali viene fornito il comando cat >> .ssh / authorized_keys. Quelli. i contenuti dello standard output vengono scritti riga per riga nel file .ssh / authorized_keys sulla macchina remota.

Apertura di un programma di grafica situato su un computer remoto

Il prossimo trucco richiede due computer Linux. Sfortunatamente, nemmeno Cygwin può gestire questo trucco. Inoltre, entrambi i Linux devono essere dotati di un'interfaccia utente grafica.

Tunneling con SSH

Tra l'altro, ciò che accade quando viene effettuata una connessione a un host remoto tramite SSH è la creazione di un tunnel crittografato che si forma 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 alla macchina remota e che anche il risultato venga restituito in modo sicuro.

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

Forse la più comunemente usata di queste funzionalità è la capacità di trasmettere il traffico del sistema X Window. Su un sistema che esegue un server X (queste sono macchine che hanno un'interfaccia utente grafica), è possibile eseguire un programma client X (applicazione grafica) su un sistema remoto e vedere i risultati del suo lavoro sul sistema locale. È facile da fare. Ad esempio, voglio connettermi all'host remoto remote-sys e su questo 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

Un vero esempio:

Ssh -X [e-mail protetta] gedit

Quelli. SSH viene avviato con l'opzione -X. E poi il programma si avvia. Dai un'occhiata allo screenshot.

Sono su Kali Linux. Sto accedendo con successo al computer remoto tramite SSH. Successivamente, ho eseguito il programma gedit. Questo programma potrebbe non essere nemmeno disponibile su Kali Linux, ma lo è sicuramente su Linux Mint, 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 c'è un programma gedit in esecuzione sul computer locale. Se voglio salvare il risultato del lavoro di gedit (o qualsiasi altro programma aperto in questo modo), si scopre che funziona nell'ambiente del computer remoto, vede il suo file system, ecc. Questo è conveniente quando si desidera 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 su SSH".

Su alcuni sistemi, questo "focus" richiede l'uso dell'opzione -Y invece dell'opzione -X.

Copia da/a computer remoto (scp e sftp)

scp

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

Scp remote-sys: document.txt. document.txt 100% 177 0.2KB / s 00:00

Un vero esempio:

# cancella il file sulla macchina locale, se presente rm dirlist.txt # crea il file sulla macchina ssh remota [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

Per copiare un file da una macchina locale a una remota:

scp file-local remote-sys :.

Esempio reale

# crea un nuovo file touch nfile.txt # invia il file scp nfile.txt [e-mail protetta]:. nfile.txt 100% 0 0.0KB / s 00:00 # controlla se il file esiste sulla macchina ssh remota [e-mail protetta]"ls -l"

Nel comando di invio:

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

Nota:

Per copiare un file da B ad A dopo aver effettuato l'accesso a B:

scp / percorso / a / file [e-mail protetta]: / percorso / verso / destinazione

Copiare un file da B ad A dopo aver effettuato l'accesso ad A:

scp [e-mail protetta]: /percorso/a/file/percorso/a/destinazione

sftp

Il secondo programma per la copia di file su SSH è sftp... Come suggerisce il nome, è un sostituto sicuro per i programmi ftp. sftp funziona come il programma ftp originale. Tuttavia, invece di inviare in chiaro, utilizza un tunnel SSH crittografato. Un importante vantaggio di sftp su ftp è che non richiede un server FTP in esecuzione sull'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:

[e-mail protetta]~ $ sftp [e-mail protetta] Collegato a 192.168.1.36. sftp> ls dirlist.txt newfile.txt nfile.txt temp Video Documenti Download Immagini Musica Public Desktop Modelli sftp> lls dirlist.txt nfile.txt sftp> ls temp temp / TakeMeHome sftp> cd temp / sftp> get TakeMeHome Fetching / mial / temp / Da TakeMeHome a TakeMeHome sftp> ciao

Il protocollo SFTP è supportato da molti gestori di file grafici presenti nelle distribuzioni Linux. Usando sia Nautilus (GNOME) che Konqueror (KDE), possiamo inserire URI (link) che iniziano con sftp: // nella barra di navigazione e lavorare con file che si trovano su un sistema remoto che esegue un server SSH.

Il Garante è un intermediario di fiducia tra i Partecipanti all'operazione.

SSH (Secure Shell) è un protocollo di accesso remoto alla rete che utilizza la crittografia e la compressione per i dati trasmessi. In poche parole, è uno strumento molto utile e potente che consente di autenticarsi nel sistema e lavorare completamente per conto di un utente locale, trovandosi a molti chilometri di distanza da una macchina in funzione. Inoltre, a differenza di telnet e rsh, SSH crittografa tutto il traffico, in modo che tutte le informazioni trasmesse rimangano riservate.

Quindi, abbiamo già installato ssh e ssh-daemon viene aggiunto all'avvio all'avvio del sistema. Puoi controllarlo tramite il comando:

service ssh stop | start | restart

Su Ubuntu, oppure:

/etc/init.d/ssh (start | stop | reload | force-reload | restart | status)

Su Debian, oppure:

systemctl start | stop | riavviare sshd.service

In ArchLinux (dopo ogni modifica della configurazione, è necessario riavviare). Il kit include un client e un server.

Proviamolo in azione! Per prima cosa, crea una cartella ~ / .ssh

mkdir ~ / .ssh

Genera chiavi per l'utente del server specificato con il comando:

ssh-keygen (come utente normale).

Durante la generazione, puoi impostare una passphrase per la chiave (è consigliabile impostarne una lunga - quindi anche dopo aver ottenuto la chiave ma non conoscendo la password dalla chiave, l'attaccante non sarà in grado di accedere), oppure puoi saltalo semplicemente premendo "Invio" - in questo caso, la password non verrà mai richiesta. Le stesse chiavi pubbliche e private sono apparse nella cartella ~ / .ssh.

Trova un'altra macchina (anche uno smartphone andrà bene - Android ha alcuni ottimi client SSH come ConnectBot o JuiceSSH), installa ssh su di essa e connettiti al server con il comando:

ssh [e-mail protetta]

Se tutto è stato eseguito correttamente, ti verrà richiesta la password dell'utente e, dopo essere entrato, ti ritroverai nel tuo sistema con una vista dalla riga di comando.

Per Windows, tra l'altro, ci sono anche server e client ssh.

Dopo aver apprezzato il risultato delle nostre fatiche, passiamo a una parte ancora più noiosa: l'impostazione del client/server.

La configurazione lato client è in /etc/ssh/ssh_config e quello del server - /etc/ssh/sshd_config... La guida alla configurazione più completa è probabilmente la pagina man per man ssh e man sshd_config, quindi consigliamo di leggerla. E in questo articolo considereremo le cose più necessarie.

personalizzazione

La porta ssh standard è 22. Può essere cambiata con qualsiasi non standard (rendendo più difficile l'hacking a causa della sicurezza attraverso l'oscurità o per attirare l'attenzione di potenziali aggressori :) - per fare ciò, decommenta la riga:

#Porta 22

E aggiungi quello che vuoi fino a 65535 (assicurandoti che la porta non sia in conflitto con altri servizi con il comando #netstat -tupln | grep ASCOLTA).

Ora, quando si connette al server, il client dovrà scrivere con la chiave:

ssh -p [porta]:

Per impostazione predefinita, è consentito l'accesso root. È altamente consigliabile limitarlo (e invece delimitare correttamente i diritti dell'utente locale utilizzando sudo). Per fare ciò, trova la riga "PermitRootLogin" e modifica il valore in "no". Puoi anche cambiarlo in "senza password" - in questo caso, l'accesso sotto root sarà consentito solo da macchine con una chiave attendibile.

Puoi disabilitare l'autenticazione della password e lavorare solo con le chiavi: trova la riga: "PasswordAuthentication" e modifica il valore in "no". Per che cosa? Se qualcuno vuole davvero ottenere l'accesso al tuo sistema, può eseguire la forza bruta della password quando tenta di autorizzare o ascoltare e decrittografare la tua connessione. Se disabiliti l'autenticazione della password e aggiungi a ~ / .ssh / authorized_keys sul server la chiave pubblica del tuo, ad esempio, laptop di lavoro, quindi, come ricordiamo, saremo immediatamente autorizzati al server. Ma cosa succede se stai lavorando sulla macchina di qualcun altro e hai urgente bisogno di accedere al server ssh, ma, come previsto, non ci farà entrare? Quindi non è possibile disabilitare l'autenticazione della password, ma utilizzare l'utilità fail2ban. Basta installarlo dal tuo repository, dopodiché applicherà le impostazioni predefinite e almeno proteggerà il tuo canale ssh dagli attacchi di forza bruta. Maggiori informazioni su fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.

Nel caso in cui il tuo server conservi le chiavi per il lancio di missili nucleari, puoi fare qualcosa del genere:

PermitRootLogin no - il login sotto root è proibito.

PasswordAuthentication no - login senza password

Generiamo una chiave lunga sulla macchina remota (-t tipo_crittografia, -b lunghezza in bit):

ssh-keygen -t rsa -b 4096

Con una passphrase altrettanto complessa (a proposito, non puoi recuperare una password dimenticata. Puoi cambiarla con il comando "ssh-keygen -p", ma ti verrà comunque richiesta quella vecchia). Trasferiamo la chiave pubblica della macchina locale remota su ~ / .ssh / authorized_keys sul server e voilà - ora l'accesso può essere ottenuto da una singola macchina, utilizzando la passphrase della chiave privata. SSH ti consente di impostare molte configurazioni di sicurezza e ha molte impostazioni specifiche per questo - leggile in man.

Due opzioni sshd_config hanno lo stesso scopo:

AccediGraceTime- imposta il tempo dopo il quale la connessione verrà disconnessa se non avviene l'autenticazione.

MaxAuthTries- imposta il numero di tentativi errati di accesso al login, al raggiungimento dei quali la connessione verrà interrotta.

MaxSesions- il numero di sessioni simultanee (se il server è il tuo computer di casa a cui ti collegherai dall'università o dal lavoro, allora sarebbe ragionevole limitare il numero di sessioni a una - un login rifiutato, in questo caso, sarà diventare un motivo per aumentare la paranoia, generare nuove chiavi e cambiare password). Tuttavia, se stai attento, potresti aver notato che la riga "Last Login" viene visualizzata ad ogni accesso al server. Oltre ad esso, puoi aggiungere il tuo messaggio di saluto: trova la riga "Banner" e invece di nessuno, imposta il percorso del file con il testo che verrà letto e visualizzato al momento del login.

Tra le altre cose, puoi consentire solo a determinati utenti di accedere o consentire a tutti tranne a determinati utenti:

Consenti Utenti utente1- consentire l'accesso solo all'utente1.

DenyUsers utente1- consentire a tutti tranne utente1.

E parametri simili per l'accesso a determinati gruppi sono AllowGroups e DenyGroups.

Puoi anche SSH una sessione X11. Per fare ciò, trova la riga "ForwardX11" e modifica il valore in "yes".

Trova una riga simile nella configurazione del client - / etc / ssh / ssh_config e cambia anche in "yes".

Ora devi connetterti al server tramite ssh con l'argomento -X:

ssh -X [e-mail protetta]>

Puoi avviare immediatamente l'applicazione quando sei connesso:

ssh -X [e-mail protetta]"Appendice"

Ecco come appare un GIMP in esecuzione in una sessione ssh:

Oppure puoi ottenere l'output dalla webcam del laptop di un utente ignaro :)

I calcoli vengono eseguiti direttamente sul server e l'output viene inviato al computer client (ovvero, anche se il server stesso non dispone di X11, le applicazioni grafiche possono essere visualizzate sul computer remoto). Questo schema funziona piuttosto lentamente (non dimenticare che tutto il traffico è crittografato dinamicamente), ma questa funzione è molto utile.

Puoi anche copiare i file su una sessione SSH: esiste una semplice utility "scp" per questo. Puoi trasferire file direttamente nella sessione come dal server al client:

scp [e-mail protetta]: / percorso / a / file / su / server / dove / salva / su / locale / macchina

Quindi da client a server:

scp percorso / a / file / client [e-mail protetta]: / percorso / su / server

Questo è abbastanza comodo se devi copiare un libro di testo o una foto, ma cosa succede quando devi lavorare con molti file? C'è una cosa molto comoda per questo: sshfs (disponibile per l'installazione nei repository della maggior parte dei * nix-system).

Basta impostare il percorso come scp:

sshfs [e-mail protetta]: / home / utente / mnt /

E la cartella /home/utente del server apparirà nel punto di montaggio /mnt della macchina locale!

Lo smontaggio avviene tramite umount.

E per finire, parliamo di una caratteristica poco conosciuta. Se crei un file /.ssh/config e riempilo così:

Nome host]

Nome host

Utente [nome utente del server]

opzioni desiderate

Piace

AvantiX11 sì

Porta 30.000

Quindi possiamo accedere tramite:

ssh [nome]

ssh -X -p 30000 [e-mail protetta]

E tutte le opzioni verranno raccolte automaticamente. Pertanto, con l'autenticazione frequente su un server specifico, semplificherai questo processo in pochi istanti.

Bene, abbiamo coperto tutto (e anche di più) che devi sapere su SSH per il suo uso quotidiano: abbiamo imparato a utilizzare l'autenticazione con chiave, protetto il server da attacchi di forza bruta e, in generale, corretto la maggior parte dei potenziali buchi. In effetti, SSH può fare molte altre cose, ad esempio tunneling e port forwarding attraverso una sessione ssh, ma è improbabile che tu, come utente normale, lo utilizzerai mai. Risorse addizionali

In questo articolo, esamineremo modi moderni e convenienti per lavorare con un server tramite SSH con un VPS di Infobox e un cloud.

Ti parleremo non solo del solito modo di connettersi, ma anche dell'organizzazione di una connessione stabile tramite una Internet instabile (ad esempio modem 3G), nonché di utilità aggiuntive che aiutano a lavorare su SSH.

Se sei un utente Windows e hai bisogno di connetterti facilmente e rapidamente a un server Linux, vai alla sezione "Putty o come connettersi rapidamente a SSH da Windows".

Cosa devi sapere per connetterti tramite SSH

Per connetterti hai bisogno di:

• Indirizzo IP del server
• Accedere
• parola d'ordine

Dove ottenere i dati per la connessione al server VPS NG da Infobox

Dopo aver ordinato il servizio, accedi al pannello di controllo https://panel.infobox.ru.
Selezionare il servizio "VPS NG" nell'angolo in alto a destra del pannello di controllo nell'elenco a discesa.
Quindi vai alla scheda "VPS".

In questa sezione vedrai indirizzo IP del server e puoi installare password per accedere al server.

Usa il tuo nome utente per connetterti radice, indirizzo IP da questa pagina e installato parola d'ordine.
Se hai dimenticato la password, clicca sulla voce "Modifica impostazioni di accesso" mostrata nello screenshot qui sopra.

Dove ottenere i dati per la connessione al server VPS da Infobox

Accedi al pannello di controllo https://panel.infobox.ru.
Selezionare il servizio VPS nell'angolo in alto a destra del pannello di controllo nell'elenco a discesa (il nome del servizio contiene il nome del sistema operativo ordinato e la regione di ubicazione).

Quindi vai alla scheda "Gestione VPS".

Usa nome utente radice, password e indirizzo IP del server da questa pagina.

Dove ottenere i dati per connettersi al server InfoboxCloud

Dopo aver creato il server, i dati di connessione ti verranno inviati via e-mail. Questo è sufficiente per la connessione.

Se hai perso l'e-mail con i dati di accesso e vuoi ottenere l'accesso al server

Per impostazione predefinita, il login dell'amministratore del server è: root

Accedi al pannello di controllo su: https://panel.infobox.ru.
Seleziona il servizio "Server Cloud" nell'angolo in alto a destra del pannello di controllo nell'elenco a discesa.

L'indirizzo IP dedicato per il server può essere visualizzato nella scheda "Infrastruttura cloud" del pannello di controllo.

Se il campo " Indirizzo IP dedicato"vuoto, significa che durante la creazione del server, non hai aggiunto almeno 1 indirizzo ip dedicato al server (e quindi non c'è accesso al server via Internet, c'è solo dalla rete locale).

Per aggiungere un indirizzo IP dedicato, fare clic sul nome del server.

Nel gruppo di impostazioni "Rete", fare clic su "Configura".

Assicurati che la larghezza di banda (velocità) della rete sia sufficiente (o impostane di più se necessario).
Quindi fare clic su Aggiungi indirizzo IPv4 e fare clic su Salva modifiche.

Il server ha ora un indirizzo IP dedicato.

Per modificare la password di accesso al server, cliccare su "Cambia", come mostrato nella schermata sopra. Ecco come impostare una password per accedere al server.
Ora sai indirizzo IP del server, Accedere ( radice) e parola d'ordine.

Configurazione dei client SSH

Per Windows

Per connettersi al server è necessario un client SSH. Se è necessario connettersi rapidamente, si consiglia Putty. Se hai bisogno di lavorare con utility unix come scp, rsync e ssh-copy-id, usa Cygwin.

Putty o come connettersi rapidamente a SSH da Windows

Scarica il programma di installazione di Putty per Windows dalla sezione L'ultima versione di rilascio e installa Putty con le impostazioni predefinite.

Avvia Putty (Start -> Tutte le applicazioni -> PuTTY -> PuTTY).

Immettere l'indirizzo IP del server. Assicurati che la porta 22 sia selezionata e che il tipo di connessione sia SSH e fai clic su "Apri".

Ti verrà chiesto se ti fidi del server a cui ti stai connettendo. Devi rispondere "Sì".

Si aprirà una finestra di connessione. Usa root come login e la password del tuo server come password. La password può essere incollata dagli appunti con il tasto destro del mouse. Non viene visualizzato durante la digitazione e l'incollaggio per motivi di sicurezza.

La connessione è stata stabilita con successo.

Cygwin o ambiente Unix sul tuo computer Windows

Quando lavori con server Linux, potresti aver bisogno di un ambiente simile sul tuo computer. È molto comodo utilizzare lo stesso set di utilità sul server e sul computer di lavoro, quindi assicurati di provare Cygwin. Linux sembra complicato a prima vista. Padroneggiando gradualmente questo sistema operativo, avrai sempre più bisogno di Cygwin. Buona dipendenza.

Connessione Internet instabile durante la connessione tramite SSH: cosa fare?

Spesso, quando si lavora su una rete instabile (ad esempio tramite Internet mobile 3G/4G o vari punti di accesso WiFi), la connessione SSH viene interrotta. Diamo un'occhiata a cosa si può fare a livello di client per evitare la necessità di riconnessione. Questi strumenti non sono adatti per eseguire operazioni critiche sul server (ad esempio, l'aggiornamento del sistema operativo). Per eseguire operazioni critiche, è necessario utilizzare anche le utilità descritte nella sezione successiva dell'articolo. Lo scopo delle utilità in questa sezione è di rendere il lavoro SSH più conveniente per l'utente.

AutoSSH

AutoSSH avvia una copia del client ssh e monitora la connessione, riavviando il client ssh se necessario.

Autossh utilizza ssh per creare un loop di reindirizzamento ssh (collegandosi da locale a remoto e viceversa) e inoltra i dati di test, aspettandosi che tornino. Supporta anche l'utilizzo di un servizio di eco remoto per inviare i dati di test.

AutoSSH supporta solo 3 parametri:

• -M<порт>[: porta eco]- utilizzato per specificare la porta di monitoraggio o la porta di monitoraggio e la porta del servizio eco. Se la porta del servizio echo non è specificata, viene utilizzato il numero di porta successivo. Ad esempio, se è impostato il flag -M 20000, i dati di test verranno inviati sulla porta 20000 e ricevuti sulla porta 20001. Se si specifica -M 0, il monitoraggio della connessione sarà disabilitato e autossh riavvierà ssh solo all'uscita da ssh (si puoi usarlo con le opzioni ServerAliveInterval e ServerAliveCountMax in OpenSSH se il monitoraggio non può essere utilizzato nella tua situazione);
• -F- invia autossh in background anche prima di avviare ssh (non è possibile inserire una password in questa modalità);
• -V- visualizza la versione di autossh.

Tutti gli altri argomenti vengono passati come parametri ssh.

Per evitare di dover inserire nuovamente la password quando si ripristina la connessione, consentire a questo utente di accedere al server utilizzando la chiave, come mostrato nella sezione precedente.

Installazione di AutoSSH in Cygwin su Windows

Quando si utilizza Cygwin su Windows, immettere:
aggiornamento apt-cyg
apt-cyg installa autossh

Ora puoi connetterti al server:
autossh -M 20000 [e-mail protetta] _indirizzo del server


La connessione è stata stabilita con successo.

In generale, autossh è uno strumento abbastanza conveniente per lavorare su connessioni Internet instabili e per organizzare tunnel ssh sul server (prenderemo in considerazione questo scenario in un articolo separato). Lo svantaggio di autossh è che questa utility non risolve il problema se si verificano ritardi significativi al momento dell'immissione dei comandi sulla rete (cosa che accade su una rete 3G). In questo caso, aspetterai una risposta dal server per inserire ogni carattere, il che rallenta un po' il lavoro. Tuttavia, in condizioni operative normali, autossh è molto utile per mantenere una connessione ssh.

Mosh risolve la possibilità di inserire comandi senza attendere la risposta del server, ma la compatibilità di questa utility è ancora molto limitata e la sua affidabilità è bassa, quindi non è consigliabile utilizzarla ancora.

Come eseguire operazioni server critiche e dispendiose in termini di tempo: multiplexer di terminali

Se stai aggiornando il sistema operativo, installando del software o semplicemente modificando un file sul server, dopo esserti connesso tramite ssh o autossh, non lavorare direttamente. Se la connessione SSH viene interrotta, perderai la sessione avviata durante la connessione tramite SSH. Per evitare che ciò accada e quando ti riconnetterai tramite SSH, ti ritroverai sicuramente in un'operazione in corso sul server o in una finestra di modifica di file aperta dallo stesso momento, usa i multiplexer di terminale sul server: GNU Screen o tmux.

Schermata GNU

Screen è stato originariamente progettato per eseguire più sessioni di terminale all'interno di un singolo terminale. Tuttavia, lo schermo ha un'altra proprietà utile: la capacità di staccare sessioni virtuali da un terminale fisico e collegarsi a un altro. Questo, in particolare, consente di eseguire processi di lunga durata su macchine remote, senza la necessità di essere costantemente connessi ad esse.

1. Accedi al server remoto tramite SSH.
2. Esegui la schermata lì
3. Vedrai un saluto, premi Invio.
4. Ora puoi fare quello che vuoi come se fossi appena connesso al server tramite SSH (ad esempio, avviare un processo lungo).
5. È possibile disconnettere la sessione premendo CTRL + a poi d. Puoi anche terminare la connessione SSH al server.
6. Per tornare alla sessione, riconnettiti tramite SSH (o lo farà autossh) e accedi alla schermata -r
Verrai riportato alla sessione in esecuzione e il processo avviato in precedenza continua in essa. Analizzeremo più in dettaglio i multiplexer terminali negli articoli successivi.

Conclusione

In questo articolo, abbiamo cercato di coprire le nozioni di base necessarie per familiarizzare con SSH da diversi sistemi operativi. Naturalmente, questo non è tutto ciò che è possibile, ma una buona base per iniziare. Se trovi un errore nell'articolo, pensi di dover aggiungere qualcosa di importante o hai solo una domanda -

SSH (Secure Shell) è un protocollo di rete progettato per controllare in remoto un server e trasferire dati su connessioni TCP crittografate. La maggior parte dei siti di hosting, anche virtuali, oggi fornisce sia l'accesso FTP che SSH. A mio parere, questo è fantastico, SSH è molto più comodo e sicuro da usare.

Configurazione di SSH

La configurazione verrà eseguita 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 (stiamo apportando modifiche ad esso) non necessita di alcuna impostazione e funziona correttamente. Apportiamo solo un paio di piccole modifiche per limitare l'accesso al server di persone indesiderate.

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

Come limitare l'accesso SSH

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

Cambia porta

Porta 9724

Ora, quando si autorizza, è necessario specificare 9724 invece della porta 22 standard.
Il metodo è molto semplice ed efficace contro la maggior parte dei semplici bot di hacker che bussano alle porte standard. La cosa principale qui è non creare un conflitto con altri servizi e raccogliere un numero deliberatamente inutilizzato.

Nega la comunicazione utilizzando il vecchio protocollo

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

Se non sei loggato sotto radice, prima di tutti i comandi della console devi aggiungere sudo - sta per Sostituisci utente e DO- cambia l'utente e fai (sotto di esso). Ad esempio, ti consente di eseguire comandi per conto del superutente radice.

Riduci il numero di tentativi di autorizzazione

MaxAuthTries 2

Il numero di tentativi di immissione della password. Per impostazione predefinita 6. Se la ricerca non riesce, la sessione di comunicazione viene terminata.

Riduci il timeout di autorizzazione

AccediGraceTime 30s

Per impostazione predefinita, una sessione di autorizzazione può richiedere 120 secondi. Alla fine di questo tempo, si interrompe. 2 minuti per l'autorizzazione sono troppi, per tutto questo tempo il server mantiene la connessione aperta, il che è molto irrazionale. Mezzo minuto è sufficiente per gli occhi.

Chiudi accesso IP

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

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

   dove 192.168.1.1 è il tuo IP. Se hai un IP dinamico, definisci un IP con una subnet mask e annota 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 permettiamo l'accesso solo per IP 1.2.3.4

Autorizzazione chiave SSH

Sarà molto più sicuro, conveniente e corretto configurare l'autorizzazione ssh senza password. L'autorizzazione chiave verrà utilizzata per questo.

Quindi ecco l'istruzione:

La connessione è impostata. Se hai fatto qualcosa di sbagliato, il server ha rifiutato il nostro errore di chiave apparirà durante l'autorizzazione, cioè Il server non ha accettato la nostra chiave... In questo caso, esamina tutti i punti in sequenza e cerca un errore.

abstract: questo articolo descrive le funzionalità avanzate di OpenSSH che rendono la vita molto più semplice agli amministratori di sistema e ai programmatori che non hanno paura della shell. A differenza della maggior parte dei manuali, che non descrivono nulla oltre agli interruttori e alle opzioni -L / D / R, ho cercato di raccogliere tutte le caratteristiche e le comodità interessanti che ssh porta con sé.

Attenzione: post molto voluminoso, ma per facilità d'uso, ho deciso di non tagliarlo a pezzi.

Sommario:

• gestione delle chiavi
• copiare file su ssh
• Inoltro flussi I/O
• Monta FS remoti tramite ssh
• Esecuzione del codice remoto
• Alias ​​e opzioni per le connessioni in .ssh / config
• Opzioni predefinite
• Inoltro al server X
• ssh come calzini-proxy
• Port Forwarding - Avanti e indietro
• Reverse Sox Proxy
• tunneling traffico L2/L3
• Agente di autorizzazione inoltro
• Tunneling ssh su ssh attraverso un server non attendibile ( molto probabilmente non lo sai)

Gestione delle chiavi

Teoria in poche parole: ssh può accedere non tramite password, ma tramite chiave. La chiave è composta da una parte aperta e da una chiusa. Quello aperto viene messo nella home directory dell'utente "chi" accede al server, quello chiuso - nella home directory dell'utente che va al server remoto. Le metà vengono confrontate (esagero) e se tutto è ok, lasciano perdere. Importante: non solo il client è autorizzato sul server, ma anche il server in relazione al client (cioè il server ha una propria chiave). La caratteristica principale della chiave rispetto alla password è che non può essere "rubata" hackerando il server: la chiave non viene trasferita dal client al server e durante l'autorizzazione il client dimostra al server di possedere la chiave (la stessa magia crittografica).

Generazione chiave

Puoi generare la tua chiave usando il comando ssh-keygen. Se non imposti i parametri, salverà tutto come dovrebbe.

La chiave può essere chiusa con una password. Questa password (nelle interfacce grafiche convenzionali) viene richiesta una volta e conservata per un po' di tempo. Se la password è vuota, non verrà richiesta durante l'utilizzo. È impossibile recuperare una password dimenticata.

Puoi cambiare la password di una chiave usando il comando ssh-keygen -p.

Struttura chiave

(se la risposta alla domanda sulla posizione è stata predefinita).
~ / .ssh / id_rsa.pub- chiave pubblica. Viene copiato sui server in cui è necessario ottenere l'accesso.
~ / .ssh / id_rsa- chiave privata. Non deve essere mostrato a nessuno. Se lo copi e incolli in una lettera/chat invece che in un pub, devi generare una nuova chiave. (Non sto scherzando, circa il 10% delle persone a cui viene chiesto di fornire il post chiave ssh id_rsa, e di questi dieci percento sono maschi, 100%).

Copiare la chiave sul server

Nella directory dell'utente in cui si desidera accedere, se si crea un file ~ / .ssh / chiavi_autorizzate e inserisci lì la chiave pubblica, quindi puoi accedere senza password. Tieni presente che i permessi sul file non dovrebbero consentire agli utenti non autorizzati di scrivere su questo file, altrimenti ssh non lo accetterà. Nella chiave, l'ultimo campo è [e-mail protetta] Non ha nulla a che fare con l'autorizzazione e serve solo per la comodità di determinare dove si trova la chiave. Si noti che questo campo può essere modificato (o addirittura eliminato) senza interrompere la struttura della chiave.

Se conosci la password dell'utente, il processo può essere semplificato. Squadra ssh-copy-id [e-mail protetta] consente di copiare la chiave senza modificare manualmente i file.

Nota: i vecchi manuali di ssh menzionano authorized_keys2. Motivo: c'era la prima versione di ssh, poi c'era la seconda (attuale), hanno creato il proprio set di configurazioni per questo, tutti erano molto stanchi e la seconda versione è passata alle versioni senza "2" molto tempo fa . Cioè, sempre authorized_keys e non pensare a versioni diverse.

Se hai ssh su una porta non standard, allora ssh-copy-id richiede un po' di trucchi: ssh-copy-id "-p 443 [e-mail protetta]"(attenzione alle virgolette).

Chiave del server

La prima volta che accedi al server, ssh ti chiede se ti fidi della chiave. Se rispondi no, la connessione viene chiusa. Se sì, la chiave viene salvata in un file ~ / .ssh / host_noti... Scopri dove non può essere la chiave (perché non è segreta).

Se la chiave del server è cambiata (ad esempio, il server è stato reinstallato), ssh urla di aver falsificato una chiave. Tieni presente che se il server non è stato toccato e ssh urla, stai entrando nel server sbagliato (ad esempio, un altro computer con lo stesso IP è apparso sulla rete, tutti i tipi di reti locali con 192.168.1.1, di cui sono diversi milioni nel mondo, ne soffrono soprattutto) ... Lo scenario di "Evil Man in the Middle Attack" è improbabile, più spesso si tratta solo di un errore con l'IP, anche se se "va tutto bene" e la chiave è cambiata, questo è un motivo per alzare il livello di paranoia di un un paio di livelli (e se si dispone dell'autorizzazione chiave e il server ha chiesto improvvisamente una password, la paranoia può essere attivata al 100% e la password non deve essere inserita).

Puoi rimuovere la chiave del server nota con il comando ssh-keygen -R server... In questo caso, è necessario eliminare anche la chiave IP (vengono archiviate separatamente): ssh-keygen -R 127.0.0.1.

La chiave del server è memorizzata in / etc / ssh / ssh_host_rsa_key e /etc/ssh/ssh_host_rsa_key.pub... Possono essere:
a) copia dal vecchio server al nuovo.
b) generare con ssh-keygen. Non è necessario impostare una password (ovvero vuota). Il server ssh non può utilizzare la chiave con la password.

Nota, se cloni i server (ad esempio, nelle macchine virtuali), le chiavi ssh del server devono essere rigenerate.

Allo stesso tempo, è meglio rimuovere le vecchie chiavi da know_hosts, altrimenti ssh giurerà sulla chiave duplicata.

Copiare file

Il trasferimento di file sul server a volte può essere noioso. Oltre a giocherellare con sftp e altre cose strane, ssh ci dà il comando scp che copia un file su una sessione ssh.

Percorso scp / miofile [e-mail protetta]: / completo / percorso / a / nuovo / posizione /

Puoi anche fare il contrario:
scp [e-mail protetta]: / completo / percorso / a / file / percorso / a / metti / qui

Avviso pesce: nonostante il fatto che mc possa connettersi tramite ssh, copiare file di grandi dimensioni sarà molto doloroso. fish (il modulo mc per lavorare con ssh come fs virtuali) è molto lento. 100-200kb è il limite, poi inizia la prova della pazienza. (Mi sono ricordato della mia primissima giovinezza, quando, non sapendo di scp, ho copiato ~ 5 GB tramite fish su mc, ci sono volute poco più di 12 ore su FastEthernet).

La capacità di copiare è eccezionale. Ma vuoi "salvare con nome" - e immediatamente sul server. E per copiare in modalità grafica non da un programma speciale, ma da uno familiare.

Questo è anche possibile:

sshfs

Teoria: il modulo fuse consente di "esportare" le richieste al filesystem dal kernel nello spazio utente per il programma appropriato. Ciò semplifica l'implementazione di "pseudo-file system". Ad esempio, possiamo fornire l'accesso a un file system remoto tramite ssh in modo che tutte le applicazioni locali (con poche eccezioni) non sospettino nulla.

In realtà, l'eccezione: O_DIRECT non è supportata, purtroppo (questo non è un problema con sshfs, è un problema di fusibili in generale).

Utilizzo: installa il pacchetto sshfs (porterà il fusibile stesso).

In realtà, un esempio del mio script che monta desunote.ru (che si trova sul mio computer di casa - le immagini sono mostrate da esso in questo articolo) sul mio laptop:

#! / bin / bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

Facciamo un file + x, lo chiamiamo, andiamo a qualsiasi applicazione, diciamo salva e vediamo:

Opzioni Sshfs che possono essere importanti: -o reconnect (dice di provare a riconnettersi invece di errori).

Se lavori molto con i dati di root, puoi (necessità) creare una mappa id:

-o idmap = utente... Funziona come segue: se ci colleghiamo come utente [e-mail protetta], e localmente lavoriamo come utente vasiliy, quindi diciamo "considera che i file pupkin sono file vasiliy". beh, o "root" se ci colleghiamo come root.

Nel mio caso, idmap non è necessario, poiché i nomi utente (locale e remoto) sono gli stessi.

Nota che risulta funzionare comodamente solo se abbiamo una chiave ssh (vedi l'inizio dell'articolo), in caso contrario, l'autenticazione della password richiede 2-3 connessioni.

Puoi spegnerlo di nuovo con il comando fusermount -u / percorso, tuttavia, se la connessione è bloccata (ad esempio, non esiste una rete), puoi / devi farlo da sotto la radice: sudo umount -f / path.

Esecuzione del codice remoto

ssh può eseguire un comando su un server remoto e chiudere immediatamente la connessione. Esempio più semplice:

Ssh [e-mail protetta] ls / ecc /

Verrà visualizzato il contenuto di / etc / sul server, mentre avremo una riga di comando locale.

Alcune applicazioni richiedono un terminale di controllo. Dovrebbero essere eseguiti con l'opzione -t:
ssh [e-mail protetta]-t remove_command

A proposito, possiamo fare qualcosa del genere:
ssh [e-mail protetta] cat / some / file | awk "(print $ 2)" | local_app

Questo ci porta alla seguente caratteristica:

Stdin / inoltro in uscita

Diciamo che vogliamo fare una richiesta al programma in remoto, e poi mettere il suo output in un file locale

Ssh [e-mail protetta] comando> mio_file

Diciamo che vogliamo mettere l'output locale in remoto

Il mio comando | scp - [e-mail protetta]: / percorso / file_remoto

Complichiamo l'esempio: possiamo trasferire file dal server al server: creiamo una catena per mettere stdin su 10.1.1.2, che non è disponibile per noi dall'esterno:

Il mio comando | ssh [e-mail protetta]"Scp- [e-mail protetta]: / percorso / a / file "

C'è anche un metodo così ridicolo di usare una pipe (gentilmente suggerito nei commenti in LJ):

Tar -c * | ssh [e-mail protetta]"cd && tar -x"

Tar comprime i file per maschera localmente, li scrive su stdout, da dove ssh li legge, li trasferisce a stdin sul server remoto, dove cd li ignora (non legge stdin) e tar li legge e li decomprime. Scp è per i poveri, per così dire.

alias

Francamente, fino a poco tempo non lo conoscevo e non lo usavo. Si è rivelato molto comodo.

In un'azienda più o meno grande, spesso si scopre che i nomi dei server hanno questo aspetto: spb-MX-i3.extrt.int.company.net. E l'utente non è uguale a quello locale. Cioè, devi accedere in questo modo: ssh [e-mail protetta] Digitando ogni volta - non ne hai mai abbastanza delle sindromi del tunnel. Nelle piccole aziende, il problema è l'opposto: nessuno pensa al DNS e la chiamata al server si presenta così: ssh [e-mail protetta] In breve, ma ancora fastidioso. Ancora più drammatico se abbiamo una porta non standard e, ad esempio, la prima versione di ssh (ciao cisks). Quindi tutto sembra così: ssh -1 -p 334 [e-mail protetta] Strangolati. Non voglio nemmeno parlare del dramma scp.

È possibile registrare alias a livello di sistema per IP (/ etc / hosts), ma questa è una via d'uscita storta (e stampare comunque l'utente e le opzioni).

File ~ / .ssh / config consente di impostare i parametri di connessione, inclusi quelli specifici per i server, che è più importante, per ogni server il suo. Ecco un esempio di configurazione:

Host ric Nome host ooo-roga-i-kopyta.rf Amministratore utente ForwardX11 sì Compressione sì Home host Nome host myhome.dyndns.org Utente vasya PasswordAuthentication no

Tutte le opzioni disponibili per l'uso possono essere visualizzate in man ssh_config(da non confondere con sshd_config).

Opzioni predefinite

Come richiesto da UUSER: è possibile specificare le impostazioni di connessione predefinite utilizzando il costrutto Host *, ad esempio:

Host * Compressione root utente sì

Lo stesso può essere fatto in /etc/ssh/ssh_config (da non confondere con /etc/ssh/ssh D _config), ma questo richiede i diritti di root e si applica a tutti gli utenti.

Inoltro al server X

In realtà, ho rovinato un po' questa parte nella configurazione di esempio sopra. ForwardX11 è proprio questo.

Teoria: le applicazioni grafiche Unix di solito usano un server X (wayland è in arrivo, ma non è ancora pronto). Ciò significa che l'applicazione si avvia e si connette al server X per disegnare. In altre parole, se hai un server nudo senza gui e hai un x-server locale (in cui lavori), puoi abilitare le applicazioni dal server per disegnare sul tuo desktop. Di solito connettersi a un server X remoto non è la cosa più sicura e banale. SSH semplifica questo processo e lo rende completamente sicuro. E la capacità di raccogliere traffico ti consente anche di cavartela con meno traffico (ovvero ridurre l'utilizzo del canale, ovvero ridurre il ping (più precisamente, la latenza), ovvero ridurre i ritardi).

Chiavi: -X - inoltro del server X. -Y inoltro autorizzazione.

È abbastanza facile ricordare la combinazione ssh -XYC [e-mail protetta]
Nell'esempio sopra (i nomi delle società sono fittizi), mi collego al server ooo-roga-and-hooves.rf per un motivo, ma per ottenere l'accesso al server Windows. Conosciamo tutti la sicurezza di Microsoft quando si lavora in rete, quindi esporre il nudo RDP all'esterno è scomodo. Invece, ci colleghiamo al server tramite ssh, quindi eseguiamo il comando rdesktop lì:
ssh ric
rdesktop -k it-us 192.168.1.1 -g 1900x1200

E miracolo, la finestra di login in Windows sul nostro desktop. Nota, è accuratamente crittografato e indistinguibile dal normale traffico ssh.

calzini-proxy

Quando mi trovo in un altro hotel (bar, conferenza), il wifi locale si rivela spesso terribile: porti chiusi, nessuno sa quale livello di sicurezza. Sì, e non c'è molta fiducia nei punti di accesso di altre persone (questa non è paranoia, ho visto abbastanza come vengono portati password e cookie usando un laptop banale, distribuendo 3G a tutti con il nome di un bar vicino (e scrivendo cose interessanti nel processo)).

Le porte chiuse sono un problema particolare. Quel jabber verrà chiuso, quindi IMAP, quindi qualcos'altro.

Una normale VPN (pptp, l2tp, openvpn) non funziona in tali situazioni: semplicemente non è consentita. È noto sperimentalmente che la porta 443 viene spesso lasciata e nella modalità CONNECT, ovvero viene passata "così com'è" (il normale http può ancora essere avvolto in modo trasparente su un calamaro).

La soluzione è calzini-proxy modalità operativa ssh. Il suo principio: il client ssh si connette al server e ascolta localmente. Ricevuta la richiesta, la invia (tramite connessione aperta) al server, il server stabilisce una connessione in base alla richiesta e rimanda tutti i dati al client ssh. E risponde alla persona che ha fatto domanda. Per funzionare, devi dire alle applicazioni "usa calze-proxy". E specifica l'indirizzo IP del proxy. Nel caso di ssh, questo è molto spesso localhost (in questo modo non darai il tuo canale a estranei).

La connessione in modalità sock-proxy ha il seguente aspetto:
ssh -D 8080 [e-mail protetta]

A causa del fatto che il wifi di altre persone è spesso non solo fig, ma anche lento, potrebbe essere utile abilitare l'opzione -C (comprimere il traffico). Risulta quasi come l'opera turbo (solo le immagini non sono troppo strette). Nella vera navigazione su http preme circa 2-3 volte (leggi - se hai una sfortuna di 64kbit, allora aprirai pagine di megabyte non in due minuti, ma in 40 secondi. Fa schifo, ma è meglio). Ma soprattutto: nessun cookie rubato o sessioni ascoltate.

Non invano ho parlato di porti chiusi. La 22a porta è chiusa esattamente allo stesso modo della porta jabber "non necessaria". La soluzione è appendere il server sulla porta 443. Non dovresti sparare con 22, a volte ci sono sistemi con DPI (Deep Packet Inspection) che il tuo "pseudo-ssl" non ti farà entrare.

Ecco come appare la mia configurazione:

/etc/ssh/sshd_config:
(frammento)
Porta 22
Porta 443

Ed ecco un pezzo di ~ / .ssh / config da un laptop che descrive vpn

Host VPN Nome host desunote.ru Utente vasya Compressione sì DynamicForward 127.1: 8080 Porta 443

(notare la notazione "pigro" localhost - 127.1, questo è un modo perfettamente legale per scrivere 127.0.0.1)

Port forwarding

Passiamo a una parte estremamente difficile da comprendere della funzionalità SSH, che consente di eseguire complicate operazioni di tunneling TCP "dal server" e "al server".

Per comprendere la situazione, tutti gli esempi seguenti faranno riferimento a questo diagramma:

Commenti: due reti grigie. La prima rete assomiglia a una tipica rete d'ufficio (NAT), la seconda è un "gateway", ovvero un server con un'interfaccia bianca e grigia che esamina la propria rete privata. In quanto segue, assumiamo che il "nostro" laptop sia A e che il "server" sia B.

Compito: abbiamo un'applicazione in esecuzione localmente, dobbiamo consentire a un altro utente (al di fuori della nostra rete) di guardarla.

Soluzione: inoltrare la porta locale (127.0.0.1:80) a un indirizzo accessibile pubblicamente. Diciamo che la nostra B "pubblicamente disponibile" ha occupato la porta 80 con qualcosa di utile, quindi la inoltreremo a una porta non standard (8080).

Configurazione finale: le richieste per 8.8.8.8:8080 andranno al localhost del laptop A.

Ssh -R 127.1: 80: 8.8.8.8: 8080 [e-mail protetta]

Opzione -R consente il reindirizzamento da remoto ( R emote) alla tua porta (locale).
Importante: se vogliamo utilizzare l'indirizzo 8.8.8.8, dobbiamo abilitare GatewayPorts nelle impostazioni del server B.
Compito... Sul server "B" è in ascolto un determinato demone (ad esempio sql-server). La nostra applicazione non è compatibile con il server (diversi bit, OS, admin male, vietando e imponendo limiti, ecc.). Vogliamo accedere localmente al localhost remoto "y.

Configurazione finale: le richieste a localhost: 3333 su "A" dovrebbero essere servite da un demone su localhost: 3128 "B".

Ssh -L 127.1: 3333: 127.1: 3128 [e-mail protetta]

Opzione -L consente le chiamate locali ( l ocal) da inviare al server remoto.

Compito: Sul server "B" un certo servizio è in ascolto sull'interfaccia grigia e vogliamo dare a un collega (192.168.0.3) l'opportunità di guardare questa applicazione.

Configurazione finale: le richieste per il nostro indirizzo IP grigio (192.168.0.2) vanno all'interfaccia grigia del Server B.

Ssh -L 192.168.0.2:8080:10.1.1.1:80 [e-mail protetta]

Tunnel nidificati

I tunnel possono ovviamente essere reindirizzati.

Complichiamo il compito: ora vogliamo mostrare a un collega un'applicazione in esecuzione su localhost sul server con l'indirizzo 10.1.1.2 (sulla porta 80).

La soluzione è complicata:
ssh -L 192.168.0.2:8080:127.1:9999 [e-mail protetta] ssh -L 127.1: 9999: 127.1: 80 [e-mail protetta]

Cosa sta succedendo? Diciamo a ssh di reindirizzare le richieste locali dal nostro indirizzo al localhost del server B e subito dopo la connessione, avvia ssh (ovvero un client ssh) sul server B con l'opzione di ascoltare su localhost e inviare richieste al server 10.1.1.2 ( dove il client dovrebbe connettersi). La porta 9999 viene scelta arbitrariamente, l'importante è che corrisponda alla prima chiamata e alla seconda.

Reverse Sox Proxy

Se l'esempio precedente ti è sembrato semplice e ovvio, prova a indovinare cosa farà questo esempio:
ssh -D 8080 -R 127.1: 8080: 127.1: 8080 [e-mail protetta] ssh -R 127.1: 8080: 127.1: 8080 [e-mail protetta]

Se sei un addetto alla sicurezza il cui compito è vietare l'uso di Internet sul server 10.1.1.2, puoi iniziare a tirarti i capelli sul sedere, perché questo comando organizza l'accesso a Internet per il server 10.1.1.2 tramite un proxy sox in esecuzione sul computer "A". Il traffico è completamente crittografato e indistinguibile da qualsiasi altro traffico SSH. E il traffico in uscita dal computer dal punto di vista della rete 192.168.0/24 è indistinguibile dal normale traffico del computer A.

Tunneling

Se a questo punto il prete del dipartimento di sicurezza non è calvo, e ssh non è ancora elencato come il nemico numero uno della sicurezza, ecco il killer definitivo di tutto e tutti: tunneling IP o persino ethernet. Nei casi più radicali, ciò consente il tunneling DHCP, lo spoofing remoto dell'arp, il risveglio su lan e altre bruttezze di secondo livello.

(Io stesso, purtroppo, non l'ho usato).

È facile capire che in tali condizioni è impossibile per qualsiasi DPI (ispezione approfondita dei pacchetti) catturare tali tunnel - o ssh è consentito (leggi - fai quello che vuoi) o ssh è proibito (e puoi tranquillamente lasciare un tale compagnia di idioti senza provare il minimo rimpianto).

Inoltro dell'autorizzazione

Se pensi che questo sia tutto, allora ... ... tuttavia, a differenza dell'autore, il cui "fondo" non è stato ancora scritto, il lettore vede in anticipo che ci sono molte lettere sotto e non c'è intrigo.

OpenSSH consente di utilizzare i server come trampolino di lancio per connettersi ad altri server, anche se tali server non sono affidabili e possono essere abusati in qualsiasi modo desiderino.

Ripeto la foto:

Diciamo che vogliamo connetterci al server 10.1.1.2, che è pronto ad accettare la nostra chiave. Ma non vogliamo copiarlo in 8.8.8.8, perché c'è un passaggio e metà delle persone ha sudo e può navigare nelle directory di altre persone. Un compromesso sarebbe avere una chiave ssh "diversa" che autorizzi [e-mail protetta] il 10.1.1.2, ma se non vogliamo permettere a nessuno di passare da 8.8.8.8 a 10.1.1.2, allora questa non è un'opzione (soprattutto perché la chiave non può solo essere usata, ma anche copiata da soli "per un giorno di pioggia ").

Ssh offre la possibilità di inoltrare l'agente ssh (questo è un servizio che richiede una password per una chiave). Opzione ssh -A inoltra l'autorizzazione a un server remoto.

La chiamata si presenta così:

Ssh -A [e-mail protetta] ssh [e-mail protetta]

Il client ssh remoto (su 8.8.8.8) può dimostrare a 10.1.1.2 che siamo noi solo se siamo connessi a questo server e abbiamo dato al client ssh l'accesso al suo agente di autorizzazione (ma non la chiave!).

La maggior parte delle volte funziona.

Tuttavia, se il server è davvero difettoso, la radice del server può utilizzare il socket per impersonare quando siamo connessi.

Esiste un metodo ancora più potente: trasforma ssh in una semplice pipe (nel senso di "pipe") attraverso la quale lavoriamo fino in fondo con un server remoto.

Il vantaggio principale di questo metodo è la completa indipendenza dal server proxy. Può usare un falso server ssh, registrare tutti i byte e tutte le azioni, intercettare tutti i dati e falsificarli come vuole - l'interazione va tra il server "finale" e il client. Se i dati sul server terminal vengono manomessi, la firma non convergerà. Se i dati non vengono manomessi, allora la sessione viene stabilita in modalità sicura, quindi non c'è nulla da intercettare.

Non conoscevo questa fantastica ambientazione, quindi ho scoperto il suo redrampage.

La configurazione è legata a due caratteristiche di ssh: l'opzione -W (trasforma ssh in una "pipa") e l'opzione config Comando Proxy(opzioni della riga di comando, a quanto pare, no), che dice "esegui il programma e attieniti al suo stdin / out". Queste opzioni sono apparse di recente, quindi gli utenti di centos sono fuori questione.

Assomiglia a questo (numeri per l'immagine sopra):

Ssh / configurazione:
Host raep HostName 10.1.1.2 Utente user2 ProxyCommand ssh -W% h:% p [e-mail protetta]

Bene, la connessione è banale: ssh raep.

Ancora una volta, un punto importante: il server 8.8.8.8 non può intercettare o falsificare il traffico, utilizzare un agente di autorizzazione utente o alterare il traffico in altro modo. Nega - sì, può. Ma se consentito, passerà attraverso se stesso senza decrittazione o modifica. Affinché la configurazione funzioni, devi avere la tua chiave pubblica in authorized_keys come per [e-mail protetta] e in [e-mail protetta]

Naturalmente, la connessione può essere dotata di tutte le altre bauble: port forwarding, copia di file, proxy sox, tunnel L2, tunneling di X-server, ecc.
ssh tunneling aggiungi tag