Cum se configurează smartphone-uri și PC-uri. Portal informativ
  • Acasă
  • Windows 7, XP
  • Cum se configurează și se utilizează portul SSH? Instrucțiuni pas cu pas. Conectarea la un server virtual prin SFTP

Cum se configurează și se utilizează portul SSH? Instrucțiuni pas cu pas. Conectarea la un server virtual prin SFTP

Gazduire cu acces ssh Probabil că nu atât de comun, cel puțin din experiența mea. Cea mai recentă găzduire a mea acceptă SSH și am decis să o încerc și am avut un motiv întemeiat să o fac. Problema este că găzduirea mea actuală nu arată în detaliu dimensiunea fișierelor.

Nici prin clientul FTP nu o puteți vedea, dar am mare nevoie de el, pentru că spațiul de găzduire s-a epuizat rapid și trebuie să scot tot gunoiul pentru a nu cumpăra megaocteți suplimentari și a nu plăti prea mult. Și mai recent, site-urile mele au fost infectate și aș fi fost imposibil fără acces ssh.

Aș fi știut că găzduirea mea nu suportă o funcție atât de simplă, m-am gândit de o sută de ori dacă să trec la ea sau nu. Dar găzduirea a avut recenzii bune și mi-am cumpărat un loc pe ea timp de doi ani deodată. Dar din moment ce are ssh, cred că problema este rezolvabilă. Deci, găzduire SSH, cum o puteți folosi?

Ce este găzduirea cu acces ssh?

Dar mai întâi, voi vorbi despre ce este SSH, deoarece poate nu toată lumea știe ce fel de animal este. Pe scurt, conform Wikipedia este:

SSH (ing. Secure SHell - „secure shell”) este un protocol de rețea la nivel de aplicație care vă permite să controlați de la distanță sistemul de operare și conexiunile TCP de tunel (de exemplu, pentru a transfera fișiere). SSH permite alegerea diferiților algoritmi de criptare. Clienții SSH și serverele SSH sunt disponibile pentru majoritatea sistemelor de operare în rețea.

Puteți lucra cu ssh direct prin terminal folosind comenzi Linux. Conectarea la server este foarte ușoară, trebuie să tastați o comandă în următorul format:

ssh nume utilizator@adresa_server

După cum puteți vedea, totul este foarte simplu. Voi încerca să mă conectez prin ssh la găzduirea mea. Dar nu a fost acolo, hostingul cu încăpăţânare nu a vrut să mă accepte sub acest protocol. Am scris serviciului de asistență și acum aștept un răspuns.

Între timp, vă voi spune cât de convenabil este să vă conectați prin ssh prin managerul de fișiere Nautilus. Conectându-vă la acesta prin SSH, veți lucra cu fișierele care se află pe găzduire ca și cum ar fi pe computerul dvs. Deschideți Nautilus și apăsați Ctrl + L, astfel încât să puteți scrie calea către serverul ssh în bara de adrese:

sftp:// [email protected]

Apoi vi se va cere să introduceți o parolă și veți vedea toate fișierele dvs. în managerul de fișiere. Acestea sunt avantajele găzduirii cu ssh.

Prin urmare, atunci când alegeți găzduirea, acordați atenție acestui lucru. Ale mele Gazduire IHOR dă acces la SSH și de aceea îl folosesc de câțiva ani...

SFATUL WEBMASTER: Capacitatea de a face bani pe Internet este doar jumătate din luptă, a doua jumătate este capacitatea de a încasa FAVORĂ bani electronici. Iată o listă de carduri bancare offshore din care puteți retrage fonduri și apoi să retrageți facturi crocante de pe ele:

1. plătitor- Cel mai popular sistem de plată din lume pentru freelanceri. Emite carduri, situate în SUA.

2. EpayService- Sistemul de plată american, foarte popular în multe țări, oferă un card MasterCard în EVRO gratuit pentru rezidenții CSI și Europa.

3. Skrill- Singurul sistem de plată care funcționează cu criptomonede și în același timp emite carduri bancare MasterCard gratuite.

4. AdvCash- O bancă offshore este situată în Belize, puteți deschide un cont în dolari, euro, lire sterline și ruble.

5. plătitor- Sediul acestui sistem de plată este situat în Georgia, aici puteți deschide și un cont în dolari, euro și ruble.


Domeniul RU - 99 de ruble
Domeniul RF - 99 de ruble

SSH (Secure Shell) este un protocol de rețea de acces la distanță care utilizează criptarea și compresia pentru datele transmise. Mai simplu spus, acesta este un instrument foarte util și puternic care vă permite să vă autentificați în sistem și să lucrați pe deplin în numele unui utilizator local, fiind la mulți kilometri distanță de o mașină care rulează. De asemenea, spre deosebire de telnet și rsh, SSH criptează tot traficul, astfel încât toate informațiile transmise rămân confidențiale.

Deci, avem deja ssh instalat și ssh-daemon este adăugat la încărcarea automată la pornirea sistemului. Îl poți controla cu comanda:

service ssh stop|start|restart

Pe Ubuntu sau:

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

Pe Debian sau:

systemctl start|stop|reporniți sshd.service

În ArchLinux (după fiecare editare a configurației, trebuie să reporniți). Pachetul include un client și un server.

Să încercăm în acțiune! Mai întâi, creați un folder ~/.ssh

mkdir ~/.ssh

Generați chei pentru utilizatorul de server dat cu comanda:

ssh-keygen (ca utilizator normal).

La generare, puteți seta o frază de acces pentru cheie (de preferință setată și una lungă - atunci chiar dacă obțineți cheia, dar nu știți parola pentru cheie, atacatorul nu se va putea conecta), sau puteți săriți peste el apăsând pur și simplu „Enter” - în acest caz, parola nu va cere niciodată. Aceleași chei publice și private au apărut în folderul ~/.ssh.

Găsiți o altă mașină (chiar și un smartphone va face - există niște clienți SSH grozavi pe Android, cum ar fi ConnectBot sau JuiceSSH), instalați ssh pe ea și conectați-vă la server cu comanda:

ssh [email protected]

Dacă totul este făcut corect, i se va solicita parola utilizatorului, iar după ce ați introdus vă veți regăsi în sistemul dumneavoastră cu o vizualizare din linia de comandă.

Pentru Windows, apropo, există și servere și clienți ssh.

După ce ne-am bucurat de rezultatul muncii noastre, să trecem la partea și mai plictisitoare - configurarea clientului / serverului.

Configurația din partea clientului este în /etc/ssh/ssh_config, și server - /etc/ssh/sshd_config. Cel mai cuprinzător ghid de configurare este poate pagina de manual - man ssh și man sshd_config, așa că vă recomandăm să o citiți. Și în acest articol vom lua în considerare cele mai necesare lucruri.

Setare

Portul ssh standard este 22. Poate fi schimbat cu orice non-standard (complicând un posibil hack din cauza securității prin obscuritate, sau pentru a atrage atenția potențialilor hackeri :) - pentru a face acest lucru, decomentați linia:

#Portul 22

Și adăugați tot ce doriți până la 65535 (asigurându-vă că portul nu intră în conflict cu alte servicii cu comanda #netstat -tupln | grep ASCULTĂ).

Acum, când se conectează la server, clientul va trebui să scrie cu cheia:

ssh -p [port] :

În mod implicit, accesul root este permis. Este foarte de dorit să-l limitezi (și în schimb să delimitezi corect drepturile utilizatorului local cu sudo). Pentru a face acest lucru, găsiți linia „PermitRootLogin” și schimbați valoarea în „nu”. De asemenea, îl puteți schimba în „fără-parolă” - în acest caz, autentificarea ca root va fi permisă numai de sub mașinile cu o cheie de încredere.

Puteți dezactiva autentificarea cu parolă și puteți lucra numai cu chei - găsiți linia: „PasswordAuthentication” și schimbați valoarea la „nu”. Pentru ce? Dacă cineva dorește cu adevărat să obțină acces la sistemul dvs., atunci poate fie să forțeze brutal parola atunci când încearcă să autorizeze, fie să vă asculte și să decripteze conexiunea. Dacă dezactivați autentificarea cu parolă și adăugați cheia publică a laptopului dvs., de exemplu, de lucru la ~/.ssh/authorized_keys de pe server, atunci, după cum ne amintim, vom fi lăsați să intrăm pe server imediat. Dar dacă lucrați la mașina altcuiva și aveți nevoie urgent să obțineți acces la serverul ssh, dar nu ne lasă să intrăm așa cum era de așteptat? Apoi nu puteți dezactiva autentificarea parolei, ci puteți utiliza utilitarul fail2ban. Doar instalați-l din depozitul dvs., după care va aplica setările implicite și va proteja cel puțin canalul dvs. ssh de atacurile de forță brută. Mai multe despre fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.

În cazul în care serverul dvs. are cheile pentru a lansa rachete nucleare, puteți face ceva de genul acesta:

PermitRootLogin nu - autentificarea sub root este interzisă.

PasswordAuthentication nu - autentificare fără parolă

Să generăm o cheie lungă pe mașina de la distanță (-t encryption_type, -b bit length):

ssh-keygen -t rsa -b 4096

Cu o frază de acces nu mai puțin complexă (apropo, este imposibil să recuperați o parolă uitată. O puteți schimba cu comanda „ssh-keygen -p”, dar în orice caz vi se va cere cea veche). Mutați cheia publică a mașinii locale la distanță în ~/.ssh/authorized_keys a serverului și voilà, acum o puteți accesa de pe o singură mașină folosind fraza de acces a cheii private. SSH vă permite să configurați o mulțime de configurații de securitate și are o mulțime de setări specifice pentru aceasta - citiți despre ele în man.

Două opțiuni sshd_config servesc aceluiași scop:

LoginGraceTime- setează timpul după care conexiunea va fi deconectată dacă nu are loc autentificarea.

MaxAuthTries- stabilește numărul de încercări de conectare nevalide, la care se va ajunge conexiunea.

MaxSessions- numărul de sesiuni simultane (dacă serverul este computerul dvs. de acasă la care vă veți conecta de la universitate sau de la serviciu, atunci ar fi rezonabil să limitați numărul de sesiuni la una - o autentificare respinsă, în acest caz, va deveni un motiv pentru a crește paranoia, a genera chei noi și a schimba parola). Totuși, dacă ești atent, s-ar putea să observi că la fiecare conectare la server este afișată linia „Ultima autentificare”. În plus, puteți adăuga propriul mesaj de bun venit - găsiți linia „Banner” și, în loc de niciunul, setați calea către fișier cu textul care va fi citit și afișat la conectare.

Printre altele, puteți permite numai anumitor utilizatori să se conecteze sau permiteți tuturor, cu excepția anumitor utilizatori:

AllowUsers user1- permite autentificarea numai user1.

DenyUsers utilizator1- permiteți tuturor, cu excepția utilizatorului1.

Și opțiuni similare pentru accesarea anumitor grupuri - AllowGroups și DenyGroups.

De asemenea, puteți transfera o sesiune X11 prin SSH. Pentru a face acest lucru, găsiți linia „ForwardX11” și modificați valoarea în „da”.

Găsiți o linie similară în configurația clientului - /etc/ssh/ssh_config și, de asemenea, schimbați-o în „da”.

Acum trebuie să vă conectați la server prin ssh cu argumentul -X:

ssh -X [email protected]>

Puteți lansa imediat aplicația la conectare:

ssh -X [email protected]"Apendice"

Iată cum arată un GIMP care rulează într-o sesiune ssh:

Sau puteți obține rezultatul de la camera web a laptopului unui utilizator nebănuit :)

