Ne paraqesim në vëmendjen tuaj një kurs të ri nga ekipi Kodimi sipas- "Testimi i penetrimit të aplikacioneve në ueb nga e para". Teoria e Përgjithshme, Përgatitja e Mjedisit të Punës, Fuzimi pasiv dhe Gjurmët e Gishtave, Fuzimi aktiv, Dobësitë, Post-Shfrytëzimi, Mjetet, Inxhinieria Sociale dhe më shumë.

Çfarë është SSH dhe për çfarë shërben

Secure Shell (SSH) është një protokoll rrjeti që ofron funksionalitet shell për një makinë të largët mbi një kanal të sigurt. SSH sjell përmirësime të ndryshme sigurie, duke përfshirë vërtetimin e përdoruesit / hostit, enkriptimin e të dhënave dhe integritetin e të dhënave, gjë që i bën të pamundura sulmet e njohura si përgjimi, mashtrimi DNS/IP, falsifikimi i të dhënave dhe rrëmbimi i lidhjeve. etj. Për përdoruesit e ftp, telnet ose rlogin që përdorin një protokoll me tekst të qartë, rekomandohet shumë që ata të kalojnë në SSH.

OpenSSH është një zbatim me kod të hapur i protokollit SSH që kodon një lidhje rrjeti duke përdorur një grup programesh. Nëse dëshironi të keni SSH në Linux, mund të instaloni OpenSSH, i cili përbëhet nga një server OpenSSH dhe paketa klientësh.

Paketat e serverit / klientit OpenSSH vijnë me shërbimet e mëposhtme:

• Serveri OpenSSH: sshd (demon SSH)
• Klienti OpenSSH: scp (kopje e sigurt në distancë), sftp (transferim i sigurt i skedarëve), hyrje / ssh (hyrje e sigurt në distancë), ssh-add (shtimi i çelësit privat), ssh-agent (agjent vërtetimi), ssh-keygen (menaxhimi i çelësit të vërtetimit ).

Instalimi i serverit dhe klientit OpenSSH në Linux

Nëse dëshironi të instaloni serverin / klientin OpenSSH dhe të konfiguroni serverin OpenSSH që të fillojë automatikisht, ndiqni udhëzimet e mëposhtme, të cilat ndryshojnë në varësi të shpërndarjes.

Debian, Ubuntu ose Linux Mint

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

Në sistemet e bazuara në Debian, menjëherë pas instalimit, OpenSSH do të fillojë automatikisht në nisje. Nëse për ndonjë arsye serveri OpenSSH nuk fillon automatikisht gjatë nisjes së sistemit, mund të ekzekutoni komandën e mëposhtme për të shtuar pa mëdyshje ssh në nisjen gjatë nisjes së sistemit.

$ sudo update-rc.d parazgjedhjet ssh

Fedora ose CentOS / RHEL 7

$ sudo yum -y instaloni openssh-server openssh-clients $ sudo systemctl filloni shërbimin sshd $ sudo systemctl aktivizoni sshd.service

CentOS / RHEL 6

$ sudo yum -y instaloni openssh-server openssh-klientët $ shërbim sudo sshd fillon $ sudo chkconfig sshd në

Arch Linux

$ sudo pacman -Sy openssh $ sudo systemctl nis shërbimin sshd $ sudo systemctl aktivizo sshd.service

Konfigurimi i serverit OpenSSH

Nëse dëshironi të konfiguroni serverin OpenSSH, mund të modifikoni skedarin e konfigurimit në të gjithë sistemin që ndodhet në / etc / ssh / sshd_config.

Ka disa opsione OpenSSH për të cilat mund të jeni të interesuar:

Si parazgjedhje, sshd dëgjon në portin 22 dhe dëgjon për lidhjet hyrëse ssh. Duke ndryshuar portin e paracaktuar për ssh, mund të parandaloni sulme të ndryshme të automatizuara të hakerëve.

Dëgjo Adresa 192.168.1.1

Nëse kompjuteri juaj ka më shumë se një ndërfaqe rrjeti fizik, mund të dëshironi të kontrolloni se cila është e lidhur me sshd, mund të përdorni opsionin ListenAddress për ta bërë këtë. Ky opsion ndihmon në përmirësimin e sigurisë duke kufizuar SSH-në hyrëse vetëm përmes një ndërfaqeje specifike.

HostKey / etj / ssh / ssh_host_key

Opsioni HostKey përcakton se ku ndodhet çelësi personal i hostit.

PermitRootLogin nr

Opsioni PermitRootLogin - Nëse root mund të identifikohet përmes ssh.

AllowUsers alice bob

Duke përdorur opsionin AllowUsers, mund të çaktivizoni në mënyrë selektive shërbimin ssh për përdorues të veçantë Linux. Mund të specifikohen përdorues të shumtë, të ndarë me hapësira.

Pas modifikimit të / etc / ssh / sshd_config, sigurohuni që të rinisni shërbimin ssh.

Për të rifilluar OpenSSH në Debian, Ubuntu ose Linux Mint:

$ sudo /etc/init.d/ssh rinisni

Për të rifilluar OpenSSH në Fedora, CentOS / RHEL 7 ose Arch Linux:

$ sudo systemctl rinis sshd.service

Për të rifilluar OpenSSH në CentOS / RHEL 6:

$ rinisja e shërbimit sudo sshd

Si të lidheni me SSH

Lidhja me SSH nga Linux

Përdoruesit e Linux nuk kanë nevojë të instalojnë softuer shtesë.

Lidhu me SSH nga Windows

Për Windows, shumë njerëz rekomandojnë dhe përdorin me sukses PuTTY. Nuk kam asgjë kundër këtij programi, por preferoj dhe rekomandoj vetë Cygwin.

Cygwin nuk është thjesht një klient SSH. Është një kombinim i fuqishëm që mbështet shumë komanda Linux. Për shembull, është shumë e lehtë të krijosh certifikata SSL në Cygwin (ashtu si në Linux). Në Windows, ju duhet të kërceni me një dajre për të krijuar certifikata të vetë-nënshkruara. Cygwin është shumë i përshtatshëm për të përdorur cURL (nuk keni nevojë të instaloni asgjë veç e veç), etj. Ata të cilëve u mungon linja e komandës dhe programet Linux në Windows, do të gjejnë një prizë për veten e tyre në Cygwin.

Instalimi i Cygwin është i thjeshtë. Shkoni në faqen zyrtare të internetit dhe shkarkoni versionin 32-bit ose 64-bit.

Një skedar i vogël është shkarkuar - ky është instaluesi. Instaluesi është grafik. Megjithëse përmban një numër të madh opsionesh, ato janë të gjitha mjaft të thjeshta dhe shumë prej tyre janë të njohur nga instaluesit e tjerë grafikë. Nëse diçka nuk është e qartë, thjesht klikoni "Next". Ndoshta vetëm dritarja e mëposhtme mund të jetë konfuze:

Këtu janë të gjithë artikujt e disponueshëm për instalim. Ne nuk kemi nevojë t'i kuptojmë ato tani. Meqenëse ato më të kërkuarat janë tashmë të shënuara për instalim. Dhe nëse diçka mungon në të ardhmen, atëherë lehtë mund ta instaloni atë të nevojshme.

Lidhja SSH (e zakonshme për Linux dhe Windows)

Përdoruesit e Linux hapin një tastierë, përdoruesit e Windows shkruajnë Cygwin.

SSH ka nevojë për informacionin e mëposhtëm për t'u lidhur:

• IP ose emri i hostit
• numri i portit
• Emri i përdoruesit
• fjalëkalimi i përdoruesit

Dy prej këtyre parametrave mund të supozojë SSH: emri i përdoruesit dhe numri i portit. Nëse nuk specifikohet asnjë port, supozohet porta e paracaktuar. Nëse nuk specifikohet asnjë përdorues, atëherë përdoret i njëjti emër si në sistemin nga i cili është bërë lidhja. Për shembull, adresa e hostit për lidhjen është 192.168.1.36. Nëse shkruaj

Ssh 192.168.1.36

Unë shoh sa vijon

[email i mbrojtur]~ $ ssh 192.168.1.36 Autenticiteti i hostit "192.168.1.36 (192.168.1.36)" nuk mund të "përcaktohet. Gjurma e gishtit të kyçit ECDSA është SHA256: sIxZeSuiivoEQ00RXEAP8SQH5rxyl, jeni i sigurt që po vazhdoni të lidhni me //xylxuf.

Meqenëse po lidhem me hostin për herë të parë, është një host i panjohur. Më pyesin nëse dua të vazhdoj. Unë jam duke shtypur po:

Paralajmërim: Shtuar përgjithmonë "192.168.1.36" (ECDSA) në listën e hosteve të njohur. [email i mbrojtur] Fjalëkalimi i "s:

Në rregull, hosti 192.168.1.36 është shtuar në listën e hosteve të njohur. Më kërkohet një fjalëkalim për përdoruesin Alex. Meqenëse nuk ka një përdorues të tillë në server me SSH, por unë klikoj Ctrl + C(për të thyer) dhe futni komandën së bashku me emrin e përdoruesit të sistemit në distancë. Përdoruesi futet përpara adresës së makinës në distancë dhe ndahet nga adresa me simbolin @. Simboli @ në anglisht lexohet si në dhe mund të përkthehet si "në". ato. regjistrimi [email i mbrojtur] mund të interpretohet si "mial i përdoruesit në makinën 192.168.1.36".

Ssh [email i mbrojtur]

Ftesë [email i mbrojtur] i la vendin një ftese [email i mbrojtur] Kjo do të thotë që ne jemi tashmë në një makinë në distancë, domethënë, ne tashmë kemi një lidhje. Nëse duhet të specifikoni një port (nëse ndryshon nga ai standard), atëherë porti duhet të specifikohet pas ndërprerësit -p. Për shembull si kjo:

Ssh [email i mbrojtur]-f 10456

Pas lidhjes, ne përshëndesemi me diçka si përshëndetja e mëposhtme:

Linux mint 3.16.0-4-amd64 # 1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 Programet e përfshira me sistemin Debian GNU / Linux janë softuer falas; kushtet e sakta të shpërndarjes për secilin program përshkruhen në skedarët individualë në / usr / share / doc / * / copyright. Debian GNU / Linux vjen me ASNJË GARANCI, në masën e lejuar nga ligji në fuqi. Hyrja e fundit: Mar 16 Qershor 15:32:25 2015 nga 192.168.1.35

Kjo nënkupton që makina në distancë është Linux Mint, me kernel 3.16, version 64-bit. Gjithashtu informacione të rëndësishme për kohën e hyrjes së fundit dhe adresën IP nga e cila filloi lidhja. Nëse koha dhe IP nuk janë të njohura për ju, dhe ju jeni përdoruesi i vetëm, atëherë sistemi juaj është i rrezikuar dhe ju duhet të ndërmerrni veprimet e duhura.

Le të shkruajmë disa komanda për t'u siguruar se ku jemi dhe kush jemi: pwd, unname -a etj.:

Për të përfunduar seancën (shkëputeni), shkruani

Ose shtypni Ctrl + D.

Hyni në SSH pa futur një fjalëkalim

Së pari, është thjesht më i përshtatshëm. Së dyti, është më e sigurt.

Së pari, ne duhet të krijojmë çelësat rsa. Nëse jeni përdorues Linux, atëherë jeni mirë. Nëse jeni përdorues i Windows, por nuk keni dëgjuar këshillat e mia dhe keni zgjedhur PuTTY, atëherë keni një problem dhe mendoni vetë se si ta zgjidhni atë. Nëse keni Cygwin, atëherë gjithçka është gjithashtu në rregull.

Nëse keni arritur të identifikoheni në sistemin në distancë, dilni. Pastaj shkruani

Ssh-keygen -t rsa

Na kërkohet emri i skedarit, nuk ka nevojë të fusim asgjë, do të përdoret emri i paracaktuar. Kërkohet edhe fjalëkalimi. Unë nuk fus një fjalëkalim.

Tani në makinën në distancë, ne duhet të krijojmë drejtorinë .ssh. Ekzekutimi i komandës në një makinë në distancë do të përshkruhet më poshtë. Tani për tani, thjesht kopjoni komandën, duke kujtuar të ndryshoni adresën IP dhe emrin e përdoruesit në tuajin:

Ssh [email i mbrojtur] mkdir .ssh

Tani duhet të kopjojmë përmbajtjen e skedarit id_rsa.pub në makinën në distancë. Është shumë e lehtë për ta bërë këtë (mos harroni të ndryshoni të dhënat në tuajat):

Cat .ssh / id_rsa.pub | ssh [email i mbrojtur]"cat >> .ssh / autorized_keys"

Tani ne thjesht hyjmë dhe nuk na kërkojmë më fjalëkalim. Dhe tani do të jetë gjithmonë kështu.

Ekzekutimi i komandave në një server të largët pa krijuar një sesion shell

Përveç hapjes së një sesioni shell në një sistem në distancë, ssh gjithashtu lejon që komandat individuale të ekzekutohen në sistemin në distancë. Për shembull, për të ekzekutuar komandën e pemës në një host të largët të quajtur remote-sys dhe për të shfaqur rezultatet në sistemin lokal, duhet të bëni këtë:

ssh remote-sys pemë

Shembulli im i jetës reale:

Ssh [email i mbrojtur] pemë

Duke përdorur këtë teknikë, mund të bëni gjëra interesante, të tilla si ekzekutimi i komandës ls në sistemin në distancë dhe ridrejtimi i daljes në një skedar në sistemin lokal:

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

Një shembull i vërtetë:

Ssh [email i mbrojtur]"ls *"> dirlist.txt mace dirlist.txt

Vini re thonjëzat e vetme në komandën e mësipërme. Kjo është për shkak se ne nuk duam që zgjerimi i rrugës të bëhet në makinën lokale; pasi ne kemi nevojë për këtë ekzekutim në një sistem të largët. Gjithashtu, nëse duam të ridrejtojmë daljen standarde në një skedar në makinën në distancë, mund të vendosim deklaratën e ridrejtimit dhe emrin e skedarit brenda thonjëzave të vetme:

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

Dërgimi i stdout nga makina lokale në ssh në distancë

Një version po aq interesant i ekzekutimit të komandës është paraqitur pak më lart:

Cat .ssh / id_rsa.pub | ssh [email i mbrojtur]"cat >> .ssh / autorized_keys"

• Komanda cat lexon dhe shfaq përmbajtjen e skedarit .ssh / id_rsa.pub në makinën lokale rresht pas rreshti.
• | (tub) kalon atë që duhet të shfaqet në stdout në një komandë tjetër.
• Në vend të një komande që duhet të kishte përpunuar linjat e kaluara në të, bëhet një lidhje me sistemin në distancë (ssh [email i mbrojtur]).
• Sistemi në distancë merr linja për të cilat ofrohet komanda cat >> .ssh / autorized_keys. ato. përmbajtja e prodhimit standard shkruhen rresht pas rreshti në skedarin .ssh / autorized_keys në makinën në distancë.

Hapja e një programi grafik të vendosur në një kompjuter të largët

Truku tjetër kërkon dy kompjuterë Linux. Fatkeqësisht, as Cygwin nuk mund ta përballojë këtë mashtrim. Për më tepër, të dy Linux duhet të jenë me një ndërfaqe grafike të përdoruesit.

Tunelizim me SSH

Ndër të tjera, ajo që ndodh kur bëhet një lidhje me një host të largët nëpërmjet SSH është krijimi i një tuneli të koduar që formohet midis sistemeve lokale dhe të largëta. Në mënyrë tipike, ky tunel përdoret për të siguruar që komandat e shtypura në makinën lokale të transmetohen në mënyrë të sigurt në makinën në distancë, dhe rezultati gjithashtu dërgohet në mënyrë të sigurt.

Përveç këtij funksioni bazë, SSH lejon që shumica e llojeve të trafikut të drejtohen përmes një tuneli të koduar, duke krijuar një lloj VPN (rrjeti privat virtual) midis sistemeve lokale dhe të largëta.

Ndoshta më e përdorura nga këto veçori është aftësia për të transmetuar trafikun e sistemit X Window. Në një sistem që drejton një server X (këto janë makina që kanë një ndërfaqe grafike të përdoruesit), është e mundur të ekzekutoni një program klienti X (aplikacion grafik) në një sistem të largët dhe të shihni rezultatet e punës së tij në sistemin lokal. Kjo është e lehtë për t'u bërë. Për shembull, unë dua të lidhem me hostin e largët remote-sys dhe mbi të dua të ekzekutoj programin xload. Në të njëjtën kohë, unë do të jem në gjendje të shoh daljen grafike të këtij programi në kompjuterin lokal. Kjo bëhet si kjo:

ssh -X remote-sys

Një shembull i vërtetë:

Ssh -X [email i mbrojtur] gedit

ato. SSH fillon me çelësin -X. Dhe pastaj programi sapo fillon. Hidhini një sy pamjes së ekranit.

Unë jam në Kali Linux. Unë jam duke hyrë me sukses në kompjuterin në distancë nëpërmjet SSH. Pas kësaj, unë drejtova programin gedit. Ky program mund të mos jetë as i disponueshëm në Kali Linux, por sigurisht që është në Linux Mint, me të cilin u lidha. Unë mund të shoh rezultatin e këtij programi në ekran sikur programi të funksiononte lokalisht. Por, përsëri, dua që ju ta kuptoni këtë, nuk ka asnjë program gedit që funksionon në kompjuterin lokal. Nëse dua të ruaj rezultatin e punës së gedit (ose ndonjë program tjetër të hapur në këtë mënyrë), atëherë rezulton se ai funksionon në mjedisin e kompjuterit në distancë, sheh sistemin e tij të skedarëve, etj. Kjo është e përshtatshme kur ju dëshironi të konfiguroni kompjuterin në distancë duke përdorur një ndërfaqe grafike ...

Do të mësoni se si të transferoni një imazh nga i gjithë desktopi në të njëjtin artikull më vonë, në seksionin "Si të konfiguroni VNC mbi SSH".

Në disa sisteme, ky "fokus" kërkon përdorimin e opsionit -Y në vend të opsionit -X.

Kopjo nga / në kompjuter në distancë (scp dhe sftp)

scp

Paketa OpenSSH përfshin gjithashtu dy programe që përdorin një tunel të koduar SSH për të kopjuar skedarët në rrjet. Programi i parë është scp("Kopje e sigurt") - përdoret më shpesh, si dhe një program i ngjashëm cp për kopjimin e skedarëve. Dallimi më i dukshëm është se burimi i skedarit mund të jetë një host i largët i ndjekur nga një dy pika dhe vendndodhja e skedarit. Për shembull, nëse duam të kopjojmë një dokument të quajtur document.txt nga direktoria jonë kryesore në sistemin remote-sys në drejtorinë aktuale të punës në sistemin tonë lokal, mund ta bëjmë këtë:

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

Një shembull i vërtetë:

# fshi skedarin në makinën lokale, nëse është i pranishëm rm dirlist.txt # krijoni skedarin në makinën ssh të largët [email i mbrojtur]"ls *> dirlist.txt" # kontrolloni praninë e tij ssh [email i mbrojtur]"ls -l" # kopjojeni atë në makinën lokale scp [email i mbrojtur]: dirlist.txt. # kontrolloni përmbajtjen e tij cat dirlist.txt

Për të kopjuar një skedar nga një makinë lokale në një të largët:

skedar scp-lokal remote-sys :.

Shembull i vërtetë

# krijoni një skedar të ri me prekje nfile.txt # dërgoni skedarin scp nfile.txt [email i mbrojtur]:. nfile.txt 100% 0 0.0 KB / s 00:00 # kontrolloni nëse skedari ekziston në makinën e largët ssh [email i mbrojtur]"ls -l"

Në komandën e dërgimit:

• nfile.txt - emri i skedarit,
• [email i mbrojtur]- emri i përdoruesit dhe hosti në distancë,
• ... (pika) do të thotë që skedari duhet të kopjohet në drejtorinë aktuale të punës në serverin e largët, ndërsa emri i skedarit do të mbetet i njëjtë, d.m.th. nfile.txt

Memo:

Për të kopjuar një skedar nga B në A kur jeni regjistruar në B:

scp / shteg / në / skedar [email i mbrojtur]: / shteg / për në / destinacion

Kopjimi i një skedari nga B në A kur hyni në A:

scp [email i mbrojtur]: / shteg / në / skedar / shteg / drejt / destinacion

sftp

Programi i dytë për kopjimin e skedarëve mbi SSH është sftp... Siç sugjeron emri i tij, ai është një zëvendësues i sigurt për programet ftp. sftp funksionon si programi origjinal ftp. Sidoqoftë, në vend që të dërgojë tekst të qartë, ai përdor një tunel të koduar SSH. Një avantazh i rëndësishëm i sftp mbi ftp është se ai nuk kërkon një server FTP që funksionon në hostin e largët. Kërkon vetëm një server SSH. Kjo do të thotë që çdo makinë në distancë që është e lidhur nëpërmjet një klienti SSH mund të përdoret gjithashtu si një server i ngjashëm me FTP. Këtu është një sesion shembull:

[email i mbrojtur]~ $ sftp [email i mbrojtur] Lidhur me 192.168.1.36. sftp> ls dirlist.txt newfile.txt nfile.txt temp Videot Dokumentet Shkarkimet Imazhet Muzika Modelet e Desktopit Publik sftp> lls dirlist.txt nfile.txt sftp> ls temp / TakeMeHome sftp> Cd get temp / /Hptch temp / TakeMeHome në TakeMeHome sftp> mirupafshim

Protokolli SFTP mbështetet nga shumë menaxherë skedarësh grafikë që gjenden në shpërndarjet Linux. Duke përdorur të dy Nautilus (GNOME) dhe Konqueror (KDE), ne mund të fusim URI (lidhje) duke filluar me sftp: // në shiritin e navigimit dhe të punojmë me skedarët e vendosur në një sistem të largët që drejton një server SSH.

Garantuesi është një ndërmjetës i besueshëm ndërmjet pjesëmarrësve në transaksion.

SSH (Secure Shell) është një protokoll i qasjes në distancë në rrjet që përdor enkriptimin dhe kompresimin për të dhënat e transmetuara. E thënë thjesht, është një mjet shumë i dobishëm dhe i fuqishëm që ju lejon të vërtetoni në sistem dhe të punoni plotësisht në emër të një përdoruesi lokal, duke qenë shumë kilometra larg një makinerie që funksionon. Gjithashtu, ndryshe nga telnet dhe rsh - SSH kodon të gjithë trafikun, në mënyrë që të gjitha informacionet e transmetuara të mbeten konfidenciale.

Pra, ne tashmë kemi ssh të instaluar dhe ssh-daemon i shtohet fillimit në fillimin e sistemit. Ju mund ta kontrolloni atë me komandë:

shërbimi ssh stop | start | rinis

Në Ubuntu, ose:

/etc/init.d/ssh (fillimi | ndalimi | ringarkimi | ringarkimi me forcë | rinisja | statusi)

Në Debian, ose:

systemctl start | stop | rinis sshd.service

Në ArchLinux (pas çdo redaktimi të konfigurimit, duhet të rinisni). Kompleti përfshin një klient dhe një server.

Le ta provojmë në veprim! Së pari, krijoni një dosje ~ / .ssh

mkdir ~ / .ssh

Gjeneroni çelësat për përdoruesin e caktuar të serverit me komandën:

ssh-keygen (si përdorues i rregullt).

Kur gjeneroni, mund të vendosni një frazë kalimi për çelësin (është e këshillueshme të vendosni një të gjatë - atëherë edhe pasi të keni marrë çelësin, por duke mos ditur fjalëkalimin nga çelësi, sulmuesi nuk do të jetë në gjendje të identifikohet), ose mundeni kalojeni thjesht duke shtypur "Enter" - në këtë rast, fjalëkalimi nuk do të kërkohet kurrë. Të njëjtët çelësa publikë dhe privatë u shfaqën në dosjen ~ / .ssh.

Gjeni një makinë tjetër (edhe një smartphone do të bëjë - ka disa klientë të shkëlqyer SSH në Android, si ConnectBot ose JuiceSSH), instaloni ssh në të dhe lidheni me serverin me komandën:

ssh [email i mbrojtur]

Nëse gjithçka është bërë në mënyrë korrekte, do t'ju kërkohet fjalëkalimi i përdoruesit dhe pas hyrjes do të gjeni veten në sistemin tuaj me një pamje nga vija e komandës.

Për Windows, nga rruga, ka edhe serverë dhe klientë ssh.

Pasi kemi shijuar rezultatin e punës sonë, le të kalojmë në një pjesë edhe më të mërzitshme - konfigurimin e klientit / serverit.

Konfigurimi nga ana e klientit është i përfshirë / etc / ssh / ssh_config, dhe serveri një - / etc / ssh / sshd_config... Udhëzuesi më i plotë i konfigurimit është ndoshta faqja man për man ssh dhe man sshd_config, kështu që ju rekomandojmë ta lexoni. Dhe në këtë artikull do të shqyrtojmë gjërat më të nevojshme.

Përshtatje

Porta standarde ssh është 22. Ajo mund të ndryshohet në çdo jo standarde (duke e bërë më të vështirë hakimin për shkak të sigurisë përmes errësirës, ​​ose për të tërhequr vëmendjen e sulmuesve të mundshëm :) - për ta bërë këtë, hiqni komentin nga rreshti:

#Port 22