Calculele se fac direct pe server, iar rezultatul este transferat pe mașina client (adică chiar dacă serverul în sine nu are instalat X11, aplicațiile grafice pot fi redate pe mașina dvs. la distanță). Această schemă funcționează destul de lent (nu uitați că tot traficul este criptat dinamic) - dar această funcție este foarte utilă.

De asemenea, puteți copia fișiere într-o sesiune SSH - există un simplu utilitar „scp” pentru aceasta. Puteți transfera fișiere direct în sesiune ca de la server la client:

scp [email protected]:/cale/la/fișier/pe/server /unde/la/salvare/pe/local/mașină

Deci de la client la server:

scp cale/la/fișier/client [email protected]:/cale/pe/server

Acest lucru este destul de convenabil dacă trebuie să copiați un text sau o fotografie, dar ce se întâmplă dacă trebuie să lucrați cu multe fișiere? Pentru aceasta, există cel mai convenabil lucru - sshfs (disponibil pentru instalare în depozitele majorității sistemelor * nix).

Doar setați calea în același mod ca scp:

sshfs [email protected]:/acasă/utilizator /mnt/

Și folderul /home/user al serverului va apărea pe punctul de montare /mnt al mașinii locale!

Demontarea se face prin umount.

Și, în sfârșit, să vorbim despre o caracteristică puțin cunoscută. Dacă creați un fișier /.ssh/config si umple-l asa:

gazdă [nume]

nume de gazdă

Utilizator [nume utilizator server]

opțiunile dorite

ca

ForwardX11 da

Portul 30000

Apoi ne putem autentifica prin:

ssh [nume]

ssh -X -p 30000 [email protected]

Și toate opțiunile vor fi preluate automat. Astfel, cu autentificarea frecventă pe un anumit server, veți simplifica acest proces în câteva momente.

Ei bine, am acoperit tot (și mai multe) pe care trebuie să știți despre SSH pentru utilizarea de zi cu zi - am învățat cum să utilizați autentificarea cu cheie, am protejat serverul cu forța brută și, în general, am corectat majoritatea găurilor potențiale. De fapt, SSH poate face multe alte lucruri - de exemplu, tunelarea și redirecționarea portului printr-o sesiune ssh, dar este puțin probabil ca tu, în calitate de utilizator cel mai obișnuit, să folosești vreodată acest lucru. Resurse aditionale

SSH - (Secure Shell) este un protocol pentru controlul de la distanță al unui computer care rulează un sistem de operare Linux. Practic, ssh este folosit pentru a controla de la distanță serverele prin terminal. Dacă sunteți administratorul mai multor servere sau chiar un webmaster avansat, atunci probabil că veți întâlni adesea nevoia de a lucra cu un anumit computer prin ssh. În Linux, acest lucru se face folosind un server ssh pe mașina la care doriți să vă conectați și clientul pe cel de la care vă conectați.

În acest tutorial, ne vom uita la modul de utilizare a ssh, precum și la caracteristicile sale despre care nici nu știai. Cel mai probabil, știți deja cum să vă conectați la un server prin ssh, dar acest utilitar are mult mai multe caracteristici, cum ar fi transferul de fișiere ssh, conectarea fără parolă sau executarea unui script pe un server la distanță. Toate acestea le vom analiza mai departe în articol.

Dar să începem cu elementele de bază.

Sintaxa comenzii este următoarea:

$ ssh [opțiuni] Nume de utilizator@server [comandă]

Este important de reținut că ssh poate funcționa cu două versiuni ale protocolului. Versiunile 1 și 2. Este clar că versiunea 2 este mai bună și acceptă mai multe tipuri de criptare și autentificare. Nu vom vorbi mai mult despre diferențele de protocol în acest articol și voi presupune că utilizați versiunea 2.

Opțiuni de comandă SSH

Acum să ne uităm la cele mai de bază opțiuni ale comenzii ssh:

  • f- pune ssh în fundal
  • g- permite mașinilor de la distanță să acceseze porturile locale
  • l- numele de utilizator în sistem
  • n- redirecționează stdout către /dev/null
  • p- portul ssh pe mașina de la distanță
  • q- nu afișați mesaje de eroare
  • v- modul de depanare
  • X- dezactivați redirecționarea X11
  • X- activați redirecționarea X11
  • C- activați compresia

Acestea nu sunt toate opțiuni de utilitate, restul depășesc domeniul de aplicare al acestui articol. Multe setări pentru funcționarea ssh pot fi modificate prin fișierul de configurare ~/.ssh/config, dar nici aici nu vom lua în considerare acest lucru în detaliu.

Configurare server SSH

Setările serverului SSH se află în fișierul /etc/ssh/sshd_config. Nu ne vom atinge nici de multe dintre ele. Luați în considerare doar cele mai interesante. Mai întâi deschideți fișierul /etc/ssh/sshd.conf

port ssh

În mod implicit, ssh rulează pe portul 22. Dar acest comportament este nesigur, deoarece un atacator cunoaște acest port și poate încerca să efectueze un atac Bruteforce pentru a forța parola. Portul este specificat de linia:

Schimbați valoarea portului la ceea ce doriți.

Protocolul SSH

Implicit, serverul ssh poate rula pe două versiuni ale protocolului, pentru compatibilitate. Pentru a utiliza doar versiunea a doua a protocolului, decomentați linia:

Și faceți să arate așa:

Acces rădăcină

În mod implicit, accesul rădăcină prin ssh este permis, dar acest comportament este foarte nesigur, așa că decomentați linia:

PermitRootLogin nr

Numai un anumit utilizator acces la SSH

Putem permite accesul ssh doar pentru un anumit utilizator sau grup. Pentru a face acest lucru, adăugați liniile:

AllowUsers User1, User2, User3
AllowGroups Group1, Group2, Group3

Aici User1 și Group1 sunt utilizatorul și grupul la care doriți să permiteți accesul.

Rularea aplicațiilor X11

Nu toată lumea știe, dar este posibil să utilizați ssh pentru a rula aplicații X11 cu drepturi depline. Vom vorbi despre asta mai jos, dar pentru ca totul să funcționeze, trebuie să activați această caracteristică pe partea serverului, adăugați această linie:

X11 Redirecționare da

Opțiunile principale au fost acoperite, înainte de a trece mai departe, nu uitați să reporniți serverul ssh pentru a salva modificările:

repornirea serviciului sshd

Folosind SSH

Scopul principal al acestui articol este de a arăta modalități interesante și utile de a utiliza ssh despre care poate nu le cunoașteți. Să trecem la cele mai delicioase - posibilitățile ssh.

Conexiune la server

Pentru a vă conecta pur și simplu la server prin SSH, utilizați următoarea comandă:

Executa comanda

Suntem obișnuiți să ne conectăm la un server la distanță și apoi să executăm comenzile necesare, dar, de fapt, utilitarul ssh vă permite să executați imediat comanda dorită fără a deschide terminalul mașinii la distanță. De exemplu:

ssh [email protected] ls

Executați comanda ls pe serverul de la distanță și returnați rezultatul acesteia la terminalul curent.

Executați scriptul local

Să executăm un interpret bash pe serverul de la distanță și să îi transmitem scriptul nostru local folosind redirecționarea de intrare Bash:

ssh [email protected]"bash -s"< script.sh

Faceți backup pe un server la distanță și restaurați

Putem salva o copie de rezervă a discului direct pe un server la distanță folosind ssh. Redirecționează rezultatul dd cu operatorul de redirecționare |, apoi salvează-l într-un fișier pe cealaltă parte:

sudo dd if=/dev/sda | ssh [email protected]„dd of=sda.img”

Acum, pentru a restabili starea discului din backup, rulați:

ssh [email protected]„dd if=sda.img” | ddof=/dev/sda

Aici și mai sus /dev/sda este numele fișierului hard disk-ului tău.

Autentificare fără parolă

Folosirea unei parole ssh pentru a vă conecta la server este nu numai incomod, ci și nesigur, deoarece această parolă poate fi ghicită în orice moment. Cea mai sigură și utilizată metodă de autentificare este cu o pereche de chei RSA. Cheia privată este stocată pe computer, în timp ce cheia publică este folosită pe server pentru autentificarea utilizatorului.

Este foarte ușor să configurați acest comportament. Mai întâi, creați o cheie cu comanda:

ssh-keygen -t rsa

În timpul creării cheii, va trebui să răspundeți la câteva întrebări, să părăsiți locația în mod implicit, dacă doriți să vă conectați fără parolă - lăsați și câmpul Passphare gol.

Apoi trimitem cheia către server:

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

Obțineți parola din fișierul local

Permiteți-mi să vă reamintesc că stocarea parolelor în fișiere text obișnuite nu este sigură, dar dacă doriți, atunci da - este posibil. Pentru a face acest lucru, utilizați operatorul de redirecționare a intrării Bash:

ssh [email protected] < local_file.txt

Schimbați salutul SSH

Când vă conectați prin ssh, poate fi afișat un salut, este foarte ușor să îl schimbați. Fișierul /etc/issue este responsabil pentru acest lucru. Doar deschideți acest fișier și introduceți textul dorit:

Urmăriți încercările eșuate de conectare SSH

Doriți să vedeți dacă au existat încercări nereușite de a vă accesa serverul prin ssh și de la ce adrese IP? Cu ușurință, toate cererile sunt înregistrate în fișierul /var/log/secure, filtram doar datele necesare cu comanda:

cat /var/log/secure | grep „Parola eșuată pentru”

Transferați fișiere prin SSH

Pe lângă executarea comenzilor, puteți copia fișiere prin ssh. Utilitarul scp este folosit pentru aceasta. Trebuie doar să specificați fișierul pe care doriți să îl transferați, serverul la distanță și folderul de pe server, astfel:

$ scp /adresă/local/fișier utilizator@gazdă:adresă/dosare

De exemplu:

scp ~/test.txt [email protected]:documente

Pe lângă utilitarul scp, transferurile de fișiere ssh se pot face într-un mod mai complicat. Citim fișierul și cu ajutorul pisicii, transferăm, iar acolo salvăm fluxul într-un fișier:

fisier local cat | ssh [email protected] pisică > fișier la distanță

ssh [email protected] pisică > fișier la distanță< localfile

tar czf - /home/user/file | ssh [email protected] tar -xvzf -C /home/remoteuser/

Copierea fișierelor ca acest ssh vă permite să trimiteți foldere întregi simultan.

Rularea aplicațiilor grafice prin ssh