Dhe shtoni çdo gjë që dëshironi deri në 65535 (duke u siguruar që porti të mos bie ndesh me shërbimet e tjera me komandën #netstat -tupln | grep Dëgjo).

Tani, kur lidhet me serverin, klienti do të duhet të shkruajë me çelësin:

ssh -p [port]:

Si parazgjedhje, qasja në rrënjë lejohet. Është shumë e këshillueshme që ta kufizoni atë (dhe në vend të kësaj të kufizoni siç duhet të drejtat e përdoruesve lokalë duke përdorur sudo). Për ta bërë këtë, gjeni rreshtin "PermitRootLogin" dhe ndryshoni vlerën në "jo". Ju gjithashtu mund ta ndryshoni atë në "pa fjalëkalim" - në këtë rast, identifikimi nën rrënjë do të lejohet vetëm nga nën makinat me një çelës të besuar.

Mund të çaktivizoni vërtetimin e fjalëkalimit dhe të punoni vetëm me çelësa - gjeni rreshtin: "PasswordAuthentication" dhe ndryshoni vlerën në "jo". Per cfare? Nëse dikush me të vërtetë dëshiron të fitojë akses në sistemin tuaj, atëherë ai ose mund ta detyrojë me forcë fjalëkalimin kur përpiqet të autorizojë, ose të dëgjojë dhe deshifrojë lidhjen tuaj. Nëse çaktivizoni vërtetimin e fjalëkalimit dhe shtoni në ~ / .ssh / autorized_keys në server çelësin publik të laptopit tuaj të punës, për shembull, atëherë, siç e kujtojmë, ne do të lejohemi menjëherë në server. Por, çka nëse jeni duke punuar në makinën e dikujt tjetër dhe keni nevojë urgjente për të hyrë në serverin ssh, por ai, siç pritej, nuk do të na lejojë të hyjmë? Atëherë nuk mund të çaktivizoni vërtetimin e fjalëkalimit, por përdorni mjetin fail2ban. Thjesht instaloni atë nga depoja juaj, pas së cilës do të aplikojë cilësimet e paracaktuara dhe të paktën do të mbrojë kanalin tuaj ssh nga sulmet e forcës brutale. Më shumë rreth fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.

Në rast se serveri juaj ruan çelësat për lëshimin e raketave bërthamore, mund të bëni diçka si kjo:

PermitRootLogin jo - identifikimi nën rrënjë është i ndaluar.

PasswordAuthentication no - hyrje pa fjalëkalim

Le të gjenerojmë një çelës të gjatë në makinën në distancë (-t encryption_type, -b gjatësia e bitit):

ssh-keygen -t rsa -b 4096

Me një frazë kalimi po aq kompleks (meqë ra fjala, nuk mund të rikuperoni një fjalëkalim të harruar. Mund ta ndryshoni atë me komandën "ssh-keygen -p", por gjithsesi do t'ju kërkohet i vjetri). Le të transferojmë çelësin publik të makinës lokale në distancë në ~ / .ssh / autorized_keys në server, dhe voila - tani qasja mund të merret nga një makinë e vetme, duke përdorur frazën e kalimit të çelësit privat. SSH ju lejon të vendosni shumë konfigurime sigurie dhe ka shumë cilësime specifike për këtë - lexoni rreth tyre tek njeriu.

Dy opsione sshd_config shërbejnë për të njëjtin qëllim:

LoginGraceTime- cakton kohën pas së cilës lidhja do të shkëputet nëse nuk ndodh vërtetimi.

MaxAuthTries- cakton numrin e përpjekjeve të pasakta për të hyrë në hyrje, me arritjen e së cilës lidhja do të ndërpritet.

MaxSessions- numri i seancave të njëkohshme (nëse serveri është kompjuteri juaj i shtëpisë me të cilin do të lidheni nga universiteti ose nga puna, atëherë do të ishte e arsyeshme të kufizohej numri i seancave në një - një hyrje e refuzuar, në këtë rast, do të bëhet shkak për rritjen e paranojës, gjenerimin e çelësave të rinj dhe ndryshimin e fjalëkalimit). Megjithatë, nëse jeni të kujdesshëm, mund të keni vënë re se linja "Last Login" shfaqet në çdo hyrje në server. Përveç tij, mund të shtoni mesazhin tuaj përshëndetës - gjeni rreshtin "Banner" dhe në vend të asnjë, vendosni shtegun për në skedar me tekstin që do të lexohet dhe shfaqet në hyrje.

Ndër të tjera, ju mund të lejoni vetëm disa përdorues të identifikohen, ose të lejoni të gjithë, përveç përdoruesve të caktuar:

AllowUsers user1- lejo hyrjen vetëm të përdoruesit1.

Përdoruesi i DenyUsers1- lejoni të gjithë përveç përdoruesit 1.

Dhe parametra të ngjashëm për të hyrë në grupe të caktuara janë AllowGroups dhe DenyGroups.

Ju gjithashtu mund të SSH një sesion X11. Për ta bërë këtë, gjeni rreshtin "ForwardX11" dhe ndryshoni vlerën në "po".

Gjeni një linjë të ngjashme në konfigurimin e klientit - / etc / ssh / ssh_config, dhe gjithashtu ndryshoni në "po".

Tani ju duhet të lidheni me serverin përmes ssh me argumentin -X:

ssh -X [email i mbrojtur]>

Ju mund ta nisni menjëherë aplikacionin kur lidheni:

ssh -X [email i mbrojtur]"Shtojca"

Kështu duket një GIMP që funksionon në një seancë ssh:

Ose mund të merrni rezultatin nga uebkamera e laptopit të një përdoruesi që nuk dyshon :)

Llogaritjet kryhen direkt në server dhe dalja dërgohet në makinën e klientit (d.m.th., edhe nëse vetë serveri nuk ka X11, aplikacionet grafike mund të jepen në makinën tuaj në distancë). Kjo skemë funksionon mjaft ngadalë (mos harroni se i gjithë trafiku është i koduar në mënyrë dinamike) - por ky funksion është shumë i dobishëm.

Ju gjithashtu mund të kopjoni skedarë në një seancë SSH - ekziston një mjet i thjeshtë "scp" për këtë. Ju mund të transferoni skedarë direkt në seancë nga serveri te klienti:

scp [email i mbrojtur]: / shtegu / te / skedari / në / server / ku / ruaj / në / lokal / makinë

Pra, nga klienti në server:

shtegu scp / në / skedar / klient [email i mbrojtur]: / shteg / në / server

Kjo është mjaft e përshtatshme nëse keni nevojë të kopjoni një libër shkollor ose një foto, por po kur duhet të punoni me shumë skedarë? Ekziston një gjë shumë e përshtatshme për këtë - sshfs (e disponueshme për instalim në depot e shumicës së sistemeve * nix).

Thjesht vendosni shtegun si scp:

sshfs [email i mbrojtur]: / shtëpi / përdorues / mnt /

Dhe dosja e serverit / shtëpia / përdoruesi do të shfaqet në pikën e montimit / mnt të makinës lokale!

Çmontimi bëhet nëpërmjet umount.

Dhe së fundi, le të flasim për një veçori pak të njohur. Nëse krijoni një skedar /.ssh/config dhe mbusheni si kjo:

Pritësi [emri]

Emri i hostit

Përdoruesi [emri i përdoruesit të serverit]

opsionet e dëshiruara

si

PërparaX11 po

Porta 30,000

Atëherë ne mund të identifikohemi duke:

ssh [emri]

ssh -X -p 30000 [email i mbrojtur]

Dhe të gjitha opsionet do të merren automatikisht. Kështu, me vërtetimin e shpeshtë në një server specifik, ju do ta thjeshtoni këtë proces për disa momente.

Epo, ne mbuluam gjithçka (dhe edhe më shumë) që ju duhet të dini për SSH për përdorimin e tij të përditshëm - mësuam se si të përdorim vërtetimin e çelësit, mbrojtëm serverin nga sulmet me forcë brutale dhe, në përgjithësi, rregulluam shumicën e vrimave të mundshme. Në fakt, SSH mund të bëjë shumë gjëra të tjera - për shembull, tunelimin dhe përcjelljen e portit përmes një sesioni ssh, por nuk ka gjasa që ju, si përdorues i zakonshëm, ta përdorni ndonjëherë këtë. Burime Shtesë

Në këtë artikull, ne do të shikojmë mënyra moderne dhe të përshtatshme për të punuar me një server përmes SSH me një VPS nga Infobox dhe një re.

Ne do t'ju tregojmë jo vetëm për mënyrën e zakonshme të lidhjes, por edhe për organizimin e një lidhjeje të qëndrueshme përmes një interneti të paqëndrueshëm (për shembull, modemet 3G), si dhe për shërbimet shtesë që ndihmojnë në punën mbi SSH.

Nëse jeni përdorues i Windows dhe duhet të lidheni lehtësisht dhe shpejt me një server Linux - shkoni te seksioni "Stuko ose si të lidheni shpejt me SSH nga Windows".

Çfarë duhet të dini për t'u lidhur me SSH

Për t'u lidhur ju duhet:

• Adresa IP e serverit
• identifikimi
• fjalëkalimin

Ku mund të merrni të dhënat për t'u lidhur me serverin VPS NG nga Infobox

Pasi të porosisni shërbimin, futni panelin e kontrollit https://panel.infobox.ru.
Zgjidhni shërbimin "VPS NG" në këndin e sipërm djathtas të panelit të kontrollit në listën rënëse.
Pastaj shkoni te skedari "VPS".

Në këtë seksion do të shihni adresa IP e serverit dhe mund ta instaloni fjalëkalimin për të hyrë në server.

Përdorni emrin tuaj të përdoruesit për t'u lidhur rrënjë, adresa IP nga kjo faqe dhe të instaluar fjalëkalimin.
Nëse keni harruar fjalëkalimin tuaj, klikoni në artikullin "Modifiko cilësimet e hyrjes" të paraqitur në pamjen e mësipërme.

Ku mund të merrni të dhënat për t'u lidhur me serverin VPS nga Infobox

Hyni në panelin e kontrollit https://panel.infobox.ru.
Zgjidhni shërbimin VPS në këndin e sipërm djathtas të panelit të kontrollit në listën rënëse (emri i shërbimit përmban emrin e sistemit operativ të porositur dhe rajonin e vendndodhjes).

Pastaj shkoni te skeda "Menaxhimi i VPS".

Përdorni emrin e përdoruesit rrënjë, fjalëkalimin dhe adresën IP të serverit nga kjo faqe.

Ku të merrni të dhëna për t'u lidhur me serverin InfoboxCloud

Pas krijimit të serverit, të dhënat e lidhjes do t'ju dërgohen me e-mail. Kjo është e mjaftueshme për lidhjen.

Nëse e keni humbur emailin me të dhënat e aksesit dhe dëshironi të keni akses në server

Si parazgjedhje, identifikimi i administratorit të serverit është: root

Hyni në panelin e kontrollit në: https://panel.infobox.ru.
Zgjidhni shërbimin "Cloud Servers" në këndin e sipërm të djathtë të panelit të kontrollit në listën rënëse.

Adresa IP e dedikuar për serverin mund të shihet në skedën "Infrastruktura në renë kompjuterike" të panelit të kontrollit.

Nëse fusha " Adresa IP e dedikuar"bosh, do të thotë që kur krijoni serverin, nuk keni shtuar të paktën 1 adresë IP të dedikuar në server (dhe për këtë arsye nuk ka qasje në server përmes Internetit, ka vetëm nga rrjeti lokal).

Për të shtuar një adresë IP të dedikuar, klikoni në emrin e serverit.

Në grupin e cilësimeve "Rrjeti", klikoni "Konfiguro".

Sigurohuni që gjerësia e brezit (shpejtësia) e rrjetit të jetë e mjaftueshme (ose të vendosni më shumë nëse është e nevojshme).
Pastaj klikoni Shto adresën IPv4 dhe klikoni Ruaj ndryshimet.

Serveri tani ka një adresë IP të dedikuar.

Për të ndryshuar fjalëkalimin për të hyrë në server, klikoni "Ndrysho", siç tregohet në pamjen e mësipërme. Kështu mund të vendosni një fjalëkalim për të hyrë në server.
Tani ju e dini adresa IP e serverit, login ( rrënjë) dhe fjalëkalimin.

Konfigurimi i klientëve SSH

Për Windows

Për t'u lidhur me serverin ju nevojitet një klient SSH. Nëse keni nevojë të lidheni shpejt, rekomandohet Putty. Nëse keni nevojë të punoni me programe unix si scp, rsync dhe ssh-copy-id, përdorni Cygwin.

Stuko ose si të lidheni shpejt me SSH nga Windows

Shkarkoni instaluesin Putty për Windows nga seksioni i versionit të fundit të lëshimit dhe instaloni Putty me cilësimet e paracaktuara.

Nisni Putty (Fillimi -> Të gjitha aplikacionet -> PuTTY -> PuTTY).

Futni adresën IP të serverit. Sigurohuni që porti 22 është zgjedhur dhe lloji i lidhjes është SSH dhe klikoni "Open".

Do të pyeteni nëse i besoni serverit me të cilin po lidheni. Ju duhet të përgjigjeni "Po".

Do të hapet një dritare lidhjeje. Përdorni root si hyrje dhe fjalëkalimin e serverit tuaj si fjalëkalim. Fjalëkalimi mund të ngjitet nga clipboard me butonin e djathtë të miut. Nuk shfaqet gjatë shtypjes dhe ngjitjes për arsye sigurie.

Lidhja u krijua me sukses.

Cygwin ose Unix-environment në kompjuterin tuaj Windows

Kur punoni me serverë Linux, mund t'ju duhet një mjedis i ngjashëm në kompjuterin tuaj. Është shumë i përshtatshëm për të përdorur të njëjtin grup të shërbimeve në server dhe në kompjuterin e punës, prandaj sigurohuni që të provoni Cygwin. Linux duket i ndërlikuar në shikim të parë. Duke zotëruar gradualisht këtë OS, do t'ju duhet gjithnjë e më shumë Cygwin. Varësues i mirë.

Lidhje e paqëndrueshme në internet kur lidheni përmes SSH - çfarë të bëni?

Shpesh, kur punoni në një rrjet të paqëndrueshëm (për shembull, përmes Internetit celular 3G / 4G ose pikave të ndryshme të hyrjes WiFi), lidhja SSH ndërpritet. Le të hedhim një vështrim se çfarë mund të bëhet në nivelin e klientit për të parandaluar nevojën për rilidhje. Këto mjete nuk janë të përshtatshme për kryerjen e operacioneve kritike në server (për shembull, përmirësimin e sistemit operativ). Për të kryer operacione kritike, duhet të përdorni gjithashtu shërbimet e përshkruara në pjesën tjetër të artikullit. Qëllimi i shërbimeve në këtë seksion është ta bëjnë SSH punën më të përshtatshme për përdoruesit.

AutoSSH

AutoSSH fillon një kopje të klientit ssh dhe monitoron lidhjen, duke rifilluar klientin ssh nëse është e nevojshme.

Autossh përdor ssh për të ndërtuar një lak ridrejtues ssh (duke u lidhur nga lokali në telekomandë dhe anasjelltas) dhe i përcjell të dhënat e testimit, duke pritur që ato të kthehen. Ai gjithashtu mbështet përdorimin e një shërbimi të jehonës në distancë për të dërguar të dhënat e provës.

AutoSSH mbështet vetëm 3 parametra:

• -M<порт>[: porta e jehonës]- përdoret për të specifikuar portën e monitorimit ose portën e monitorimit dhe portën e shërbimit echo. Nëse porti i shërbimit echo nuk është specifikuar, numri i portës tjetër përdoret për të. Për shembull, nëse është vendosur flamuri -M 20000, të dhënat e testimit do të dërgohen në portin 20000 dhe do të merren në portin 20001. Nëse specifikoni -M 0, monitorimi i lidhjes do të çaktivizohet dhe autossh do të riniset ssh vetëm kur të dilni nga ssh (ju mund ta përdorni këtë me opsionet ServerAliveInterval dhe ServerAliveCountMax në OpenSSH nëse monitorimi nuk mund të përdoret në situatën tuaj);
• -f- dërgon autossh në sfond edhe para fillimit të ssh (nuk mund të vendosni një fjalëkalim në këtë mënyrë);
• -V- shfaq versionin e autossh.

Të gjitha argumentet e tjera kalohen si parametra ssh.

Për të shmangur nevojën për të futur përsëri fjalëkalimin gjatë rivendosjes së lidhjes, lejojeni këtë përdorues të hyjë në server duke përdorur çelësin, siç tregohet në seksionin e mësipërm.

Instalimi i AutoSSH në Cygwin në Windows

Kur përdorni Cygwin në Windows, shkruani:
përditësimi apt-cyg
apt-cyg instaloni autossh

Tani mund të lidheni me serverin:
autossh -M 20000 [email i mbrojtur] _adresa_server


Lidhja është vendosur me sukses.

Në përgjithësi, autossh është një mjet mjaft i përshtatshëm për të punuar përmes lidhjeve të paqëndrueshme të Internetit dhe për organizimin e tuneleve ssh në server (ne do ta shqyrtojmë këtë skenar në një artikull të veçantë). Disavantazhi i autossh është se ky mjet nuk e zgjidh problemin nëse ndodhin vonesa të konsiderueshme në kohën e futjes së komandave në rrjet (gjë që ndodh në një rrjet 3G). Në këtë rast, do të prisni një përgjigje nga serveri për të futur çdo karakter, gjë që ngadalëson disi punën. Sidoqoftë, në kushte normale funksionimi, autossh është shumë i dobishëm për të mbajtur një lidhje ssh.

Mosh zgjidh aftësinë për të futur komanda pa pritur një përgjigje të serverit, por përputhshmëria e këtij mjeti është ende shumë e kufizuar dhe besueshmëria e tij është e ulët, kështu që nuk rekomandohet ta përdorni ende.

Si të kryeni operacione kritike dhe që kërkojnë kohë të serverit: Multiplekserët terminalë

Nëse jeni duke përditësuar sistemin operativ, duke instaluar ndonjë softuer ose thjesht duke redaktuar një skedar në server, pasi të jeni lidhur me ssh ose autossh, mos punoni drejtpërdrejt. Nëse lidhja SSH ndërpritet, ju do të humbni seancën e filluar kur lidheni nëpërmjet SSH. Për të parandaluar që kjo të ndodhë dhe kur të rilidheni përmes SSH, patjetër që do ta gjeni veten në një operacion të vazhdueshëm në server ose në një dritare të hapur redaktimi skedari nga i njëjti moment, përdorni multipleksuesit e terminalit në server: Ekrani GNU ose tmux.

Ekrani GNU

Ekrani u krijua fillimisht për të ekzekutuar seanca të shumta terminale brenda një terminali të vetëm. Sidoqoftë, ekrani ka një veçori tjetër të dobishme: aftësinë për të shkëputur seancat virtuale nga një terminal fizik dhe për t'i bashkuar me një tjetër. Kjo, në veçanti, ju lejon të ekzekutoni procese të gjata në makineritë e largëta, pa pasur nevojë të jeni vazhdimisht të kyçur në to.

1. Hyni në serverin në distancë nëpërmjet SSH.
2. Ekzekutoni ekranin atje
3. Do të shihni një përshëndetje, shtypni Enter.
4. Tani mund të bëni çfarë të doni sikur sapo jeni lidhur me serverin nëpërmjet SSH (për shembull, filloni ndonjë proces të gjatë).
5. Mund ta shkëputni seancën duke shtypur CTRL + a pastaj d. Ju madje mund të përfundoni lidhjen SSH me serverin.
6. Për t'u kthyer në seancë, rilidheni nëpërmjet SSH (ose autossh do ta bëjë këtë) dhe futni ekranin -r
Do të ktheheni në sesionin e ekzekutimit dhe procesi që keni filluar më herët vazhdon në të. Ne do t'i analizojmë multiplekserët e terminalit në më shumë detaje në artikujt vijues.

konkluzioni

Në këtë artikull, ne u përpoqëm të mbulojmë bazat e nevojshme për t'u qetësuar duke përdorur SSH nga sisteme të ndryshme operative. Sigurisht, kjo nuk është gjithçka që është e mundur, por një bazë e mirë për të filluar. Nëse gjeni një gabim në artikull, mendoni se duhet të shtoni diçka të rëndësishme, ose thjesht keni një pyetje -

SSH (Secure Shell) është një protokoll rrjeti i krijuar për të kontrolluar në distancë një server dhe për të transferuar të dhëna përmes lidhjeve të koduara TCP. Shumica e faqeve të pritjes, madje edhe ato virtuale, sot ofrojnë qasje në FTP dhe SSH. Sipas mendimit tim, kjo është e mrekullueshme, SSH është shumë më i përshtatshëm dhe më i sigurt për t'u përdorur.

Konfigurimi i SSH

Konfigurimi do të bëhet për një server të dedikuar, VDS, VPS në Debian, Ubuntu. Skedari i konfigurimit ndodhet këtu: / etc / ssh / sshd_config.
Nëse keni një pritje të rregullt, gjithçka duhet të konfigurohet siç duhet, shkoni te seksioni.

Si parazgjedhje, daemon SSHD (ne po bëjmë ndryshime në të) nuk ka nevojë për ndonjë cilësim dhe funksionon mirë. Ne do të bëjmë vetëm disa ndryshime të vogla për të kufizuar aksesin e personave të padëshiruar në server.

Si rezultat i ndryshimeve të pasakta në skedarin e konfigurimit, mund të humbni aksesin në server përmes ssh, prandaj sigurohuni që të keni opsione alternative për t'u aksesuar, për shembull, duke përdorur panelin e kontrollit ISPManager.

Si të kufizoni aksesin SSH

Të gjitha ndryshimet bëhen në / etc / ssh / sshd_config
Që ndryshimet të hyjnë në fuqi, duhet

Ndrysho portin

Porta 9724

Tani, kur autorizoni, duhet të specifikoni 9724 në vend të portit standard 22.
Metoda është shumë e thjeshtë dhe efektive kundër shumicës së robotëve të thjeshtë të hakerëve që trokasin në portet standarde. Gjëja kryesore këtu nuk është të krijoni një konflikt me shërbimet e tjera dhe të merrni një numër qëllimisht të papërdorur.

Mohoni komunikimin duke përdorur protokollin e vjetër

Këtu përcaktojmë se komunikimi është i mundur vetëm duke përdorur protokollin v2

Nëse nuk jeni regjistruar nën rrënjë, përpara të gjitha komandave të konsolës ju duhet të shtoni sudo - qëndron për Zëvendëso Përdoruesin dhe DO- ndryshoni përdoruesin dhe bëni (nën të). Për shembull, ju lejon të ekzekutoni komanda në emër të superpërdoruesit rrënjë.

Zvogëloni numrin e përpjekjeve për autorizim

MaxAuthTries 2

Numri i përpjekjeve për të futur fjalëkalimin. Si parazgjedhje 6. Nëse kërkimi dështon, sesioni i komunikimit përfundon.

Zvogëlo afatin e autorizimit

LoginGraceTime 30s

Si parazgjedhje, një seancë autorizimi mund të zgjasë 120 sekonda. Në fund të kësaj kohe, ajo shkëputet. 2 minuta për autorizim janë shumë, gjithë këtë kohë serveri e mban lidhjen të hapur, gjë që është shumë e paarsyeshme. Gjysmë minutë është e mjaftueshme për sytë.

Mbyll qasjen IP

Nëse keni nevojë vetëm për akses, mënyra më e thjeshtë dhe më e besueshme është të bllokoni aksesin nga kudo, përveç IP-së tuaj ose, nëse është dinamike, atëherë diapazoni i IP-së.

1. Hapni /etc/hosts.allow dhe shtoni SSHD atje: 192.168.1.1

   ku 192.168.1.1 është IP-ja juaj. Nëse keni një IP dinamike, përcaktoni një IP me një maskë nënrrjeti dhe shkruani nënrrjetin tuaj në vend të IP, për shembull:

   SSHD: 192.168.0.0/16

2. Hapni /etc/hosts.deny dhe shtoni atje: SSHD: ALL

Një mënyrë tjetër për të kufizuar aksesin me IP

Ju mund të përdorni udhëzimin e mëposhtëm:

AllowUsers = *@1.2.3.4

Këtu ne lejojmë aksesin vetëm për IP 1.2.3.4

Autorizimi i çelësit SSH

Do të jetë shumë më e sigurt, më e përshtatshme dhe më e saktë të konfiguroni autorizimin ssh pa një fjalëkalim. Për këtë do të përdoret autorizimi kyç.

Pra, këtu është udhëzimi:

Lidhja është vendosur. Nëse keni bërë diçka të gabuar, serveri refuzoi gabimin tonë kyç do të shfaqet gjatë autorizimit, d.m.th Serveri nuk e pranoi çelësin tonë... Në këtë rast, kaloni nëpër të gjitha pikat në mënyrë sekuenciale dhe kërkoni një gabim.

abstrakt: Ky artikull përshkruan veçori të avancuara të OpenSSH që e bëjnë jetën shumë më të lehtë për administratorët e sistemit dhe programuesit që nuk kanë frikë nga guaska. Ndryshe nga shumica e manualeve, të cilët nuk përshkruajnë asgjë përveç çelsave dhe opsioneve -L / D / R, u përpoqa të mbledh të gjitha veçoritë dhe komoditetet interesante që ssh sjell me vete.

Paralajmërim: postim shumë voluminoze, por për lehtësinë e përdorimit, vendosa të mos e pres në copa.

Tabela e përmbajtjes:

• menaxhimi kryesor
• kopjimi i skedarëve mbi ssh
• Përcjellja e transmetimeve I/O
• Montoni FS në distancë nëpërmjet ssh
• Ekzekutimi i kodit në distancë
• Pseudonimet dhe opsionet për lidhjet në .ssh / config
• Opsionet e parazgjedhura
• Përcjellja e serverit X
• ssh si çorape-proxy
• Port Forwarding - Përpara dhe Reverse
• Reverse Sox Proxy
• tunelizimi i trafikut L2 / L3
• Përcjellja e agjentit të autorizimit
• Tunelizim ssh mbi ssh përmes një serveri të pabesueshëm ( me shumë mundësi nuk e dini këtë)

Menaxhimi i çelësave

Teoria me pak fjalë: ssh mund të hyjë jo me fjalëkalim, por me çelës. Çelësi përbëhet nga një pjesë e hapur dhe një e mbyllur. E hapura vendoset në direktorinë kryesore të përdoruesit "i cili" hyn në server, ai i mbyllur - në direktorinë kryesore të përdoruesit që shkon në serverin e largët. Krahasohen gjysmat (e ekzagjeroj) dhe nese cdo gje eshte ne rregull e lene te shkoje. E rëndësishme: jo vetëm klienti është i autorizuar në server, por edhe serveri në lidhje me klientin (d.m.th., serveri ka çelësin e tij). Karakteristika kryesore e çelësit në krahasim me fjalëkalimin është se ai nuk mund të "vidhet" duke hakuar serverin - çelësi nuk transferohet nga klienti në server, dhe gjatë autorizimit klienti i vërteton serverit se ai zotëron çelësin. (e njëjta magji kriptografike).

Gjenerimi kryesor

Ju mund të gjeneroni çelësin tuaj duke përdorur komandën ssh-keygen. Nëse nuk i vendosni parametrat, atëherë do të kursejë gjithçka ashtu siç duhet.

Çelësi mund të mbyllet me një fjalëkalim. Ky fjalëkalim (në ndërfaqet grafike konvencionale) kërkohet një herë dhe ruhet për ca kohë. Nëse fjalëkalimi është bosh, ai nuk do të kërkohet kur e përdorni. Është e pamundur të rikuperosh një fjalëkalim të harruar.

Ju mund të ndryshoni fjalëkalimin për një çelës duke përdorur komandën ssh-keygen -p.

Struktura kryesore

(nëse pyetja për vendndodhjen është përgjigjur si parazgjedhje).
~ / .ssh / id_rsa.pub- çelësi publik. Ai kopjohet në serverët ku duhet të keni akses.
~ / .ssh / id_rsa- çelës privat. Nuk duhet t'i tregohet askujt. Nëse e kopjoni dhe ngjisni në një letër / bisedë në vend të pub-it, atëherë duhet të gjeneroni një çelës të ri. (Nuk po bëj shaka, rreth 10% e njerëzve që u kërkohet të japin çelësin ssh id_rsa, dhe nga këta dhjetë përqind janë meshkuj, 100%).

Kopjimi i çelësit në server

Në drejtorinë e përdoruesit në të cilin dëshironi të identifikoheni, nëse krijoni një skedar ~ / .ssh / çelësat e autorizuar dhe vendosni çelësin publik atje, atëherë mund të identifikoheni pa një fjalëkalim. Ju lutemi vini re se lejet në skedar nuk duhet të lejojnë përdoruesit e paautorizuar të shkruajnë në këtë skedar, përndryshe ssh nuk do ta pranojë atë. Në çelës, fusha e fundit është [email i mbrojtur] Nuk ka të bëjë me autorizimin dhe shërben vetëm për lehtësinë e përcaktimit se ku është çelësi i kujt. Vini re se kjo fushë mund të ndryshohet (ose edhe të fshihet) pa prishur strukturën e çelësit.

Nëse e dini fjalëkalimin e përdoruesit, procesi mund të thjeshtohet. Ekipi ssh-copy-id [email i mbrojtur] ju lejon të kopjoni çelësin pa modifikuar manualisht skedarët.

Shënim: Manualet e vjetra ssh përmendin autorized_keys2. Arsyeja: ishte versioni i parë i ssh, pastaj ishte i dyti (aktual), ata bënë grupin e tyre të konfigurimeve për të, të gjithë ishin shumë të lodhur dhe versioni i dytë kaloi në versione pa asnjë "2" shumë kohë më parë . Kjo do të thotë, gjithmonë autorized_çelës dhe mos mendoni për versione të ndryshme.

Nëse keni ssh në një port jo standard, atëherë ssh-copy-id kërkon pak mashtrim: ssh-copy-id "-p 443 [email i mbrojtur]"(vëmendje ndaj thonjëzave).

Çelësi i serverit

Herën e parë që hyni në server, ssh ju pyet nëse i besoni çelësit. Nëse përgjigjeni jo, lidhja mbyllet. Nëse po - çelësi ruhet në një skedar ~ / .ssh / njohur_hosts... Gjeni se ku nuk mund të jetë cili çelës (sepse nuk është sekret).

Nëse çelësi i serverit ka ndryshuar (për shembull, serveri është riinstaluar), ssh bërtet duke falsifikuar një çelës. Ju lutemi vini re se nëse serveri nuk u prek dhe ssh bërtet, atëherë po hyni në serverin e gabuar (për shembull, një kompjuter tjetër me të njëjtën IP u shfaq në rrjet, të gjitha llojet e rrjeteve lokale me 192.168.1.1, nga të cilat atje janë disa milionë në botë, veçanërisht vuajnë nga kjo) ... Skenari i "njeriut të keq në sulm në mes" nuk ka gjasa, më shpesh është thjesht një gabim me IP-në, megjithëse nëse "gjithçka është në rregull" dhe çelësi ka ndryshuar, kjo është një arsye për të ngritur nivelin e paranojës me një dy nivele (dhe nëse keni autorizim çelësi dhe serveri papritmas kërkoi një fjalëkalim - atëherë paranoja mund të aktivizohet 100% dhe fjalëkalimi nuk duhet të futet).

Ju mund të hiqni çelësin e njohur të serverit me komandën Serveri ssh-keygen -R... Në këtë rast, ju gjithashtu duhet të fshini çelësin IP (ato ruhen veçmas): ssh-keygen -R 127.0.0.1.

Çelësi i serverit ruhet në / etc / ssh / ssh_host_rsa_key dhe /etc/ssh/ssh_host_rsa_key.pub... Ato mund të jenë:
a) kopjoni nga serveri i vjetër në atë të ri.
b) gjenerojnë me ssh-keygen. Ju nuk keni nevojë të vendosni një fjalëkalim (d.m.th. bosh). Serveri ssh nuk mund të përdorë çelësin me fjalëkalim.