Dacă trebuie să rulați o anumită aplicație grafică pe o mașină la distanță, nu este necesar să utilizați VNC pentru aceasta, vă puteți descurca cu capabilitățile ssh. Programul va fi executat pe partea serverului și doar o fereastră vă va fi difuzată, astfel încât să puteți face tot ce aveți nevoie. Și toate datele sunt criptate. Pentru ca această caracteristică să funcționeze, trebuie să fie activată pe partea serverului.

Apoi pur și simplu executăm comanda pentru a lansa o aplicație grafică pe un server la distanță, astfel:

ssh -XC [email protected]"eclipsă"

După cum ați văzut, opțiunea X permite redirecționarea X11 pe partea clientului, iar opțiunea C permite comprimarea datelor.

Încheierea unei sesiuni ssh

Dacă ai folosit ssh cu un Internet instabil, când conexiunea se întrerupe din când în când, atunci probabil că te-ai săturat deja să închizi terminalul, pentru că altfel, la prima vedere, sesiunea nu poate fi încheiată. Când conexiunea la serverul de la distanță este întreruptă, nu puteți introduce nicio comandă și comenzile rapide de la tastatură Ctrl+C, Ctrl+Z, Ctrl+D nu funcționează. Și nu va funcționa deoarece clientul încearcă să trimită aceste comenzi către server. Dar există o soluție - secvențe de evacuare. Pentru a le activa suportul, adăugați linia:

În fișierul /etc/ssh/ssh_config

Acest articol este marcat ca stub. Vezi nota de la sfârșitul articolului.

Acest articol se concentrează pe clientul și serverul terminal securizat (shell securizat) în Ubuntu, configurarea și utilizarea acestora. SSH este un protocol de rețea special care permite accesul de la distanță la un computer cu un grad ridicat de securitate a conexiunii. Puteți citi mai multe despre protocolul ssh.

Descrierea principiilor de funcționare și a aplicațiilor utilizate

Practic, SSH este implementat ca două aplicații - un server SSH și un client SSH.Ubuntu folosește o implementare gratuită a unui client și server SSH, OpenSSH. La conectare, clientul trece prin procedura de autorizare la server și se stabilește o conexiune criptată între ei. Serverul OpenSSH poate funcționa atât cu protocoalele ssh1, cât și cu ssh2. Protocolul ssh1 este în prezent considerat nesigur și, prin urmare, este puternic descurajat. Omit în mod deliberat diverse detalii tehnice despre modul în care funcționează protocolul, deoarece scopul principal al acestui ghid este de a descrie configurarea și utilizarea acestuia. Există multe articole pe Internet despre protocolul în sine, principiile funcționării acestuia, algoritmii de criptare etc., de exemplu, puteți citi despre acesta în detaliu.

Instalare

Instalare OpenSSH Puteți folosi comanda din terminal:

sudo apt-get install ssh

Metapachetul ssh conține atât clientul, cât și serverul, dar acesta va instala cel mai probabil doar serverul, deoarece clientul este deja inclus în Ubuntu în mod implicit.

Ajustarea serverului

La instalarea SSH, serverul este adăugat automat la pornire. Puteți controla pornirea, oprirea sau repornirea acestuia folosind comenzile:

sudo service ssh stop| începe | repornire

Fișierul principal de configurare a serverului SSH este fișierul /etc/ssh/sshd_config, care poate fi citit sau editat doar de superutilizator. După fiecare modificare a acestui fișier, trebuie să reporniți serverul ssh pentru ca modificările să aibă efect.

Exemplu de configurare implicită a serverului SSH în Ubuntu:

# Un exemplu de configurație de server open-ssh cu comentarii # # rusești..2010. # # # # # # Convenții: # # În mod implicit, aceasta se referă la comportamentul sshd atunci când # # această directivă nu este specificată în mod explicit. Este demn de remarcat faptul că pe Ubuntu # # fișierul sshd_config conține deja o serie de setări care sunt # # implicite în special pentru Ubuntu. # # Astfel de setări sunt specificate în acest fișier. # # # ############################################### # ############# ############### Setări de adresă/port etc. ########### ######################################################### #################### # # ## Port ######################## ########################### # # # Portul de utilizat. Puteți specifica mai multe, de exemplu: # # Port 22 # # Port 23 # # Port 24 # # Se recomandă utilizarea unui port non-standard, deoarece # # cel standard este adesea scanat de roboți pentru # # găuri potențiale. Poate fi omis dacă este dat # # prin adresă. Consultați și parametrul ListenAddress. # # # Port 22 # # ## AscultareAdresa ##################################### # ## # # # Adresa de rețea pe care ascultă serverul. Adresa poate fi scrisă astfel: # # ListenAddress host|IPv4_addr|IPv6_addr # # ListenAddress gazdă|IPv4_addr:port # # ListenAddress :port # # Dacă nu este specificat niciun port, sshd va asculta la această adresă și # # pe port specificat în portul opțional. Dacă # # utilizați ListenAddress fără a specifica un port, opțiunea # # Port trebuie să fie înaintea opțiunii ListenAddress. Dacă este lăsată omisă, # # este implicit să asculte la toate # # adresele locale. Puteți specifica mai multe adrese. # # # ## AdresaFamilie ######################################## ## # Specifică ce familie de adrese IP # # ar trebui să fie utilizată de sshd. Opțiunile sunt: ​​# # „orice” - orice # # „inet” (doar IPv4) # # „inet6” (doar IPv6) # # Implicit este „orice”. # AdresăFamilie inet # # ## UtilizațiDNS ####################################### # ####### # # # Specifică dacă sshd ar trebui să verifice numele gazdei și # # să folosească acel nume pentru a verifica adresa IP dată de client față de # # primită de la DNS. # # Valoarea implicită este „da”. # # # ############################################### # ############# ############ Setări de acces utilizator ############## ###### # ################################################################## ## ### # # # A permite/refuza un utilizator este definită de directivele # # DenyUsers, AllowUsers, DenyGroups și AllowGroups. # # în același timp, verificarea merge de sus în jos de-a lungul lanțului: # # ## DenyUsers ## # # || # # ## AllowUsers ## # # || # # ## DenyGroups ## # # || # # ## AllowGroups ## # # Sunt acceptate numai numele utilizatorilor și grupurilor, identificatorii numerici # # (UserID) nu sunt recunoscuți. Introducerea corectă # # a mai multor utilizatori/grupuri pe rând, separate # # printr-un spațiu. Dacă este scris ca utilizator@gazdă, atunci # # utilizatorul și gazda sunt verificate separat, acest lucru permite # # să restricționeze accesul anumitor utilizatori de la # # anumite gazde. Merită să ne amintim că directivele # # DenyUsers și AllowUsers iau un # # nume de utilizator ca parametru, în timp ce DenyGroups și AllowGroups # # iau un nume de grup. Consultați PATTERNE în man ssh_config pentru mai multe # # informații despre convențiile numelui de utilizator și al grupului. # # # ## DenyUsers ########################################### ## # # # O listă de UTILIZATORI care NU TREBUIE să fie utilizați de sshd. # # Implicit - nespecificat = nimeni nu este interzis. Acestea. # # dacă un utilizator este specificat aici, i se va refuza # # accesul la serverul ssh. # # # ## AllowUsers ########################################### # # # # Lista de UTILIZATORI care TREBUIE să fie utilizați de sshd, # # Implicit - nespecificat = toată lumea este permisă. Acestea. dacă # # este specificat cel puțin un utilizator, accesul ssh la server # # este disponibil numai pentru acesta. # # # ## DenyGroups ########################################## # # # # O listă de GRUPURI care NU TREBUIE să fie folosite de sshd. # # Implicit - nespecificat = niciun grup nu este interzis. # # adică dacă este specificat cel puțin un grup, utilizatorilor # # din acel grup li se va refuza accesul la serverul # # ssh. # # # ## AllowGroups ########################################## # # # O listă de GRUPURI pe care sshd POT folosi. # # Implicit - nespecificat = permis tuturor. Acestea. dacă # # este specificat cel puțin un grup, atunci numai acelor utilizatori# # care aparțin acestuia li se va permite accesul la serverul ssh.# # # ################## ## ########################################################## # Opțiuni care determină starea conexiunii ########## ################################# ## ####################### # # ## TPCKeepAlive ################## ## ###################### # # # Specifică dacă sistemul ar trebui să trimită mesaje TCP către client # # pentru a menține conexiunea. Dacă trimiteți aceste pachete, # # puteți detecta o deconectare. Totuși, acest # # înseamnă, de asemenea, că conexiunea poate fi întreruptă dacă # # există o întrerupere momentană în rutare și # # acest lucru este foarte enervant pentru unii. Pe de altă parte, dacă # # aceste mesaje nu sunt trimise, sesiunile pe server pot rula # # pe termen nelimitat, generând utilizatori „fantomă”# # și devorând resursele serverului. Valoarea implicită este „da”, # # adică trimite astfel de mesaje. Pentru a dezactiva trimiterea de # # astfel de mesaje, setați valoarea la „nu”. Anterior această opțiune # # se numea KeepAlive. Este de remarcat faptul că există # # modalități mai sigure de a verifica starea conexiunii # # (vezi mai jos). # # # TPCKeepAlive da # # ## ClientAliveCountMax ################################# # # # Specifică numărul de mesaje către clienți # # pe care sshd le trimite într-un rând fără a primi niciun răspuns # # de la client. Dacă pragul este atins și # # clientul tot nu răspunde, sshd va deconecta clientul, încheind # # sesiunea ssh. Este de remarcat faptul că utilizarea acestor mesaje # # este fundamental diferită de directiva TPCKeepAlive. # # Mesajele către/de la clienți sunt trimise pe un # # canal criptat și, prin urmare, nu sunt susceptibile de falsificare. # # Mesajele TPCKeepAlive sunt susceptibile de falsificare. Mecanismul client alive # # este deosebit de valoros în cazurile în care serverul și clientul # # trebuie să știe când o conexiune a devenit inactivă. Valoarea implicită # # este 3. Dacă ClientAliveInterval # # este setat la 15 și ClientAliveCountMax este lăsat la # # implicit, clienții care nu răspund vor fi deconectați după aproximativ # # 45 de secunde. Această directivă funcționează numai pentru # # protocolul ssh2. # # # ## ClientAliveInterval ################################## # # # Setează intervalul de timp în secunde. Dacă nu a fost făcută nicio comunicare cu clientul în # # acest interval, sshd # # trimite un mesaj pe un canal criptat # # solicitând un răspuns de la client. Valoarea implicită este 0, adică # # nu trimiteți astfel de mesaje. Această directivă funcționează # # numai pentru protocolul ssh2. # # # ############################################### # ############ ############### Opțiuni generale de autentificare ################ # # ################################################################## ## ####### # # ## AuthorizedKeysFile ################################# ## # # # # Specifică fișierul care conține cheile publice # # folosite pentru autentificarea utilizatorilor. Directiva # # poate conține token-uri de forma %M, care sunt înlocuite în timpul # # procesului de stabilire a conexiunii. # # Următorii marcatori sunt definiți: # # %% - înlocuiți cu literalul „%” # # %h - înlocuiți cu directorul principal # # al utilizatorului care se autentifică # # %u - înlocuit cu numele utilizatorului care se autentifică # # Astfel, fișierul cheie poate fi specificat ca # # cale absolută (adică un fișier partajat cu chei) și # # dinamic - în funcție de utilizator (adică un # # fișier per utilizator). # # Valoarea implicită este „.ssh/authorized_keys”. # # Exemplu pentru un fișier cheie în folderul principal al utilizatorului: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Exemplu pentru un fișier generic: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # Consultați descrierea fișierului authorized_keys pentru mai multe # # informație. # # # ## ChallengeResponseAuthentication ###################### # # # Indică dacă se permite autentificarea provocare-răspuns # # (autentificarea provocării-răspuns ). # # Toate tipurile de autentificare de la login.conf sunt acceptate. Implicit este „da”, # # adică. permite. # # Pe Ubuntu, dezactivat din motive de securitate. # # # ChallengeResponseAuthentication nu # # ## HostbasedUsesNameFromPacketOnly ######################## # # # Specifică modul în care serverul ar trebui să recupereze numele de gazdă al clientului # # când schema de autentificare bazată pe gazdă. # # Dacă este setat la „da”, sshd # # va folosi numele de gazdă furnizat de client atunci când verifică o potrivire în fișierele # # ~/.shosts, ~/.rhosts sau /etc/hosts.equiv. # # (efectuează rezoluția DNS inversă) Dacă este setat la „nu” # # - sshd va rezolva numele de la conexiunea TCP în sine. # # Valoarea implicită este „nu”. # # # ## IgnorăRhosts ########################################## # # Dezactivează utilizarea fișierelor .rhosts și .shosts # # în autentificarea bazată pe gazdă. # # (RhostsRSAAuthentication sau HostbasedAuthentication). # # Fișierele /etc/hosts.equiv și /etc/ssh/shosts.equiv sunt # # încă în uz. # # Valoarea implicită este „da”. # # # IgnoreRhosts da # # ## IgnoreUserKnownHosts ################################# # # # Indică ar trebui sshd să ignore fișierul utilizatorului # # „gazde cunoscute” ~/.ssh/known_hosts în timpul # # autentificării bazate pe gazdă (RhostsRSAAuthentication sau HostbasedAuthentication). # # Valoarea implicită este „nu”. # # # ## PermitBlacklistedKeys ################################ # # # Specifică dacă se acceptă cheile sshd pe lista neagră # # ca fiind compromise (chei # # cunoscute-compromise (vezi ssh-vulnkey)). Dacă se setează la „da”, încercările de autentificare # # cu aceste chei vor fi înregistrate # # și acceptate, dacă se setează la „nu”, încercările de autentificare # # vor fi respinse. # # Valoarea implicită este „nu”. # # # ## PermitEmptyPasswords ################################## # # # În cazul autentificării permise cu parolă, # # specifică dacă este posibilă autentificarea cu o parolă goală. # # Valoarea implicită este „nu”. # # # PermitEmptyPasswords nu # # ## PermitRootLogin #################################### # # Indică dacă autentificarea ssh ca superutilizator # # (rădăcină) este permisă. Poate lua următoarele valori: # # „da” - superutilizatorul se poate autentifica. # # Este utilizată schema de autentificare globală actuală. # # # # „fără-parolă” - superutilizatorul se poate autentifica. # # Autentificarea cu parolă pentru aceasta va fi dezactivată. # # # # „forțat-comenzi-doar” - superutilizatorul se va putea autentifica # # folosind autentificarea cu cheie publică și # # numai dacă trece comanda necesară pentru a fi executată. # # Acesta este la îndemână pentru a face backup # # chiar și atunci când este normal (adică nu prin ssh) # # autentificarea rădăcină este dezactivată. Toate celelalte # # metode de autentificare pentru superutilizator vor fi dezactivate.# # # # „nu” - superutilizatorul nu poate folosi ssh pentru a # # autentificare în sistem. # # # # Valoarea implicită este „da”. # # # PermitRootLogin da # # ## Protocol ###################################### ######## # # # Specifică ce protocol ar trebui să folosească sshd. # # Valorile posibile ale lui „1” și „2” sunt ssh1 și, respectiv, ssh2 # #. Este posibilă scrierea simultană, în care # # valorile trebuie separate prin virgule. # # Valoarea implicită este „2,1”. # # Este de remarcat faptul că ordinea protocoalelor în # # o intrare nu specifică prioritatea, deoarece clientul alege ce # # dintre mai multe protocoale oferite de server să folosească # # Intrarea „2,1” este exact # # identică cu intrarea „1,2”. # # # Protocolul 2 # # ## Utilizați PAM ###################################### ######### # # # Activează interfața PAM (Pluggable Authentication Module # # interfață). Dacă este setată la „da” - pentru toate tipurile de autentificare # # în plus față de procesarea modulului de sesiune și a contului # # PAM autentificarea va fi utilizată pe baza # # challenge-response (ChallengeResponseAuthentication și # # PasswordAuthentication) # # autentificarea cu răspuns la provocare în PAM îndeplinește de obicei același rol # # ca și autentificarea cu parolă, ar trebui să dezactivați # # fie PasswordAuthentication, fie # # ChallengeResponseAuthentication. Este de remarcat faptul că # # dacă directiva UsePAM este activată, nu veți putea porni # # sshd ca alt utilizator decât root. # # Valoarea implicită este „nu”. # # # Utilizați PAM da # # ## PasswordAuthentication ################################ # # # Specifică dacă autentificare folosind # # parola. # # Valoarea implicită este „da”. # # # ## HostKey ########################################### #### # # # Specifică fișierul care conține cheia privată a gazdei # # folosită de SSH. Valoarea implicită este /etc/ssh/ssh_host_key # # pentru protocolul ssh1 și /etc/ssh/ssh_host_rsa_key și # # /etc/ssh/ssh_host_dsa_key pentru protocolul ssh2. # # Este de remarcat faptul că sshd nu va folosi un fișier # # care este partajat cu altcineva decât utilizatorul. Puteți # # să utilizați mai multe fișiere cheie, cheile sunt „rsa1” # # pentru protocolul ssh1 și „dsa”/“rsa” pentru protocolul ssh2. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # # ############################## ############################ ######### Opțiuni de protocol SSH versiunea 1 (ssh1) ### ########## ######################################## ################### # NU ESTE RECOMANDAT să folosiți protocolul ssh1.# # Protocolul ssh2 este mult mai sigur decât ssh1 # ###### ##### ############################################################### #### # # ## KeyRegenerationInterval ############################### # # # Pentru protocolul ssh1 - o dată de fiecare dată # # este generată automat o nouă cheie temporară de server # # (dacă a fost folosită una). Acest lucru se face # # pentru a preveni decriptarea sesiunilor deturnate, pentru a # # ulterior să vă conectați la mașină cu parametrii acestor sesiuni și # # să furați cheile. Această cheie nu este stocată nicăieri (stocat în # # RAM). Această directivă specifică durata de viață # # a cheii în secunde după care # # va fi regenerată. Dacă valoarea este setată la 0 - # # cheia nu va fi regenerată. # # Valoarea implicită este 3600 (secunde). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ############################### # # # Indică dacă se bazează pe autentificare pe fișierele # # rhosts sau /etc/hosts.equiv, împreună cu # # autentificarea cu succes a gazdei prin RSA. # # Relevant doar pentru protocolul ssh1. # # Valoarea implicită este „nu”. # # # RhostsRSAAuthentication nu # # ## RSAAuthentication #################################### # Indică dacă autentificarea RSA „pură” este permisă. # # Relevant doar pentru protocolul ssh1. # # Valoarea implicită este „da”. # # # RSAAuthentication da # # ## ServerKeyBits ###################################### ### # # # Specifică numărul de biți din cheia temporară a serverului pentru # # protocolul ssh1. Valoarea minimă este 512. # # Valoarea implicită este 1024. # ServerKeyBits 768 # # ################################ ########################## ########## Opțiuni de protocol SSH versiunea 2 (ssh2) #### ######## ########################################## ################# # # ## Cifre ########################### ##################### # # # Specifică algoritmii de criptare permisi pentru # # protocolul ssh2. Mai mulți algoritmi ar trebui să fie # # separați prin virgule. Algoritmi acceptați: # # „3des-cbc”, „aes128-cbc”, „aes192-cbc”, „aes256-cbc”, # # „aes128-ctr”, „aes192-ctr”, „aes256-ctr”, „ arcfour128”, # # „arcfour256”, „arcfour”, „blowfish-cbc”, „cast128-cbc”. # # Valorile implicite sunt: ​​# # aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, arcfour128, # # arcfour256, arcfour, aes192-cbc, aes256-cbc, aes128-ctr, #2- # aes, #5 -ctr # # # ## HostbasedAuthentication ############################## # # # Specifică dacă autentificarea este permisă, pe baza la # # verificarea gazdei. Verificați rhosts sau /etc/hosts.equiv, # # și dacă reușiți, combinat cu o verificare cu succes # # a cheii publice, accesul este acordat. Această directivă este # # aceeași cu directiva RhostsRSAAuthentication și # # se aplică numai protocolului ssh2. # # Valoarea implicită este „nu”. # # # Autentificare bazată pe gazdă nu # # ## MAC-uri ###################################### ############ # # # Indică un algoritm MAC valid (mesaj # # cod de autentificare). Algoritmul MAC este # # folosit de protocolul ssh2 pentru a proteja integritatea datelor. Mai mulți # # algoritmi trebuie despărțiți prin virgule. # # Valorile implicite sunt: ​​# # hmac-md5,hmac-sha1, [email protected] ,hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication ########################## ########## # # # Indică dacă autentificarea cu cheie publică # # este permisă. Relevant doar pentru protocolul ssh2. # # Valoarea implicită este „da”. # # # PubkeyAuthentication da ###################################################################### ############### ################### Opțiuni GSSAPI ############# ############# ####################################################### ###################### # # ############ Aplicabil numai pentru protocolul ssh2 ######## ### # # ## GSSAPIAuthentication ################################## # # # Specifică dacă autentificarea utilizatorului este # # bazată pe GSSAPI. Valoarea implicită este „nu”, adică. interzisă. # # # ## GSSAPIKeyExchange ################################### # # # Indică dacă cheia schimbul bazat pe # # GSSAPI este permis. Schimbul de chei GSSAPI nu se bazează pe # # chei ssh pentru a verifica identitatea gazdei. # # Valoarea implicită este „nu” - adică schimbul este interzis. # # # ## GSSAPICleanupCredentials ############################# # # # Specifică dacă se distruge automat # # autentificarea utilizatorului memoria cache a acreditărilor când # # se termină sesiunea. # # Valoarea implicită este „da” - adică trebuie distrus. # # # ## GSSAPIStrictAcceptorCheck ############################ # # # Specifică cât de strictă ar trebui să fie verificarea identității # # client la autentificare prin GSSAPI. # # O valoare de „da” determină clientul să se autentifice la # # serviciul gazdă care primește pe gazda curentă. O valoare „nu” # # permite clientului să se autentifice cu orice # # cheie de serviciu. # # Valoarea implicită este „da”. # # Rețineți că setarea la „nu” poate funcționa numai # # cu bibliotecile Kerberos GSSAPI rare. # # # ############################################### # ############ ################## Opțiuni Kerberos ############### # ######### ######################################################### # ################## # # ## KerberosAuthentication ######################## # ######## # # # Indică dacă parola furnizată # # de utilizator pentru autentificare # # (PasswordAuthentication) necesită validare la Kerberos KDC. # # Pentru a utiliza această opțiune, serverul are nevoie de # # pentru a verifica dacă KDC este adevărat. (Serverul are nevoie de un # # servtab Kerberos care permite verificarea identității # # KDC) # # Implicit este „nu”. # # # ## KerberosGetAFSToken ################################### # # # Dacă AFS este activ iar utilizatorul a primit un Kerberos 5 TGT, # # dacă să încerce să obțină un token AFS înainte ca utilizatorul să aibă acces la folderul de acasă. # # Valoarea implicită este „nu”. # # # ## KerberosOrLocalPasswd ################################# # # # Specifică cum să procedezi în caz de dacă autentificarea # # prin Kerberos a eșuat. Dacă # # valoarea este „da”, parola va fi verificată folosind # # orice mecanism de autorizare local suplimentar, # # de exemplu - /etc/passwd. # # Valoarea implicită este „da”. # # # ## KerberosTicketCleanup ################################# # # # Specifică dacă se oprește automat fișierul cu # # cache-ul biletului utilizatorului când se termină sesiunea. # # Valoarea implicită este „da”. # # # ############################################### # ############# ################ Opțiuni de redirecționare ################# # ## ############################################### ## ########### # # ## AllowAgentForwarding ############################## # ### # # # Specifică dacă se activează sau se dezactivează redirecționarea ssh-agent # #. Valoarea implicită este „da”, adică permite. # # Rețineți că dezactivarea redirecționării nu va crește # # securitatea, cu excepția cazului în care utilizatorii vor refuza și # # acces shell deoarece își pot # # instala propriile agenți omologii # # # ## AllowTcpForwarding ##################### ########## ###### # # # Specifică dacă se permite sau se dezactivează redirecționarea TCP # # Valoarea implicită este „da”, adică permite. deoarece # # utilizatorii au acces la consolă, deoarece își pot # # instala omologii # # # # # ## GatewayPorts ######### ## ############################### # # # Specifică dacă se permite accesul gazdelor de la distanță la # # porturi redirecționate. În mod implicit, sshd ascultă doar # # pentru porturile redirecționate pe interfața locală # # (loopback). Acest lucru împiedică alte gazde la distanță # # să se conecteze la porturile redirecționate. Puteți utiliza # # GatewayPorts pentru a permite sshd să # # să facă acest lucru. Directiva poate lua 3 valori: # # "nu" - doar loopback. # # „da” - orice adrese. # # „clientspecified” - adrese specificate de client. # # # ## PermisDeschis ########################################### # # # # Specifică unde este permisă redirecționarea portului TCP. # # Sugestia de redirecționare trebuie să ia una dintre # # următoarele forme: # # PermitOpen gazdă:port # # PermitOpen IPv4_addr:port # # PermitOpen :port # # Mai multe intrări pot fi specificate prin separarea lor cu spații. # # Argumentul „orice” poate fi folosit pentru a elimina toate # # restricțiile de redirecționare a porturilor. În mod implicit, orice # # redirecționare este permisă. # # # ## PermitTunnel ########################################### # # Indică dacă redirecționarea dispozitivului tun este permisă. # # Poate fi setat la: # # „da” # # „punct-la-punct” (al treilea strat de rețea) # # „ethernet” (al 2-lea strat de rețea) # # „nu” # # Valoarea „da” permite ambele „ punct la punct" # # și „ethernet” în același timp. Valoarea implicită este „nu”. # # # ############################################### # ############# ################# Opțiuni de înregistrare ################ # ### ################################################################ ## ############ # # ## SyslogFacility ############################# # ########## # # # Specifică codul obiectului jurnal pentru a scrie mesaje în # # syslog din sshd. Valori posibile: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # Valoarea implicită este AUTH. # # # SyslogFacility AUTH # # ## LogLevel ###################################### ######## # # # Setează nivelul de verbozitate al jurnalului sshd. # # Opțiunile sunt: ​​# # SILENT # # QUIET # # FATAL # # EROARE # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # Implicit este INFO. # # DEBUG și DEBUG1 sunt echivalente între ele. # # DEBUG2 și DEBUG3 setează cele mai înalte niveluri de ieșire de depanare. Conectarea la nivelul DEBUG # # amenință confidențialitatea utilizatorului și nu este recomandată. # # # LogLevel INFO # # ########################################## ############### ################## Redirecționare X11 ############ # ####### ########################################## ################ # # ## X11Redirecționare ######################### ## ############## # # # Indică dacă este permisă redirecționarea subsistemului grafic X11 # #. Poate lua valorile „da” sau „nu”. # # Valoarea implicită este „nu”. # # Avertisment - activarea unei redirecționări simple X11 este # # un risc mare atât pentru server, cât și pentru clienți, deoarece în # # această redirecționare, afișajul proxy sshd va accepta # # conexiuni de la orice adresă. # # Utilizați directiva X11UseLocalhost pentru a restricționa accesul la # # serverul de redirecționare X. Este de remarcat faptul că # # dezactivarea redirecționării nu va garanta că # # utilizatorii nu vor putea redirecționa X11, deoarece având # # acces la consolă își setează întotdeauna redirectorul # #. Redirecționarea X11 va fi # # dezactivată automat dacă # # este utilizată directiva UseLogin. # # # X11Redirecționare da # # ## X11UseLocalhost ###################################### # # # Specifică dacă sshd # # ar trebui să restricționeze redirecționarea X11 la adresa de buclă locală sau # # să permită orice adrese. Implicit este sshd # # pentru a „planta” serverul de redirecționare X11 la adresa locală # # și pentru a seta partea numelui de gazdă a variabilei de mediu DISPLAY # # la „localhost”. Rețineți că # # este posibil ca unii clienți X11 mai vechi să nu funcționeze cu # # aceste setări. Valoarea implicită este „da”, adică redirecționarea # # este limitată la localhost, valoarea este „nu” - dezactivează # # restricțiile. # # # ## XAuthLocation ######################################## ## # Specifică calea completă către programul xauth. # # Implicit este /usr/bin/X11/xauth. # # # ## X11DisplayOffset #################################### # # # Indică numărul din primul afișaj disponibil pentru sshd # # ca redirecționare X11. Acest lucru se face astfel # # încât x-urile redirecționate să nu se suprapună cu # # cele reale. Valoarea implicită este 10. # # # X11DisplayOffset 10 # # ################################### #################### ################## Diverse opțiuni ###### # ################ ################################# ######################### # # ## LoginGraceTime ################## # ###################### # # # Timpul după care serverul deconectează # # un utilizator dacă nu se # # autentifică în mod satisfăcător. Valoarea 0 - permite utilizatorului # # să se autentifice pe termen nelimitat. Valoarea implicită este 120 (secunde). # # # LoginGraceTime 120 # # ## MaxAuthTries ##################################### # ### # # # Specifică numărul maxim de încercări de autentificare # # permise pe conexiune. # # Odată ce numărul de încercări eșuate depășește # # jumătate din valoarea setată, toate încercările ulterioare vor fi # # înregistrate. Valoarea implicită este 6. # # # ## MaxSessions #################################### ###### # # # Specifică numărul maxim de conexiuni simultane # # pentru fiecare conexiune la rețea. Implicit este 10. # # # ## MaxStartups ##################################### ##### # # # Specifică numărul maxim de conexiuni simultane # # neautorizate la sshd. În cazul în care # # numărul de conexiuni depășește limita - toate # # conexiunile suplimentare vor fi renunțate până când # # conexiunile curente sunt finalizate fie prin autorizare cu succes, # # fie prin expirarea perioadei de timp specificate în directiva # # LoginGraceTime . Valoarea implicită este 10. # # Opțional, puteți seta conexiunile să scadă mai devreme prin # # specificând trei valori separate # # prin două puncte „start:rate:full” (de exemplu: „10:30:60”). # # sshd va respinge încercarea de conectare cu o probabilitate # # de „rate/100” (adică. în exemplul nostru este 30%) dacă # # există deja conexiuni neautorizate „start” (10). # # Probabilitatea crește liniar și orice # # încercări de conectare vor fi respinse dacă numărul de # # conexiuni neautorizate ajunge la „plin” (60). # # # ## Compresie ########################################### # # # # Indică dacă compresia datelor este activată. Poate fi # # „da” - compresia este activată. # # „întârziat” - compresia este întârziată până când # # utilizatorul este autentificat cu succes. # # „nu” - compresia este dezactivată. # # Valoarea implicită este „întârziată”. # # # ## UtilizațiLogin ########################################### ### # # # Indică dacă autentificarea ar trebui utilizată pentru # # o sesiune interactivă. Valoarea implicită este „nu”. # # Este de remarcat faptul că autentificarea nu a fost niciodată folosită # # pentru a executa comenzi de la distanță. De asemenea, rețineți că # # folosind autentificare va face imposibilă # # folosirea directivei X11Forwarding, deoarece autentificarea nu # # știe ce să facă cu xauth. Dacă directiva # # UsePrivilegeSeparation este activată - va fi dezactivată după # # autorizare. # # # ## UsePrivilegeSeparation ############################### # # # Specifică dacă sshd ar trebui să separe privilegiile. Dacă da # #, atunci va fi creat mai întâi un proces copil neprivilegiat # # pentru traficul de rețea de intrare. După autorizarea cu succes, # # va fi creat un alt proces cu # # privilegiile utilizatorului conectat. # # # Scopul principal al partajării privilegiilor este de a preveni suprascrierile. # # Valoarea implicită este „da”. # # # UsePrivilegeSeparation da # # ## StrictModes #################################### ### # # # Specifică dacă sshd ar trebui să verifice modurile de acces și # # proprietatea folderelor și fișierelor utilizatorului înainte de a permite utilizatorului să se autentifice. Acest lucru se datorează, de obicei, că # # începătorii își fac adesea fișierele inscriptibile # # de către toată lumea. Valoarea implicită este „da”. # # # StrictModes da # # ## AcceptEnv ################################################################# ####### # # # Specifică ce variabile de mediu transmise # # de client vor fi acceptate. Vedeți opțiunea SendEnv din client. # # Rețineți că trecerea variabilelor este posibilă numai # # pentru protocolul ssh2. Variabilele sunt specificate după nume, pot fi utilizate # # metacaractere ('*' și '?'). Puteți specifica # # mai multe variabile separate prin spații sau # # întrerupeți mai multe linii de AcceptEnv. Fiți atenți - unele # # variabile de mediu pot fi folosite pentru a ocoli # # mediile de utilizator interzise. # # Utilizați această directivă cu atenție. În mod implicit, nu sunt acceptate # # variabile de mediu personalizate. # # # AcceptEnv LANG LC_* # # ## PermisUserEnvironment ############################### # # # Specifică dacă sshd # # ar trebui să accepte opțiunea ~/.ssh/environment și mediu= în # # ~/.ssh/authorized_keys. Valoarea implicită este „nu”. Merită # # remarcat faptul că gestionarea mediului de activare poate oferi utilizatorilor # # posibilitatea de a ocoli restricțiile în unele # # configurații folosind mecanisme precum # # LD_PRELOAD. # # # # # ## Fișier Pid ######################################## ###### # # # Specifică fișierul care conține ID-ul procesului # # (ID-ul procesului, PID) al demonului SSH. # # Implicit este /var/run/sshd.pid # # # # # ## PrintLastLog ########################### ## ############# # # # Specifică dacă sshd ar trebui să afișeze data și ora # # ultimei sesiuni când un utilizator se conectează interactiv. # # Valoarea implicită este „da”. # # # PrintLastLog da # # ## PrintMotd ####################################### ####### # # # Specifică dacă sshd ar trebui să imprime /etc/motd # # când un utilizator se conectează interactiv. Pe unele # # sisteme (de exemplu Ubuntu) această informație este, de asemenea, afișată de # # shell. # # Valoarea implicită este „da”. # # # PrintMotd nr # # ## Banner ###################################### ######### # # # Specifică ce fișier conține bannerul text # # care va fi afișat utilizatorului ÎNAINTE de procedura de autentificare # #. Opțiunea este disponibilă numai pentru protocolul ssh2.# # Implicit - nu arată nimic. # # Pe Ubuntu, fișierul issue.net conține expresia Ubuntu (versiune), # # de exemplu pentru karmic este „Ubuntu 9.10”. # # poate fi folosit pentru a deruta potențialii atacatori prin # # scriind „My D-Link Interet Router” =) # # # Banner /etc/issue.net # # ## ChrootDirectory ########### # ############################ # # # Dacă este specificat, furnizează calea către # # chroot după autentificare. Calea și tot # # conținutul său trebuie să corespundă # # folderelor deținute de superutilizator și să nu poată fi # # scrise de alți utilizatori. # # Calea poate conține etichete care sunt înlocuite în # # procesul de autentificare: # # %% - înlocuit cu literalul „%” # # %h - înlocuit cu directorul principal # # al utilizatorului care este autentificat # # %u - înlocuit cu numele utilizatorului care este autentificat # # chroot -folderul ar trebui să conțină toate fișierele și # # folderele necesare pentru sesiunea utilizatorului. O sesiune # # interactivă are nevoie de cel puțin: # # un shell, de obicei sh # # dispozitive de bază în /dev, cum ar fi: # # null, zero, stdin, stdout, stderr, random și tty # # pentru o sesiune de transfer de date folosind sftp # # nu este necesară nicio configurație suplimentară dacă # # este folosit procesul intern sftp al serverului. Consultați Subsistem pentru # # mai multe informații. În mod implicit, chroot-ul nu este efectuat. # # # ## ForceCommand ########################################### # # Determină executarea comenzii specificate. Ignoră # # orice comenzi date de client sau scrise în # # ~/.ssh/rc. Comanda este invocată din # # shell-ul utilizatorului cu opțiunea -c. Potrivit pentru rularea unui shell, # # comandă sau subsistem. Cel mai util în blocul # # Match. Comanda trimisă inițial de client este stocată # # în variabila de mediu SSH_ORIGINAL_COMMAND. Dacă # # este specificată comanda „internal-sftp”, # # va fi pornit un server sftp intern, care nu are nevoie de fișierele și folderele suplimentare # # descrise în directiva ChrootDirectory. # # # ## Subsistemul ########################################### ## # # # Definește și configurează un subsistem extern (de exemplu # # demonul de transfer de fișiere). # # Argumentele sunt numele și comanda (cu posibile # # argumente) care vor fi executate în timpul interogării # # pe subsisteme. Comanda sftp-server pornește subsistemul de transfer de fișiere „sftp” # #. Opțional, puteți # # specifica „internal-sftp” ca subsistem, care va porni # # un server intern sftp. # # Acest lucru poate simplifica foarte mult configurația atunci când se folosește directiva # # ChrootDirectory În mod implicit, nu sunt apelate subsisteme # #. Relevant doar pentru protocolul ssh2. # # # Subsistem sftp /usr/lib/openssh/sftp-server # # ############################### # ######################### ################### Bloc de potrivire # ######################### ######################## ################################## # # # Mutat special la sfârșitul fișierului pentru a-l face mai convenabil # # scrie regulile de potrivire. # # MadKox. # # # # Directiva Match este începutul unui # # bloc condiționat. Dacă sunt îndeplinite toate criteriile specificate în linia de potrivire # #, directivele de pe liniile ulterioare ale blocului sunt executate, # # permițându-vă să ocoliți valorile directivelor globale sshd_config # # pentru cazul în care # # se potrivește cu criteriile directivei. Un bloc sunt toate liniile care urmează linia # # cu criteriul (Potrivire - linii) până la următoarea linie de potrivire # # sau până la sfârșitul fișierului. Argumentul pentru directiva Match este una sau # # mai multe perechi de intrări de criterii. Tipurile de înregistrări posibile sunt: ​​# # Utilizator # # Grup # # Gazdă # # Adresă # # Înregistrările pot conține valori individuale # # (de ex. Utilizator=utilizator) sau valori multiple # # separate prin virgule (Utilizator=utilizator1,utilizator2 ). # # Pot fi folosite și expresiile regulate descrise în # # secțiunea PATTERNS din fișierul ssh_config. Intrările din criteriile de adresă # # pot conține adrese în notația CIDR # # (Lungimea adresă/mască, de exemplu „192.0.2.0/24” sau # # „3ffe:ffff::/32”). Este de remarcat faptul că lungimea măștii furnizată # # trebuie să se potrivească cu adresa și # # prea lung/scurt pentru adresă nu va funcționa. # # Directivele de potrivire pot folosi doar # # un anumit set de directive: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAuthentication # # # MaxAuthTriess # # # MaxAuthTries PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #

Puteți copia textul de mai sus în propriul sshd_config și îl puteți utiliza mai târziu pentru configurare.

În sine, un server SSH configurat greșit este o vulnerabilitate uriașă de securitate, deoarece un posibil atacator are capacitatea de a obține acces aproape nelimitat la sistem. În plus, sshd are multe opțiuni suplimentare utile pe care este de dorit să le activeze pentru a îmbunătăți gradul de utilizare și securitatea.

Port, ListenAddress și AddressFamily

Aceste trei opțiuni determină porturile și adresele pe care serverul dvs. va asculta pentru conexiunile de intrare. În primul rând, are sens, dacă este posibil, să se limiteze familia de adrese procesate la cele utilizate efectiv, adică dacă utilizați doar IPv4, dezactivați IPv6 și invers. Acest lucru se poate face folosind parametrul AddressFamily, de exemplu (pentru a permite IPv4 și a refuza IPv6):

AddressFamily inet

În al doilea rând, este de dorit să se schimbe portul standard (22) pe care ascultă sshd. Acest lucru se datorează faptului că numeroase scanere de rețea încearcă în mod constant să se conecteze la cel de-al 22-lea port și cel puțin să obțină acces prin enumerarea login-urilor / parolelor din baza lor de date. Chiar dacă aveți autentificarea prin parolă dezactivată, aceste încercări înfundă jurnalele și (în număr mare) pot afecta negativ viteza serverului ssh. Dacă dintr-un motiv oarecare nu doriți să schimbați portul standard, puteți utiliza diverse utilitare externe pentru a combate forțarea brută, cum ar fi fail2ban, sau cele încorporate, cum ar fi MaxStartups.
Puteți seta portul ca valoare absolută pentru toate interfețele utilizând directiva Port sau ca valoare specifică pentru fiecare interfață folosind directiva ListenAddress. De exemplu:

Port 2002

ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004

Dezactivați accesul de la distanță pentru superutilizator

În mod implicit, accesul root este refuzat prin parolă (prin cheie - puteți) - opțiunea PermitRootLogin este setată la fără parolă. Dar, având în vedere că în mod implicit în Ubuntu, utilizatorul adăugat în timpul instalării sistemului are capacitatea de a efectua toate sarcinile administrative prin sudo, crearea capacității de a accesa root la sistem prin ssh pare nerezonabilă (chiar și cu autentificarea cu cheie). Se recomandă oprirea completă. această opțiune sau aplicați-o numai în modul numai pentru comenzi forțate. Puteți dezactiva accesul root astfel:

PermitRootLogin nr

Autentificare prin parolă

Autentificarea prin parolă activată în mod implicit este practic cea mai primitivă modalitate de a vă conecta la sshd. Pe de o parte, acest lucru simplifică configurarea și conectarea noilor utilizatori (este suficient ca utilizatorul să-și cunoască autentificarea / parola de sistem), pe de altă parte, parola poate fi întotdeauna ghicită, iar utilizatorii neglijează adesea să creeze complexe și parole lungi. Boții speciali scanează în mod constant serverele ssh disponibile de pe Internet și încearcă să se autentifice la ele prin enumerarea autentificărilor/parolelor din baza lor de date. Este foarte recomandat să nu utilizați autentificarea prin parolă. Îl poți dezactiva astfel:

PasswordAuthentication nr

Dacă dintr-un motiv oarecare doriți să utilizați autentificarea cu parolă - asigurați-vă că nimeni nu se poate conecta cu o parolă goală. Pentru a face acest lucru, setați directiva PermitEmptyPasswords:

PermitEmptyPasswords nr

Protocoale SSH1 și SSH2

După cum sa menționat deja, sshd poate funcționa cu protocoalele SSH1 și SSH2. Cu toate acestea, utilizarea SSH1 nesigură este foarte descurajată. Puteți forța sshd să funcționeze numai cu protocolul SSH2 astfel:

Autentificare cheie SSH2 RSA

Metoda de autorizare preferată este autentificarea cheii SSH2 RSA. Cu această metodă, utilizatorul generează o pereche de chei pe partea sa, dintre care o cheie este secretă, iar cealaltă este publică. Cheia publică este copiată pe server și servește la verificarea identității utilizatorului. Pentru mai multe informații despre crearea unei perechi de chei și despre cum să le plasați pe server, consultați descrierea clientului SSH. Puteți activa autentificarea cu cheie publică astfel:

PubkeyAuthentication da

Serverul trebuie să știe unde ar trebui să caute cheia publică a utilizatorului. Pentru aceasta este folosit un fișier special authorized_keys. Sintaxa sa poate fi după cum urmează:

# Comentariile sunt scrise doar pe o linie nouă # formă generală de intrări în fișierul autorizat_keys # [opțiuni] key_type (ssh-rsa sau ssh-dss) very_long_string_incomprehensible_to_o_ordinary_person [login@host] ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net permitopen="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...== [email protected]

Puteți specifica atât un fișier partajat cu chei, cât și un fișier pentru fiecare utilizator. Această din urmă metodă este mai convenabilă și mai sigură, deoarece, în primul rând, puteți specifica diferite combinații de taste pentru fiecare utilizator și, în al doilea rând, puteți restricționa accesul la cheia publică a utilizatorului. Puteți seta un fișier cu chei utilizând directiva AuthorizedKeysFile:

AuthorizedKeysFile %h/.ssh/my_keys

pentru utilizatorul de schemă - fișier
sau

AuthorizedKeysFile /etc/ssh/authorized_keys

pentru o schemă cu un fișier partajat. În mod implicit, clientul SSH caută chei în ~/.ssh/authorized_keys .

Mai multe despre securitate

Setari aditionale

Utilizatori și grupuri.

Dacă aveți o mulțime de utilizatori care „trăiesc” pe server și doriți să permiteți doar câțiva dintre ei să acceseze prin ssh, puteți utiliza directivele DenyUsers , AllowUsers , DenyGroups și AllowGroups. Consultați comentariile din exemplul sshd_config pentru mai multe detalii despre aceste directive.

Opțiuni pentru starea conexiunii

În mod implicit, numai metoda de verificare a conexiunii TCP, TCPKeepAlive, este inclusă din metodele de detectare a stării conexiunii, cu toate acestea, sshd poate determina stările de conexiune în moduri mai convenabile și mai sigure. Consultați secțiunea relevantă din exemplul sshd_config pentru detalii.

Performanţă. MaxStartups

Port forwarding

redirecționare X11

Pe server, în fișierul /etc/ssh/sshd_config, setați parametrul (activat implicit):

ForwardX11 da

Pe client, în fișierul /etc/ssh/ssh_config, setați următorii parametri (dezactivați implicit):

ForwardAgent da ForwardX11 da

Îl poți rula pe client astfel ssh [email protected] firefox. Sau mai întâi mergem ssh [email protected] apoi rulați, de exemplu sudo synaptic .

SFTP

sshd are un server SFTP încorporat în mod implicit. SFTP (SSH File Transfer Protocol) - protocol SSH pentru transferul de fișiere. Este conceput pentru a copia și a efectua alte operațiuni de fișiere printr-o conexiune fiabilă și sigură. De regulă, protocolul SSH2 este utilizat ca protocol de bază care asigură conexiunea. Pentru a activa suportul SFTP, adăugați linia la sshd_config

Subsistemul sftp /usr/lib/openssh/sftp-server

În mod implicit, suportul SFTP este activat.

Utilizarea criteriilor. Directiva de potrivire

Configurarea unui client SSH

Conectarea cu cheie este considerată cea mai sigură și, în cele mai multe cazuri, această caracteristică este activată pe partea serverului, deci nu sunt necesare drepturi de superutilizator pentru ao utiliza. Generați o cheie pe computerul client:

ssh-keygen -t rsa

Primim o ofertă de a introduce o parolă pentru a proteja fișierul cheie (se dovedește a fi util dacă fișierul cade în mâini greșite). Dacă vom executa scripturi prin SSH, atunci îl lăsăm gol. Transferăm cheia publică pe server cu comanda

ssh-copy-id -i ~/ .ssh/ id_rsa.pub [email protected] Server

Totul, poți intra.

Când ssh rulează pe un port non-standard:

ssh-copy-id -i ~/ .ssh/ id_rsa.pub „-p port [email protected]"

Dacă apare o eroare: port greșit „umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys”

încercați să puneți parametrii între ghilimele:

ssh-copy-id „-i /home/user/.ssh/id_rsa.pub „-p port [email protected]""

Este convenabil să utilizați utilitarul ecran atunci când vă conectați la un sistem de la distanță.

Configurarea unui director ssh la distanță în Nautilus

Montarea unui director la distanță cu sshfs

Montarea unui director la distanță într-un director local

sshfs [email protected] hostingserver.ru:/ home/ userdir ~/ sshfsdir

Demontați

Fusermount -u ~/sshsfdir

Aliasuri SSH

Când utilizați mai multe servere cu parametri de acces diferiți (port non-standard, nume lung de gazdă, autentificare diferită de cea locală etc.), uneori este plictisitor să introduceți din nou toate setările de conexiune de fiecare dată. Pentru a facilita acest lucru, pot fi folosite aliasuri.

Setările sunt stocate în ~/.ssh/config pentru un singur utilizator și în /etc/ssh/ssh_config la nivel global pentru toți utilizatorii.

Exemplu de configurare. Pot fi descrise o multitudine de servere. Citiți mai multe în man ssh_config(a nu se confunda cu sshd_config)

Host AliasName # Nume gazdă arbitrar HostName 1.2.3.4 # Puteți specifica atât IP-ul, cât și numele de gazdă (dacă DNS funcționează) User YourUserName # Dacă utilizatorul nu se potrivește cu utilizatorul local Port YourSSHPort # Dacă este un port non-standard

După aceea, vă puteți conecta la server cu comanda

ssh AliasName

ssh-agent

Diagnosticarea problemelor de conectare

    Analiza jurnalului de conectare:

ssh-vvv [email protected] gazdă

    Analiza fișierelor de configurare client și server.

Locația fișierelor de configurare poate fi găsită în

Man ssh man sshd

Folosind carduri inteligente

1. Crearea unui certificat și exportarea unei chei publice, precum și a părții client pe Windows + Putty SC sunt descrise pe site: http://habrahabr.ru/post/88540/ Add-on-ul Key Manager descris acolo este disponibil numai în versiunile mai vechi de Firefox. Testat pe versiunea 3.5 pentru Windows. Link direct la supliment: https://addons.mozilla.org/en/firefox/addon/key-manager/

2. Pregătirea serverului. Trebuie să vă asigurați că configurația sshd permite autentificarea cu chei publice. Pentru a face acest lucru, trebuie să specificați valoarea parametrului „PubkeyAuthentication” în fișierul „sshd_config” la „yes”. Apoi adăugăm cheia noastră publică obținută mai devreme (pe o singură linie) în fișierul „~/.ssh/authorized_keys”. Vă rugăm să rețineți că fișierul „.ssh/authorized_keys” se află în directorul principal al utilizatorului care se va conecta apoi folosind cheia publică.

3. Partea client pe Linux. Va trebui să reconstruiți pachetul OpenSSH fără opțiuni. Se recomandă să specificați doar prefixe de director, cum ar fi --prefix=/usr. De asemenea, rețineți că fișierele de configurare vor fi în /usr/etc. Înainte de a începe, sunt necesare pachete: opensc-lite-devel, zlib-devel, openssl-devel. Instalați driverul pentru cardul inteligent. Pentru comoditate, în configurația ssh_config (a nu se confunda cu sshd_config) specificați calea către biblioteca pkcs: PKCS11Provider=<путь к библиотеке>

4. Rulați ssh pe client [email protected] Dacă este conectat un smart card (token), va fi solicitată o parolă și o sesiune SSH va fi conectată.

Posibile probleme la utilizare

Combinația obișnuită de taste Ctrl + S , folosită în multe editoare pentru a salva corecțiile, atunci când lucrați într-un terminal cu un server ssh, va determina executarea comenzii XOFF, care arată ca o sesiune de blocare. Cu toate acestea, nu este. Serverul continuă să accepte caractere introduse și comenzi, dar nu le afișează pe ecran. Pentru a ieși dintr-o astfel de situație, este suficient să folosiți combinația Ctrl + Q, reactivând astfel modul XON.

Legături

Adică, user1 poate fi înregistrat atât pentru el însuși - în fișierul /home/user1/.ssh/keys), cât și pentru un alt utilizator, ceea ce îi va permite să se autentifice de pe computer atât „sub sine” cât și sub „altul”

Sau SSH pe scurt, este una dintre cele mai avansate tehnologii pentru securizarea datelor în tranzit. Utilizarea acestui mod pe același router vă permite să asigurați nu numai confidențialitatea informațiilor transmise, ci și să accelerați schimbul de pachete. Adevărat, nu toată lumea știe cum este SSH și de ce este nevoie de toate acestea. În acest caz, este necesar să se dea o explicație constructivă.

Port SSH: ce este și de ce este necesar?

Întrucât vorbim de securitate, în acest caz, portul SSH trebuie înțeles ca un canal de comunicație dedicat sub forma unui tunel care asigură criptarea datelor.

Cea mai primitivă schemă pentru un astfel de tunel este că un port SSH deschis este utilizat în mod implicit pentru a cripta informațiile la sursă și a le decripta la punctul final. Puteți explica astfel: indiferent dacă vă place sau nu, traficul transmis, spre deosebire de IPSec, este criptat forțat atât la ieșirea unui terminal de rețea, cât și la intrarea părții destinatare. Pentru a decripta informațiile transmise pe acest canal, terminalul receptor folosește o cheie specială. Cu alte cuvinte, nimeni nu poate interfera cu transmisia sau încălca integritatea datelor transmise în momentul actual fără o cheie.

Doar deschiderea unui port SSH pe orice router sau utilizarea setărilor corespunzătoare ale unui client suplimentar care interacționează direct cu serverul SSH vă permite să profitați din plin de toate caracteristicile de securitate ale rețelelor moderne. Ideea aici este să utilizați portul atribuit implicit sau setările utilizatorului. Acești parametri în aplicare pot părea destul de complicati, dar nu se poate face fără înțelegerea organizării unei astfel de conexiuni.

Port SSH standard

Dacă procedați cu adevărat de la parametrii oricărui router, mai întâi trebuie să decideți ce fel de software va fi folosit pentru a activa acest canal de comunicare. De fapt, portul SSH implicit poate avea setări diferite. Totul depinde de ce tehnică este utilizată în acest moment (conexiune directă la server, instalarea unui client suplimentar, redirecționarea portului etc.).

Deci, de exemplu, dacă Jabber este folosit ca client, portul 443 trebuie utilizat pentru conexiunea, criptarea și transferul de date corecte, deși portul 22 este setat implicit.

Pentru a reconfigura routerul cu cerințe preliminare pentru un anumit program sau proces, va trebui să efectuați redirecționarea portului SSH. există o atribuire specifică de acces pentru un singur program care utilizează o conexiune la Internet, indiferent de setările protocolului de comunicare curent (IPv4 sau IPv6).

Rațiune tehnică

După cum este deja clar, portul standard SSH 22 nu este întotdeauna utilizat. Totuși, aici este necesar să evidențiem unele dintre caracteristicile și parametrii utilizați în configurație.

De ce confidențialitatea transferului de date criptate necesită utilizarea protocolului SSH ca port de utilizator exclusiv extern (oaspete)? Da, doar pentru că tunelul utilizat vă permite să utilizați așa-numitul remote shell (SSH), să obțineți acces la managementul terminalului prin autentificare de la distanță (slogin) și, de asemenea, să utilizați proceduri de copiere la distanță (scp).

În plus, portul SSH poate fi folosit și atunci când utilizatorul trebuie să execute scripturi X Windows la distanță, care în cel mai simplu caz este transferul de informații de la o mașină la alta, așa cum sa menționat deja, cu criptarea forțată a datelor. În astfel de situații, cel mai necesar va fi utilizarea algoritmilor bazați pe AES. Acesta este algoritmul de criptare simetrică care a fost furnizat inițial în tehnologia SSH. Și nu este doar posibil să îl utilizați, ci și necesar.