Shënim, nëse klononi serverë (për shembull, në makinat virtuale), atëherë çelësat ssh të serverit duhet të rigjenerohen.

Në të njëjtën kohë, është më mirë të hiqni çelësat e vjetër nga know_hosts, përndryshe ssh do të betohet për çelësin e kopjuar.

Kopjimi i skedarëve

Transferimi i skedarëve në server ndonjëherë mund të jetë i lodhshëm. Përveç përleshjes me sftp dhe gjëra të tjera të çuditshme, ssh na jep komandën scp i cili kopjon një skedar gjatë një sesioni ssh.

Rruga Scp / skedari im [email i mbrojtur]: / e plotë / shteg / drejt / e re / vendndodhja /

Ju gjithashtu mund të bëni të kundërtën:
scp [email i mbrojtur]: / e plotë / shteg / në / skedar / shteg / në / vendos / këtu

Paralajmërim për peshkun: Pavarësisht se mc mund të lidhet përmes ssh, kopjimi i skedarëve të mëdhenj do të jetë shumë i dhimbshëm. peshku (moduli mc për të punuar me ssh si fs virtuale) është shumë i ngadalshëm. 100-200 kb është kufiri, pastaj fillon testi i durimit. (Kujtova rininë time shumë të hershme, kur, duke mos ditur për scp, kopjova ~ 5 GB përmes fishit në mc, u deshën pak më shumë se 12 orë në FastEthernet).