Istoricul implementării

Tehnologia în sine există de mult timp. Lăsând deoparte întrebarea cum se face redirecționarea portului SSH pentru moment, să ne concentrăm asupra modului în care funcționează totul.

De obicei, se rezumă la utilizarea unui proxy bazat pe Socks sau a unui tunel VPN. Dacă o aplicație software poate funcționa cu VPN, este mai bine să preferați această opțiune. Faptul este că aproape toate programele cunoscute în prezent care folosesc traficul pe Internet pot funcționa cu VPN, iar configurarea rutării nu este dificilă. Acest lucru, ca și în cazul serverelor proxy, vă permite să lăsați adresa externă a terminalului de la care accesați în prezent rețeaua nerecunoscută. Adică, în cazul unui proxy, adresa se schimbă constant, dar în versiunea VPN rămâne neschimbată odată cu fixarea unei anumite regiuni, diferită de cea în care este în vigoare interdicția de acces.

Tehnologia în sine, când portul SSH este deschis, a fost dezvoltată în 1995 la Universitatea de Tehnologie finlandeză (SSH-1). În 1996, a fost adăugată o îmbunătățire sub forma protocolului SSH-2, care a devenit destul de răspândit în spațiul post-sovietic, deși pentru aceasta, precum și în unele țări din Europa de Vest, uneori este necesar să obțineți permisiunea de a folosiți un astfel de tunel și de la agențiile guvernamentale.

Principalul avantaj al deschiderii unui port SSH, spre deosebire de telnet sau rlogin, este utilizarea unei semnături digitale RSA sau DSA (folosind o pereche sub forma unei chei publice și private). În plus, în această situație, poate folosi așa-numita cheie de sesiune bazată pe algoritmul Diffie-Hellman, ceea ce presupune utilizarea criptării simetrice la ieșire, deși nu exclude utilizarea algoritmilor de criptare asimetrică în procesul de transmiterea datelor și recepția lor de către o altă mașină.

Servere și Shell

Pe Windows sau în Windows nu este atât de greu. Singura întrebare este ce fel de set de instrumente va fi folosit pentru asta.

În acest sens, trebuie acordată atenție problemei transferului și autentificării informațiilor. În primul rând, protocolul în sine se dovedește a fi suficient de protejat de așa-numitul sniffing, care este cea mai comună „interceptare” a traficului. SSH-1 s-a dovedit a fi lipsit de apărare împotriva atacurilor. Intervenția în procesul de transmitere a datelor sub forma unei scheme „om la mijloc” a avut rezultatele. Informațiile ar putea fi pur și simplu interceptate și decriptate într-un mod complet elementar. Dar cea de-a doua versiune (SSH-2) a fost asigurată împotriva acestui tip de interferență, numită sesiunea deturnată, ceea ce a făcut-o cea mai răspândită.

Interdicții de securitate

În ceea ce privește securitatea în raport cu datele transmise și primite, organizarea unei conexiuni creată folosind astfel de tehnologii evită următoarele probleme:

  • determinarea cheii gazdei în stadiul de transmitere, când este utilizată amprenta digitală „turnată”;
  • suport pentru sisteme de tip Windows și UNIX;
  • Falsificarea adreselor IP și DNS (spoofing);
  • interceptarea parolelor deschise în timpul accesului fizic la canalul de transmisie a datelor.

De fapt, întreaga organizare a unui astfel de sistem este construită pe principiul „client-server”, adică, în primul rând, mașina utilizatorului, printr-un program special sau un add-on, accesează serverul, care efectuează redirecționarea corespunzătoare. .

tunelare

Este de la sine înțeles că în sistem trebuie instalat un driver special pentru a realiza acest tip de conexiune.

În mod obișnuit, pe sistemele Windows, acesta este driverul Microsoft Teredo încorporat în software-ul shell, care este un fel de instrument virtual de emulare IPv6 pe rețelele numai IPv4. este activ implicit. În cazul defecțiunilor asociate cu acesta, puteți pur și simplu să reporniți sistemul sau să lansați comenzile de oprire și repornire în shell. Următoarele linii sunt folosite pentru dezactivare:

  • netsh;
  • starea setării interfeței teredo este dezactivată;
  • starea setării interfeței isatap este dezactivată.

După introducerea comenzilor, urmează o repornire. Pentru a reactiva adaptorul și a verifica starea acestuia, se atribuie permisiunea activată în loc de dezactivată, după care, din nou, întregul sistem este repornit.

Server SSH

Acum să vedem care port SSH este folosit ca port principal, pornind de la schema „client-server”. De obicei, portul 22 este utilizat în mod implicit, dar, după cum sa menționat mai sus, poate fi folosit și portul 443. Întrebarea este doar în preferința serverului în sine.

Cele mai comune servere SSH sunt considerate următoarele:

  • pentru Windows: Tectia SSH Server, OpenSSH cu Cygwin, MobaSSH, KpyM Telnet/SSH Server, WinSSHD, copssh, freeSSHd;
  • pentru FreeBSD: OpenSSH;
  • pentru Linux: Tectia SSH Server, ssh, openssh-server, lsh-server, dropbear.

Toate serverele enumerate sunt gratuite. Cu toate acestea, puteți găsi și servicii cu plată care se disting printr-un nivel crescut de securitate, care este esențial pentru organizarea accesului la rețea și protejarea informațiilor în întreprinderi. Costul unor astfel de servicii nu este discutat momentan. Dar, în general, putem spune că este relativ ieftin, chiar și în comparație cu instalarea unui software specializat sau firewall „de fier”.

Client SSH

Schimbarea portului SSH se poate face pe baza programului client sau a setărilor corespunzătoare atunci când redirecționați porturile pe router.

Cu toate acestea, când vine vorba de shell-uri client, următoarele produse software pot fi utilizate pentru diferite sisteme:

  • Windows - SecureCRT, PuTTY\KiTTY, Axessh, ShellGuard, SSHWindows, ZOC, XShell, ProSSHD etc.;
  • Mac OS X: iTerm2, vSSH, NiftyTelnet SSH;
  • Linux și BSD: lsh-client, kdessh, openssh-client, Vinagre, putty.

Autentificarea cheii publice și schimbarea portului

Acum câteva cuvinte despre cum este verificat și configurat serverul. În cel mai simplu caz, trebuie să utilizați un fișier de configurare (sshd_config). Cu toate acestea, puteți face fără el, de exemplu, în cazul utilizării unor programe precum PuTTY. Schimbarea portului SSH de la valoarea standard (22) la oricare alta este destul de elementară.

Principalul lucru este că numărul portului deschis nu depășește valoarea 65535 (pur și simplu nu există porturi mai mari în natură). În plus, există unele porturi care sunt deschise implicit, care pot fi utilizate de clienți precum bazele de date MySQL sau FTPD. Dacă le specificați configurația pentru SSH, desigur, pur și simplu nu mai funcționează.

Rețineți că același client Jabber trebuie să ruleze în același mediu folosind un server SSH, cum ar fi o mașină virtuală. Și serverului localhost însuși va trebui să i se atribuie valoarea 4430 (și nu 443, așa cum s-a menționat mai sus). Această configurație poate fi utilizată atunci când accesul la fișierul principal jabber.example.com este blocat de un firewall.

Pe de altă parte, puteți, de asemenea, să port forward pe routerul însuși, folosind setările interfeței sale pentru aceasta, cu crearea regulilor de excludere. La majoritatea modelelor, introducerea se face prin introducerea adreselor care încep cu 192.168 cu adăugarea lui 0.1 sau 1.1, dar pe routerele care combină capabilitățile modemurilor ADSL precum Mikrotik, adresa finală presupune utilizarea 88.1.

În acest caz, se creează o nouă regulă, după care se setează parametrii necesari, de exemplu, pentru a stabili o conexiune externă dst-nat, iar porturile sunt înregistrate manual nu în secțiunea setări generale, ci în secțiunea Preferințe acțiuni. Nu este nimic deosebit de complicat aici. Principalul lucru este să specificați setările necesare și să setați portul corect. În mod implicit, se poate folosi portul 22, dar dacă se folosește un client specializat (unul dintre cele de mai sus pentru diferite sisteme), valoarea poate fi modificată în mod arbitrar, dar numai pentru ca acest parametru să nu depășească valoarea declarată, peste care există pur și simplu fără numere de port.

Când configurați o conexiune, ar trebui să acordați atenție și parametrilor programului client. Se poate foarte bine ca în setările sale să fie necesar să specificați o lungime minimă a cheii (512), deși valoarea implicită este de obicei 768. De asemenea, este de dorit să setați timeout-ul de conectare la 600 de secunde și să permiteți accesul de la distanță folosind drepturi root. După aplicarea acestor setări, trebuie să acordați și permisiunea de a utiliza toate drepturile de autentificare, cu excepția celor bazate pe utilizarea .rhost (dar numai administratorii de sistem au nevoie de acest lucru).

Printre altele, dacă numele de utilizator înregistrat în sistem nu se potrivește cu cel introdus în prezent, va trebui să îl specificați explicit folosind comanda user ssh master pentru aceasta, introducând parametri suplimentari (pentru cei care înțeleg ce este în joc).

Comanda ~/.ssh/id_dsa (sau rsa) poate fi folosită pentru a converti cheia și metoda de criptare în sine. Pentru a crea o cheie publică, se utilizează o transformare folosind linia ~/.ssh/identity.pub (dar aceasta nu este necesară). Dar, după cum arată practica, cea mai ușoară modalitate este de a folosi comenzi precum ssh-keygen. Aici esența întrebării se reduce doar la adăugarea unei chei la instrumentele de autorizare disponibile (~/.ssh/authorized_keys).

Dar am mers prea departe. Revenind la problema setării portului SSH, așa cum este deja clar, schimbarea portului SSH nu este atât de dificilă. Adevărat, în unele situații, după cum se spune, va trebui să transpirați, pentru că va trebui să țineți cont de toate valorile parametrilor principali. În caz contrar, problema de configurare se rezumă fie la intrarea în programul server sau client (dacă a fost furnizat inițial), fie la utilizarea redirecționării portului pe router. Dar chiar dacă schimbați portul 22, care este setat implicit, la același 443, trebuie să înțelegeți clar că o astfel de schemă nu funcționează întotdeauna, ci numai în cazul instalării aceluiași supliment Jabber (alți analogi pot folosi porturile corespunzătoare, diferite de standard). În plus, o atenție deosebită ar trebui acordată setării parametrilor clientului SSH care va interacționa direct cu serverul SSH, dacă acest lucru este cu adevărat destinat în utilizarea conexiunii curente.

În caz contrar, dacă nu este furnizat inițial (deși este de dorit să se efectueze astfel de acțiuni), setările și parametrii de acces prin protocolul SSH nu pot fi modificați. Aici, în general, nu există probleme speciale la crearea unei conexiuni și utilizarea ulterioară a acesteia (cu excepția cazului în care, desigur, se utilizează configurarea manuală bazată pe server și client). Cea mai comună creare a unei reguli de excludere pe router vă permite să remediați toate problemele sau să le evitați.

Top articole similare