Aftësia për të kopjuar është e madhe. Por ju dëshironi të "ruani si" - dhe menjëherë në server. Dhe për të kopjuar në modalitetin grafik jo nga një program i veçantë, por nga ndonjë i njohur.

Kjo është gjithashtu e mundur:

sshfs

Teori: Moduli i siguresave ju lejon të "eksportoni" kërkesat në sistemin e skedarëve nga kerneli përsëri në hapësirën e përdoruesit për programin e duhur. Kjo e bën të lehtë zbatimin e "sistemit pseudo-skedar". Për shembull, ne mund të ofrojmë akses në një sistem skedari të largët përmes ssh, në mënyrë që të gjitha aplikacionet lokale (me disa përjashtime) të mos dyshojnë për asgjë.

Në fakt, përjashtimi: O_DIRECT nuk mbështetet, mjerisht (ky nuk është një problem me sshfs, është një problem me siguresat në përgjithësi).

Përdorimi: instaloni paketën sshfs (do të sjellë vetë siguresën).

Në fakt, një shembull i skriptit tim që monton desunote.ru (e vendosur në kompjuterin tim të shtëpisë - fotot tregohen prej tij në këtë artikull) në laptopin tim:

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

Ne bëjmë një skedar + x, e quajmë, shkojmë në çdo aplikacion, themi ruaj dhe shiko:

Sshfs opsionet që mund të jenë të rëndësishme: -o rilidheni (thotë që të përpiqeni të rilidheni në vend të gabimeve).

Nëse punoni shumë me të dhëna nga root, atëherë mund (duhet) të bëni një idmap:

-o idmap = përdorues... Punon si më poshtë: nëse lidhemi si përdorues [email i mbrojtur], dhe lokalisht ne punojmë si përdorues vasiliy, pastaj themi "konsideroni se skedarët pupkin janë skedarë vasiliy". mirë, ose "rrënjë" nëse lidhim si rrënjë.

Në rastin tim, idmap nuk nevojitet, pasi emrat e përdoruesve (lokalë dhe të largët) janë të njëjtë.

Vini re se rezulton të funksionojë rehat vetëm nëse kemi një çelës ssh (shiko fillimin e artikullit), nëse jo, vërtetimi i fjalëkalimit kërkon 2-3 lidhje.

Mund ta fikni përsëri me komandën fusermount -u / shteg, megjithatë, nëse lidhja është e bllokuar (për shembull, nuk ka rrjet), atëherë mund / duhet ta bëni atë nga poshtë rrënjës: sudo umount -f / shteg.

Ekzekutimi i kodit në distancë

ssh mund të ekzekutojë një komandë në një server të largët dhe të mbyllë menjëherë lidhjen. Shembulli më i thjeshtë:

Ssh [email i mbrojtur] ls / etj /

Do të nxjerrë përmbajtjen e / etc / në server, ndërsa ne do të kemi një linjë komanduese lokale.

Disa aplikacione duan një terminal kontrolli. Ato duhet të ekzekutohen me opsionin -t:
ssh [email i mbrojtur]-t remove_command

Nga rruga, ne mund të bëjmë diçka të tillë:
ssh [email i mbrojtur] cat / disa / skedar | awk "(print $ 2)" | local_app

Kjo na sjell në veçorinë e mëposhtme:

Stdin / out forwarding

Le të themi se duam t'i bëjmë një kërkesë programit nga distanca dhe më pas të vendosim daljen e tij në një skedar lokal

Ssh [email i mbrojtur] komanda> my_file

Le të themi se duam të vendosim prodhimin lokal nga distanca

Mycommand | scp - [email i mbrojtur]: / shteg / remote_file

Le ta komplikojmë shembullin - mund të transferojmë skedarë nga serveri në server: Ne bëjmë një zinxhir për të vendosur stdin në 10.1.1.2, i cili nuk është i disponueshëm për ne nga jashtë:

Komanda ime | ssh [email i mbrojtur]"Scp - [email i mbrojtur]: / rruga / te / skedari "

Ekziston gjithashtu një metodë kaq qesharake për të përdorur një tub (sugjerohet me mirësi në komentet në LJ):

Tar -c * | ssh [email i mbrojtur]"cd && tar -x"

Tar i paketon skedarët me maskë në nivel lokal, i shkruan ato në stdout, nga ku ssh i lexon, i transferon në stdin në serverin e largët, ku cd i injoron (nuk lexon stdin) dhe tar i lexon dhe i shpaketon. Scp është për të varfërit, si të thuash.

Pseudonimet

Sinqerisht, deri vonë nuk e dija dhe nuk e përdorja. Është dëshmuar se është shumë komode.

Në një kompani pak a shumë të madhe, shpesh rezulton se emrat e serverëve duken kështu: spb-MX-i3.extrt.int.company.net. Dhe përdoruesi atje nuk është i barabartë me atë lokal. Kjo do të thotë, ju duhet të identifikoheni si kjo: ssh [email i mbrojtur] Duke shtypur çdo herë - nuk mund të ngopeni nga sindromat e tunelit. Në kompanitë e vogla, problemi është e kundërta - askush nuk mendon për DNS, dhe thirrja në server duket si kjo: ssh [email i mbrojtur] Me pak fjalë, por ende e bezdisshme. Akoma më dramatike nëse kemi një port jo standard, dhe, për shembull, versionin e parë të ssh (përshëndetje cisks). Atëherë gjithçka duket kështu: ssh -1 -p 334 [email i mbrojtur] Mbyt veten. Nuk dua të flas as për dramën scp.

Është e mundur të regjistrohen pseudonimet në të gjithë sistemin për IP (/ etc / hosts), por kjo është një rrugëdalje e gabuar (dhe gjithsesi printoni përdoruesin dhe opsionet). Ekziston një mënyrë më e shkurtër.

Skedari ~ / .ssh / konfigurim ju lejon të vendosni parametrat e lidhjes, duke përfshirë ato specifike për serverët, gjë që është më e rëndësishmja, për secilin server të vetin. Këtu është një shembull i konfigurimit:

Host ric Emri i hostit ooo-roga-i-kopyta.rf Administratori i përdoruesit PërparaX11 po Kompresim po Emri i hostit të shtëpisë së pritësit myhome.dyndns.org Përdoruesi vasya FjalëkalimiAutentifikimi jo

Të gjitha opsionet e disponueshme për përdorim mund të shihen në njeri ssh_config(të mos ngatërrohet me sshd_config).

Opsionet e parazgjedhura

Siç kërkohet nga UUSER: mund të specifikoni cilësimet e paracaktuara të lidhjes duke përdorur konstruktin Host *, p.sh.

Pritësi * Kompresimi i rrënjës së përdoruesit po

E njëjta gjë mund të bëhet në / etc / ssh / ssh_config (të mos ngatërrohet me / etc / ssh / ssh d _config), por kjo kërkon të drejta rrënjësore dhe vlen për të gjithë përdoruesit.

Përcjellja e serverit X

Në fakt, e prisha pak këtë pjesë në konfigurimin e shembullit të mësipërm. ForwardX11 është pikërisht ajo.

Teoria: Aplikacionet grafike Unix zakonisht përdorin një server X (wayland është në rrugë e sipër, por ende nuk është gati). Kjo do të thotë që aplikacioni niset dhe lidhet me serverin X për vizatim. Me fjalë të tjera, nëse keni një server të zhveshur pa gui dhe keni një server x lokal (në të cilin punoni), atëherë mund të aktivizoni aplikacionet nga serveri që të vizatojnë në desktopin tuaj. Zakonisht lidhja me një server X të largët nuk është gjëja më e sigurt dhe e parëndësishme. SSH e thjeshton këtë proces dhe e bën atë plotësisht të sigurt. Dhe aftësia për të mbledhur trafikun ju lejon gjithashtu të kaloni me më pak trafik (d.m.th., zvogëloni përdorimin e kanalit, domethënë zvogëloni ping (më saktë, vonesën), domethënë zvogëloni vonesat).

Çelësat: -X - përcjellja e serverit X. -Y përcjellja e autorizimit.

Është mjaft e lehtë të kujtosh kombinimin ssh -XYC [email i mbrojtur]
Në shembullin e mësipërm (emrat e kompanive janë fiktive), unë lidhem me serverin ooo-roga-and-hooves.rf për një arsye, por për të fituar akses në serverin e Windows. Ne të gjithë e dimë sigurinë e microsoft kur punojmë në rrjet, kështu që ekspozimi i RDP-së së zhveshur nga jashtë është i pakëndshëm. Në vend të kësaj, ne lidhemi me serverin përmes ssh, dhe më pas ekzekutojmë komandën rdesktop atje:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200

Dhe mrekullia, dritarja e hyrjes në Windows në desktopin tonë. Shënim, ai është i koduar me kujdes dhe i padallueshëm nga trafiku i rregullt ssh.

Çorape-prokurë

Kur e gjej veten në një hotel tjetër (kafe, konferencë), wifi lokal shpesh rezulton të jetë i tmerrshëm - porte të mbyllura, askush nuk e di se çfarë niveli sigurie. Po, dhe nuk ka shumë besim në pikat e hyrjes së njerëzve të tjerë (kjo nuk është paranojë, unë pashë mjaft se si hiqen fjalëkalimet dhe cookies duke përdorur një laptop banal, duke shpërndarë 3G për të gjithë me emrin e një kafeneje aty pranë (dhe duke shkruar interesante gjërat në proces)).

Portet e mbyllura janë një problem i veçantë. Ai jabber do të mbyllet, pastaj IMAP, pastaj diçka tjetër.

Një VPN e rregullt (pptp, l2tp, openvpn) nuk funksionon në situata të tilla - thjesht nuk lejohet. Dihet eksperimentalisht që porti 443 lihet më së shpeshti, dhe në modalitetin CONNECT, domethënë kalohet "siç është" (http normale ende mund të mbështillet në mënyrë transparente në një kallamar).

Zgjidhja është çorape-prokurë mënyra e funksionimit ssh. Parimi i tij: klienti ssh lidhet me serverin dhe dëgjon në nivel lokal. Pasi ka marrë kërkesën, ai e dërgon atë (përmes një lidhjeje të hapur) në server, serveri vendos një lidhje sipas kërkesës dhe i dërgon të gjitha të dhënat përsëri te klienti ssh. Dhe ai i përgjigjet personit që ka aplikuar. Për të punuar, duhet t'u thoni aplikacioneve "përdorni çorape-proxy". Dhe specifikoni adresën IP të përfaqësuesit. Në rastin e ssh, ky është më shpesh localhost (në këtë mënyrë nuk do t'ia jepni kanalin tuaj të huajve).

Lidhja në modalitetin sock-proxy duket si kjo:
ssh -D 8080 [email i mbrojtur]

Për shkak të faktit se wifi i njerëzve të tjerë është më shpesh jo vetëm fig, por edhe i vonuar, mund të jetë mirë të aktivizoni opsionin -C (kompresoni trafikun). Rezulton pothuajse si opera turbo (vetëm fotot nuk janë shumë të ngushta). Në surfing real në http shtyp rreth 2-3 herë (lexo - nëse ke një fatkeqësi prej 64 kbit, atëherë do të hapësh faqe megabajt jo në dy minuta, por në 40 sekonda. E këqij, por është më mirë). Por më e rëndësishmja: pa cookie të vjedhura ose seanca të dëgjuara.

Jo më kot thashë për portet e mbyllura. Porti i 22-të mbyllet saktësisht në të njëjtën mënyrë si porti "i panevojshëm" jabber. Zgjidhja është të varni serverin në portin 443. Ju nuk duhet të qëlloni me 22, ndonjëherë ka sisteme me DPI (inspektim të thellë të paketave) që "pseudo-ssl" juaj nuk do t'ju lejojë të hyni.

Kështu duket konfigurimi im:

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

Dhe këtu është një pjesë e ~ / .ssh / config nga një laptop që përshkruan vpn

Host vpn Emri i hostit desunote.ru Përdoruesi vasya Kompresimi po DynamicForward 127.1: 8080 Porta 443

(vini re shënimin "dembel" localhost - 127.1, kjo është një mënyrë krejtësisht ligjore për të shkruar 127.0.0.1)

Përcjellja e portit

Ne kalojmë në një pjesë jashtëzakonisht të vështirë për t'u kuptuar të funksionalitetit SSH, e cila ju lejon të kryeni operacione të çuditshme të tunelit TCP "nga serveri" dhe "në server".

Për të kuptuar situatën, të gjithë shembujt e mëposhtëm do t'i referohen këtij diagrami:

Komente: Dy rrjete gri. Rrjeti i parë i ngjan një rrjeti tipik zyrash (NAT), i dyti është një "portë", domethënë një server me një ndërfaqe të bardhë dhe gri që shikon në rrjetin e tij privat. Në atë që vijon, supozojmë se laptopi "yni" është A dhe "serveri" është B.

Detyrë: ne kemi një aplikacion që funksionon në nivel lokal, duhet të mundësojmë një përdorues tjetër (jashtë rrjetit tonë) ta shikojë atë.

Zgjidhja: përcjellja e portit lokal (127.0.0.1:80) në një adresë të aksesueshme nga publiku. Le të themi se B ynë "i disponueshëm publikisht" ka zënë portin e 80-të me diçka të dobishme, kështu që ne do ta përcjellim atë në një port jo standard (8080).

Konfigurimi përfundimtar: kërkesat për 8.8.8.8:8080 do të shkojnë te hosti lokal i laptopit A.

Ssh -R 127.1: 80: 8.8.8.8: 8080 [email i mbrojtur]

Opsioni -R lejon ridrejtimin nga një telekomandë ( R emote) porta e serverit në portin tuaj (lokal).
E rëndësishme: nëse duam të përdorim adresën 8.8.8.8, atëherë duhet të aktivizojmë GatewayPorts në cilësimet e serverit B.
Detyrë... Në serverin "B" një demon i caktuar (për shembull, serveri sql) po dëgjon. Aplikacioni ynë nuk është i pajtueshëm me serverin (bitness të ndryshëm, OS, administrator i keq, ndalues ​​dhe imponues i kufijve, etj.). Ne duam të aksesojmë lokalisht lokalin në distancë "y.

Konfigurimi përfundimtar: kërkesat për localhost: 3333 në "A" duhet të shërbehen nga një demon në localhost: 3128 "B".

Ssh -L 127.1: 3333: 127.1: 3128 [email i mbrojtur]

Opsioni -L lejon thirrjet lokale ( L ocal) për të dërguar te serveri në distancë.

Detyrë: Në serverin "B" një shërbim i caktuar po dëgjon në ndërfaqen gri dhe ne duam t'i japim një kolegu (192.168.0.3) mundësinë për të parë këtë aplikacion.

Konfigurimi përfundimtar: kërkesat për adresën tonë IP gri (192.168.0.2) shkojnë në ndërfaqen gri të Serverit B.

Ssh -L 192.168.0.2: 8080: 10.1.1.1: 80 [email i mbrojtur]

Tunele të mbivendosur

Sigurisht, tunelet mund të ridrejtohen.

Le ta komplikojmë detyrën: tani duam t'i tregojmë një kolegu një aplikacion që funksionon në localhost në server me adresën 10.1.1.2 (në portin 80).

Zgjidhja është e ndërlikuar:
ssh -L 192.168.0.2: 8080: 127.1: 9999 [email i mbrojtur] ssh -L 127.1: 9999: 127.1: 80 [email i mbrojtur]

Cfare po ndodh? Ne i themi ssh-së që të ridrejtojë kërkesat lokale nga adresa jonë në hostin lokal të serverit B dhe menjëherë pas lidhjes, lëshoni ssh (d.m.th., një klient ssh) në serverin B me opsionin për të dëgjuar në localhost dhe për të dërguar kërkesa në serverin 10.1.1.2 ( ku klienti duhet të lidhet). Porti 9999 zgjidhet në mënyrë arbitrare, gjëja kryesore është që përputhet në thirrjen e parë dhe në të dytën.

Reverse Sox Proxy

Nëse shembulli i mëparshëm ju dukej i thjeshtë dhe i qartë, atëherë përpiquni të merrni me mend se çfarë do të bëjë ky shembull:
ssh -D 8080 -R 127.1: 8080: 127.1: 8080 [email i mbrojtur] ssh -R 127.1: 8080: 127.1: 8080 [email i mbrojtur]

Nëse jeni një oficer sigurie, detyra e të cilit është të ndaloni përdorimin e internetit në serverin 10.1.1.2, atëherë mund të filloni t'i hiqni flokët priftit, sepse kjo komandë organizon hyrjen në internet për serverin 10.1.1.2 përmes një përfaqësues sox që funksionon në kompjuterin "A". Trafiku është plotësisht i koduar dhe i padallueshëm nga çdo trafik tjetër SSH. Dhe trafiku dalës nga kompjuteri nga pikëpamja e rrjetit 192.168.0 / 24 është i padallueshëm nga trafiku normal i kompjuterit A.

Tunelizim

Nëse deri në këtë pikë prifti i departamentit të sigurisë nuk është tullac dhe ssh ende nuk renditet si armiku numër një i sigurisë, këtu është vrasësi përfundimtar i gjithçkaje dhe të gjithëve: tunelimi i IP-së apo edhe etherneti. Në rastet më radikale, kjo lejon tunelimin e dhcp, mashtrimin e arp në distancë, zgjimin në lan dhe shëmti të tjera të nivelit të dytë.

(Unë vetë, mjerisht, nuk e përdora këtë).

Është e lehtë të kuptohet se në kushte të tilla është e pamundur që çdo DPI (inspektim i thellë i paketave) të kapë tunele të tillë - ose lejohet ssh (lexo - bëj çfarë të duash), ose ssh është i ndaluar (dhe mund ta lësh me siguri një shoqëri idiotësh pa ndjerë as më të voglin keqardhje).

Përcjellja e autorizimit

Nëse mendoni se kjo është e gjitha, atëherë ... ... megjithatë, ndryshe nga autori, "fundi" i të cilit ende nuk është shkruar, lexuesi e sheh paraprakisht se ka shumë letra më poshtë dhe nuk ka asnjë intrigë.

OpenSSH lejon që serverët të përdoren si trampolinë për t'u lidhur me serverë të tjerë, edhe nëse ata serverë nuk janë të besueshëm dhe mund të abuzohen në çfarëdo mënyre që duan.

Po e përsëris foton:

Le të themi se duam të lidhemi me serverin 10.1.1.2, i cili është gati të pranojë çelësin tonë. Por ne nuk duam ta kopjojmë atë në 8.8.8.8, sepse ka një vendkalim dhe gjysma e njerëzve kanë sudo dhe mund të shfletojnë nëpër drejtoritë e njerëzve të tjerë. Një kompromis do të ishte të kishim një çelës "të ndryshëm" ssh që autorizon [email i mbrojtur] në 10.1.1.2, por nëse nuk duam të lejojmë askënd nga 8.8.8.8 në 10.1.1.2, atëherë ky nuk është një opsion (veçanërisht pasi çelësi jo vetëm që mund të përdoret, por edhe të kopjohet për veten e tyre "për një ditë me shi ").

Ssh ofron mundësinë për të përcjellë agjentin ssh (ky është një shërbim që kërkon një fjalëkalim për një çelës). Opsioni ssh -A dërgon autorizimin në një server të largët.

Thirrja duket si kjo:

Ssh -A [email i mbrojtur] ssh [email i mbrojtur]

Klienti ssh në distancë (në 8.8.8.8) mund t'i vërtetojë 10.1.1.2 se ne jemi ne vetëm nëse jemi të lidhur me këtë server dhe i kemi dhënë klientit ssh akses te agjenti i tij i autorizimit (por jo çelësi!).

Shumicën e kohës funksionon.

Megjithatë, nëse serveri është vërtet i keq, atëherë rrënja e serverit mund të përdorë folenë për të imituar kur jemi të lidhur.

Ekziston një metodë edhe më e fuqishme - e kthen ssh-në në një tub të thjeshtë (në kuptimin e një "tub") përmes të cilit ne punojmë përmes një serveri të largët.

Avantazhi kryesor i kësaj metode është pavarësia e plotë nga serveri proxy. Ai mund të përdorë një server të rremë ssh, të regjistrojë të gjitha bajtet dhe të gjitha veprimet, të përgjojë çdo të dhënë dhe t'i falsifikojë siç dëshiron - ndërveprimi shkon midis serverit "përfundimtar" dhe klientit. Nëse të dhënat në serverin e terminalit ngatërrohen, nënshkrimi nuk do të konvergojë. Nëse të dhënat nuk ngatërrohen, atëherë seanca vendoset në modalitetin e sigurt, kështu që nuk ka asgjë për të përgjuar.

Nuk e njihja këtë mjedis të mrekullueshëm, kështu që zbulova ndryshimin e tij.

Konfigurimi është i lidhur me dy veçori të ssh: opsionin -W (shndërron ssh në një "tub") dhe opsionin e konfigurimit ProxyCommand(opsionet e linjës së komandës, me sa duket, jo), që thotë "ekzekutoni programin dhe qëndroni në stdin / jashtë". Këto opsione janë shfaqur kohët e fundit, kështu që përdoruesit e centos nuk mund të diskutohen.

Duket kështu (numrat për foton e mësipërme):

Ssh / konfigurim:
Host raep HostName 10.1.1.2 Përdoruesi i përdoruesit2 ProxyCommand ssh -W% h:% p [email i mbrojtur]

Epo, lidhja është e parëndësishme: ssh raep.

Përsëri, një pikë e rëndësishme: Serveri 8.8.8.8 nuk mund të përgjojë ose të mashtrojë trafikun, të përdorë një agjent autorizimi përdoruesi ose ndryshe të ndryshojë trafikun. Moho - po, mundet. Por nëse lejohet, ai do të kalojë në vetvete pa deshifrim ose modifikim. Që konfigurimi të funksionojë, duhet të keni çelësin tuaj publik në çelësat e autorizuar si për [email i mbrojtur] dhe ne [email i mbrojtur]

Natyrisht, lidhja mund të pajiset me të gjitha baublet e tjera - përcjellja e portit, kopjimi i skedarëve, proxies sox, tunele L2, tunelimi i serverit X, etj.
ssh tunelimi shtoni etiketa