Csatlakozzon egy virtuális szerverhez SSH-n és SFTP-n keresztül. Csatlakozás a szerverhez SSH-n és SFTP-n keresztül Csatlakozás ssh-n keresztül putty-n keresztül
Mi az SSH és miért van rá szüksége?
A Secure Shell (SSH) egy hálózati protokoll, amely shell-funkciókat biztosít egy távoli gép számára egy biztonságos csatornán keresztül. Az SSH különféle biztonsági fejlesztésekkel érkezik, beleértve a felhasználó/gazda hitelesítést, az adattitkosítást és az adatintegritást, ami lehetetlenné teszi az olyan népszerű támadásokat, mint a lehallgatás, a DNS/IP-hamisítás, az adathamisítás és a kapcsolateltérítés stb. Az adatokat tiszta szövegben továbbító protokoll esetén erősen ajánlott az SSH-ra váltani.
Az OpenSSH az SSH protokoll nyílt forráskódú megvalósítása, amely lehetővé teszi a hálózati kapcsolat titkosítását egy sor programon keresztül. Ha SSH-t szeretne Linuxon, akkor telepítheti az OpenSSH-t, amely egy OpenSSH-kiszolgálóból és ügyfélcsomagokból áll.
Az OpenSSH szerver/kliens csomagok a következő segédprogramokkal érkeznek:
- OpenSSH szerver: sshd (SSH démon)
- OpenSSH kliens: scp (biztonságos távoli másolat), sftp (biztonságos fájlátvitel), slogin/ssh (biztonságos távoli bejelentkezés), ssh-add (privát kulcs befejezése), ssh-agent (hitelesítési ügynök), ssh-keygen (hitelesítési kulcskezelés) ).
Ha telepíteni szeretné az OpenSSH-kiszolgálót/klienst, és be szeretné állítani, hogy az OpenSSH-kiszolgáló automatikusan elinduljon, kövesse az alábbi utasításokat, amelyek a terjesztéstől függően változnak.
Debian, Ubuntu vagy Linux Mint
$ sudo apt-get install openssh-server openssh-client
Debian alapú rendszereken a telepítés után az OpenSSH automatikusan elindul a rendszerindításkor. Ha valamilyen okból az OpenSSH-kiszolgáló nem indul el automatikusan a rendszer indításakor, akkor a következő parancs futtatásával kifejezetten hozzáadhatja az ssh-t a rendszerindításhoz.
$ sudo update-rc.d ssh defaults
Fedora vagy CentOS/RHEL 7$ sudo yum -y install openssh-server openssh-clients $ sudo systemctl sshd szolgáltatás elindítása $ sudo systemctl sshd.service engedélyezése
CentOS/RHEL 6$ sudo yum -y install openssh-server openssh-clients $ sudo service sshd start $ sudo chkconfig sshd on
Arch Linux$ sudo pacman -Sy openssh $ sudo systemctl sshd szolgáltatás indítása $ sudo systemctl engedélyezése sshd.service
OpenSSH szerver beállításaHa be szeretné állítani az OpenSSH-kiszolgálót, szerkesztheti az /etc/ssh/sshd_config fájlban található, rendszerszintű konfigurációs fájlt.
Van néhány OpenSSH lehetőség, amelyek érdekesek lehetnek:
Alapértelmezés szerint az sshd a 22-es porton figyel, és figyel a bejövő ssh-kapcsolatokra. Az ssh alapértelmezett portjának megváltoztatásával megelőzheti a különféle automatizált hackertámadásokat.
Ha a gépen több fizikai hálózati interfész is van, érdemes megnézni, hogy melyik van társítva az sshd-vel, ehhez használhatja a ListenAddress opciót. Ez a beállítás javítja a biztonságot azáltal, hogy a bejövő SSH-t csak egy adott interfészre korlátozza.
HostKey /etc/ssh/ssh_host_key
A HostKey opció határozza meg, hogy hol található a személyes gazdagép kulcs.
PermitRootLogin sz
PermitRootLogin opció – a root be tud-e jelentkezni a rendszerbe ssh-n keresztül.
AllowUsers alice bob
Az AllowUsers opcióval szelektíven letilthatja az ssh szolgáltatást bizonyos Linux-felhasználók számára. Több felhasználót is megadhat, szóközökkel elválasztva.
Az /etc/ssh/sshd_config módosítása után feltétlenül indítsa újra az ssh szolgáltatást.
Az OpenSSH újraindítása Debian, Ubuntu vagy Linux Mint rendszeren:
$ sudo /etc/init.d/ssh újraindítás
Az OpenSSH újraindítása Fedora, CentOS/RHEL 7 vagy Arch Linux rendszeren:$ sudo systemctl indítsa újra az sshd.service fájlt
Az OpenSSH újraindítása CentOS/RHEL 6 rendszeren:$ sudo szolgáltatás sshd újraindítás
Hogyan csatlakozz az SSH-hozCsatlakozás az SSH-hoz Linuxról
A Linux-felhasználóknak nem kell további programokat telepíteniük.
Csatlakozás az SSH-hoz a Windows rendszerből
A vendégek elől rejtve
.A Cygwin több, mint egy SSH-kliens. Ez egy hatékony kombináló, amely számos Linux-parancsot támogat. Például a Cygwin nagyon megkönnyíti az SSL-tanúsítványok létrehozását (csakúgy, mint a Linux). Windowsban az önaláírt tanúsítványok létrehozásához egy tamburával kell táncolnia. A Cygwin nagyon kényelmes a cURL használata (nem kell semmit külön telepíteni), stb. Akinek hiányzik a parancssor és a Linux-programok Windowson, az a Cygwinben talál konnektort.
A Cygwin telepítése egyszerű. Menjünk-hoz
A vendégek elől rejtve
És töltse le
A vendégek elől rejtve
A vendégek elől rejtve
Egy apró fájl fog letöltődni – ez a telepítő. Grafikus telepítő. Bár számos lehetőséget tartalmaz, ezek mindegyike meglehetősen egyszerű, és sok más grafikus telepítőből is ismert. Ha valami nem világos, kattintson a „Tovább” gombra. Talán csak a következő ablak okozhat zavart:
Itt bemutatjuk az összes telepíthető elemet. Nem kell most megértenünk őket. Mert a legnépszerűbbek már beépítésre vannak jelölve. És ha valami hiányzik a jövőben, könnyen telepítheti, amire szüksége van.
SSH-kapcsolat (Linux-on és Windows-on közös)
A Linux-felhasználók megnyitják a konzolt, a Windows-felhasználók pedig a Cygwin-t írják be.
Az SSH-nak a következő információkra van szüksége a csatlakozáshoz:
- IP vagy gazdagépnév
- portszám
- Felhasználónév
- felhasználói jelszó
Ssh 192.168.1.36
A következőt látom
Alex@MiAl-PC ~ $ ssh 192.168.1.36 A "192.168.1.36 (192.168.1.36)" gazdagép hitelessége nem állapítható meg. Az ECDSA-kulcs ujjlenyomata: SHA256:sIxZeSuiivoEQ00RXEAQHP Biztosan csatlakozni akar8 ing ( igen nem)?
Mivel először csatlakozom a gazdagéphez, ez egy ismeretlen gazdagép. Megkérdezik, hogy akarom-e folytatni. tárcsázom Igen:
Figyelmeztetés: „192.168.1.36” (ECDSA) véglegesen hozzáadva az ismert gazdagépek listájához. [e-mail védett]" jelszava:
Oké, a 192.168.1.36 gazdagép felkerült az ismerős gazdagépek listájára. Jelszót kérek Alex felhasználóhoz. Mivel nincs ilyen felhasználó a szerveren SSH-val, de kattintok Ctrl+C(törni), és írja be a parancsot a távoli rendszer felhasználónevével együtt. A felhasználó a távoli gép címe elé kerül, és a @ szimbólum választja el a címtől. A @ szimbólum angol nyelven a következőnek felel meg, és „in”-nek fordítható. Azok. rekord [e-mail védett]értelmezhető: "mial user a 192.168.1.36 gépen".
Ssh [e-mail védett]
Az Alex@MiAl-PC meghívót a mial@mint meghívó váltotta fel. Ez azt jelenti, hogy már a távoli gépen vagyunk, azaz már létrehoztuk a kapcsolatot. Ha meg kell adni egy portot (ha eltér a szabványostól), akkor a portot a -p kapcsoló után kell megadni. Például így:
Ssh [e-mail védett]-p 10456
Csatlakozás után valami ilyesmi fogad minket:
Linux mint 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 A Debian GNU/Linux rendszerhez tartozó programok ingyenes szoftverek; az egyes programok pontos terjesztési feltételei a /usr/share/doc/*/copyright fájlokban találhatók. A Debian GNU/Linux TELJESEN NINCS GARANCIA, a vonatkozó törvények által megengedett mértékig. Utolsó bejelentkezés: 2015. június 16. kedd 15:32:25 192.168.1.35-től
Ebből következik, hogy a távoli gép Linux Mint, 3.16-os kernel, 64 bites verzióval. Szintén fontos információ az utolsó bejelentkezés időpontja és az IP-cím, ahonnan a kapcsolat jött. Ha az idő és az IP ismeretlen számodra, és Ön az egyetlen felhasználó, akkor rendszere veszélybe került, és meg kell tennie a megfelelő lépéseket.
Írjunk be néhány parancsot, hogy megbizonyosodjunk arról, hol vagyunk és kik vagyunk: pwd, [B]uname -a stb.:
A munkamenet befejezéséhez (kijelentkezés) tárcsázza
Vagy kattintson Ctrl+D.
Jelentkezzen be az SSH-ba jelszó megadása nélkül
Először is, sokkal kényelmesebb. Másodszor, biztonságosabb.
Először is létre kell hoznunk az rsa kulcsokat. Ha Linux felhasználó vagy, akkor minden rendben van. Ha Ön Windows-felhasználó, de nem hallgatta meg a tanácsomat, és a PuTTY-t választotta, akkor van egy problémája, és gondolja át, hogyan oldja meg. Ha Cygwin van, akkor is minden rendben van.
Ha sikerült bejelentkeznie a távoli rendszerbe, jelentkezzen ki. Ezt követően tárcsázza
Ssh-keygen -t rsa
Kérünk egy fájlnevet, nem kell semmit beírnunk, az alapértelmezett név kerül felhasználásra. Jelszót is kér. Nem írom be a jelszót.
Most a távoli gépen létre kell hoznunk egy .ssh könyvtárat. A parancs távoli gépen történő végrehajtását az alábbiakban tárgyaljuk. Egyelőre csak másolja a parancsot, ne felejtse el megváltoztatni az IP-címet és a felhasználónevet a sajátjára:
Ssh [e-mail védett] mkdir.ssh
Most át kell másolnunk az id_rsa.pub fájl tartalmát a távoli gépre. Ezt nagyon könnyű megtenni (ne felejtse el megváltoztatni az adatokat a sajátjaira):
Cat .ssh/id_rsa.pub | ssh [e-mail védett]"macska >> .ssh/authorized_keys"
Most csak bejelentkezünk, és többé nem kérnek tőlünk semmilyen jelszót. És ez most mindig így lesz.
Parancsok végrehajtása távoli szerveren shell-munkamenet létrehozása nélkül
Amellett, hogy shell-munkamenetet nyit egy távoli rendszeren, az ssh lehetővé teszi egyedi parancsok végrehajtását is a távoli rendszeren. Ha például a tree parancsot egy remote-sys nevű távoli gépen szeretné futtatni, és az eredményeket megjeleníteni a helyi rendszeren, tegye a következőket:
Ssh remote-sys fa
Az igazi példám:
Ssh [e-mail védett] fa
Ezzel a technikával érdekes dolgokat hajthat végre, például futtathat egy ls parancsot egy távoli rendszeren, és átirányítja a kimenetet egy fájlba a helyi rendszeren:
Ssh remote-sys "ls *" > dirlist.txt
Valódi példa:
Ssh [e-mail védett]"ls *" > dirlist.txt cat dirlist.txt
Jegyezze fel az idézőjeleket a fenti parancsban. Ez azért van, mert nem akarjuk, hogy az elérési út kibővítése a helyi gépen történjen; mert szükségünk van erre a végrehajtásra egy távoli rendszeren. Továbbá, ha a szabványos kimenetet át akarjuk irányítani egy fájlra a távoli gépen, akkor az átirányítási utasítást és a fájl nevét idézőjelbe helyezhetjük:
Ssh remote-sys "ls * > dirlist.txt"
A szabványos kimenet átvitele a helyi gépről a távoli gépre ssh-n keresztülA parancsok végrehajtására egy hasonlóan érdekes lehetőség egy kicsit magasabb:
Cat .ssh/id_rsa.pub | ssh [e-mail védett]"macska >> .ssh/authorized_keys"
- A cat parancs soronként olvassa, és megjeleníti a helyi gépen található .ssh/id_rsa.pub fájl tartalmát.
- | (pipe) átadja azt, ami a szabványos kimeneten jelenne meg egy másik parancsnak.
- A neki átadott karakterláncokat feldolgozó parancs helyett egy kapcsolat jön létre a távoli rendszerrel (ssh [e-mail védett]).
- A távoli rendszer fogadja azokat a vonalakat, amelyekhez a cat >> .ssh/authorized_keys parancs tartozik. Azok. a szabványos kimenet tartalma soronként a távoli gépen található .ssh/authorized_keys fájlba kerül.
A következő trükkhöz két Linux-számítógép szükséges. Sajnos még Cygwin sem tudja kezelni ezt a trükköt. Ezenkívül mindkét Linux rendszernek rendelkeznie kell grafikus felhasználói felülettel.
Alagútépítés SSH-val
Többek között, ami akkor történik, amikor SSH-n keresztül kapcsolatot létesítenek egy távoli gazdagéppel, az egy titkosított alagút létrehozása, amely a helyi és a távoli rendszer között jön létre. Általában ezt az alagutat használják annak biztosítására, hogy a helyi gépen beírt parancsokat biztonságosan továbbítsák egy távoli gépre, és az eredményt is biztonságosan visszaküldjék.
Ezen az alapvető funkción túlmenően az SSH protokoll lehetővé teszi a legtöbb forgalom titkosított alagúton történő továbbítását, egyfajta VPN-t (virtuális magánhálózat) hozva létre a helyi és távoli rendszerek között.
Ezek közül a szolgáltatások közül talán a leggyakrabban használt lehetőség az X Window rendszerek forgalmának sugárzására. X szervert futtató rendszeren (ezek grafikus felhasználói felülettel rendelkező gépek) lehetőség van egy X kliensprogram (grafikus alkalmazás) futtatására a távoli rendszeren, és a helyi rendszeren megtekintheti működésének eredményét. Könnyű megtenni. Például csatlakozni akarok a távoli host remote-sys-hez, és azon szeretném futtatni az xload programot. Ezzel egyidejűleg a program grafikus kimenetét is láthatom a helyi számítógépen. Ez így történik:
Ssh -X remote-sys xload
Valódi példa:
Ssh -X [e-mail védett] gedit
Azok. Az SSH a -X kapcsolóval indul. És akkor a program egyszerűen elindul. Nézd meg a képernyőképet.
Kali Linuxon vagyok. Sikeresen bejelentkeztem egy távoli számítógépre SSH-n keresztül. Utána lefuttattam a gedit programot. Lehet, hogy ez a program nem is Kali Linuxon van, de Linux Minton biztosan van, amihez csatlakoztam. Ennek a programnak az eredményét úgy látom a képernyőn, mintha a program helyben futna. De még egyszer szeretném, ha megértenéd, a helyi számítógépen nem fut gedit program. Ha el akarom menteni a gedit (vagy bármely más, így megnyitott program) eredményét, akkor kiderül, hogy működik a távoli számítógép környezetében, látja annak fájlrendszerét stb. Ez akkor kényelmes, ha be szeretné állítani a távoli számítógép grafikus felületet használva.
Ugyanebben a cikkben később, a „VNC konfigurálása SSH-n keresztül” részben megtudhatja, hogyan lehet képet átvinni a teljes asztalról.
Egyes rendszereken ehhez a trükkhöz az -Y kapcsoló használata szükséges az -X opció helyett.
Másolás távoli számítógépről/távoli számítógépre (scp és sftp)
scp
Az OpenSSH-csomag két olyan programot is tartalmaz, amelyek titkosított SSH-alagutat használnak a fájlok hálózaton keresztüli másolására. Első program - scp("biztonságos másolat") - gyakrabban használják, mint a hasonló cp-program fájlok másolására. A legszembetűnőbb különbség az, hogy a fájl forrása lehet a távoli gazdagép, amelyet kettőspont követ, és a fájl helye. Ha például egy document.txt nevű dokumentumot szeretnénk átmásolni a saját könyvtárunkból a remote-sys-be a helyi rendszerünk aktuális munkakönyvtárában, akkor ezt megtehetjük:
Scp remote-sys:document.txt . document.txt 100% 177 0,2KB/s 00:00
Valódi példa:
# törölje a fájlt a helyi gépen, ha létezik rm dirlist.txt # hozzon létre egy fájlt a távoli gépen ssh [e-mail védett]"ls * > dirlist.txt" # ellenőrizze a jelenlétét ssh [e-mail védett]"ls -l" # másolja a helyi gépre scp [e-mail védett]:dirlist.txt. # ellenőrizze a tartalmát cat dirlist.txt
sftpFájl másolása B-ből A-ba, amikor bejelentkezett B-be:
scp /elérési út/fájl felhasználónév@a:/útvonala/cél
Fájl másolása B-ből A-ba, amikor bejelentkezett A-ba:
scp felhasználónév@b:/fájl/elérési útja/cél/útvonal
A második program a fájlok másolására SSH-n keresztül sftp. Ahogy a neve is sugallja, ez egy biztonságos ftp programcsere. Az sftp úgy működik, mint az eredeti ftp program. Azonban ahelyett, hogy tiszta szöveget küldene, titkosított SSH-alagutat használ. Az sftp fontos előnye az ftp-vel szemben, hogy nem igényel futó FTP-kiszolgálót egy távoli gazdagépen. Csak SSH szerver kell hozzá. Ez azt jelenti, hogy bármely távoli gép, amely SSH-kliensen keresztül csatlakozik, FTP-szerű szerverként is használható. Íme egy példa munkamenet:
Alex@MiAl-PC ~ $ sftp [e-mail védett] Csatlakozva a 192.168.1.36-hoz. sftp> ls dirlist.txt newfile.txt nfile.txt temp Videók Dokumentumok Letöltések Képek Zene Nyilvános asztali sablonok sftp> lls dirlist.txt nfile.txt sftp> ls temp temp/TakeMeHome sftp> cd temp/TakeMeHome mial/temp/TakeMeHome to TakeMeHome sftp> bye
Az SFTP protokollt számos grafikus fájlkezelő támogatja, amelyek megtalálhatók a Linux disztribúciókban. A Nautilus (GNOME) és a Konqueror (KDE) használatával egyaránt megadhatjuk az sftp://-től kezdődő URI-kat (hivatkozásokat) az ugrósávban, és dolgozhatunk egy SSH-kiszolgálót futtató távoli rendszeren található fájlokkal.
Helló! Érdekel a kérdés: hogyan lehet SSH-n keresztül csatlakozni otthoni számítógépéhez az interneten keresztül. Van otthon telepítve egy FreeSSHd szerverem. Ha jól értem, valahogy meg kell nyitnom a 22-es portot a külső IP-n? Alex
Igen, gyakran felmerül az igény. Sok mindenről beszéltem abban a cikkben, de itt kizárólag az SSH-ról lesz szó, hiszen Alex kedvesen biztosította számunkra ezt a lehetőséget. Emellett engem is hihetetlenül érdekel az SSH, és itt van Windowson is... mmm.
Mi az SSH és miért van rá szükség?
A lényeg, hogy az SSH az S biztonságos SH ell. Protokoll a vezérlőhéjhoz való biztonságos hozzáféréshez. Ezért kifejezetten a parancssorhoz biztosít hozzáférést, mivel a Shell így van lefordítva héjés itt a jelentésben szövegvezérlő shell. De általánosságban ez a protokoll figyelemre méltó arról, hogy lehetővé teszi bármilyen más forgalom áthaladását rajta, és titkosított formában. Így a biztonságos fájlrendszer-kapcsolati protokoll neve SFTP, és az SSH-n fut. De teljesen bármilyen más kapcsolatot képes alagútba vezetni – legyen az HTTP vagy akár RDP. Lényegében kiderül, hogy ez egy „térdre húzódó VPN”.
Itt Alex már elvégezte a munka felét: telepítette és elindította a FreeSSHd-t otthoni számítógépén. Ez lehetővé teszi, hogy SSH-n keresztül csatlakozzon a Windowshoz. Ebben az esetben az „engedélyezést” nagyon határozottan mondják. Mert Windowson ez a megoldás valahogy működik. Először is, nincs megfelelő szöveges felülete - parancssor a vezérléshez.
Legalábbis a szokásos - cmd - segítségével keveset tehetsz a távoli géppel. Van még Powershell - ez egy modernebb és erősebb megoldás. A Freesshd lehetővé teszi, hogy a konzolt powershellre cseréld, de nem tudtam csatlakozni hozzá. Csatlakoztam a CMD-hez - de teljesen használhatatlan:
Másodszor, a FreeSSHd esetében még helyi hálózaton sem tudtam csatlakozni egy Windows számítógéphez, nem beszélve az internetről. Illetve lehetséges a csatlakozás, de a szolgáltatás lefagy és összeomlik; így nem fogja tudni kezelni a Windows gazdagépet.
Ezért feltételezem, hogy Alexnek szüksége volt egy ssh-kiszolgálóra a Windows rendszeren, hogy csatlakozzon a fájlrendszerhez, vagy VPN-ként használhassa, valamit proxyval SSH-n keresztül. Bár kétlem, hogy a FreeSSHd ezt megengedi. Mert harmadszor: nem is menti a beállításokat, a szolgáltatás újraindításakor minden elromlik. Általában nagyon remélem, hogy Alex a megjegyzésekben elmondja nekünk, miért volt szüksége erre.
Hogyan lehet máshogy futtatni az SSH-t Windowson?
Van egy működőbb megoldás - a Powershelserver. Bár vannak benne hibák is, de legalább nem omlik össze. Ezért azt javaslom, hogy SSH-n keresztül csatlakozzon a Windows szerverekhez.
Először is, stabilan működik, összeomlás nélkül. És ezen keresztül valóban vezérelheti a Windowsokat powershell-en keresztül.
Az összes beállítást a rendszer a szokásos módon menti. Ugyanazok a funkciók érhetők el, mint a FreeSSHd-ben, sőt még több is - használhatja az SCP-t - ez a fájlok másolása SSH-n keresztül.
De a legsikkesebb a konzol! Működik, uraim!
Könnyen csatlakoztam, anélkül, hogy a felhasználók hozzáadásával kellett volna foglalkoznom (ezt freesshd-ben kell megtenni). És ez az egyszerű parancs az útválasztási tábla megtekintéséhez tökéletesen működött, és megadta a szükséges információkat. A Frisssh pont akkor "leesett" nekem, amikor megpróbáltam megnézni a netstat -rn-t
Itt tényleg látszik, hogy nem jelennek meg az orosz karakterek. Így nálunk könnyű beállítani, csak beállítom a szükséges kódolást a powershellserveren, újraindítom, újracsatlakozom...
Kódolás beállítása a Powershellserverben
Most már teljes SSH-val rendelkezünk, és teljes mértékben kezelhetjük a Windows-t a konzolon keresztül.
A Microsoft elkészíti saját SSH-megoldását
A Microsoft egyébként még nyáron bejelentette, hogy fejleszteni fog anyanyelvi SSH-támogatás a Powershell számára a Windows új verzióiban. Vannak hírek a Habrén és a pcweeken (és egyebeken). Ezért csak alig várjuk ezt a mérföldkőnek számító eseményt, hiszen ez valóban áttörést jelent majd a munkában heterogén hálózatok.
Nem ellenőriztem a többi funkciót - az sftp-t és az scp-t, de valamiért biztos vagyok benne, hogy ezek is nagyszerűen fognak működni.
Hogyan lehet megnyitni egy SSH portot kívülről?
Elérkeztünk tehát ahhoz a titkos dologhoz, amiért ez a cikk eleve indult. Válaszolok az olvasó kérdésére.
Port továbbítás útválasztón vagy modemen
Ahhoz, hogy kívülről csatlakozhasson a számítógéphez, valóban NAT-ot kell végrehajtania, vagy adott esetben . Ennek módja az átjáróként használt eszköztől függ. Ez lehet ADSL modem vagy . A legtöbb esetben az eszközére vonatkozó részletes utasítások könnyen megtalálhatók az olyan lekérdezések segítségével, mint a „port forwarding eszköz_modell" vagy "port továbbítás eszköz_modell»
Így néz ki a Zyxel Keenetic Lite otthoni útválasztómon:
És így néz ki egy ADSL modemen a Linksys WAG200G router funkcionalitásával:
Ezenkívül egyes szolgáltatóknál ez technikailag nem lehetséges, mert nem biztosítják a "fehér" szolgáltatást.
Port továbbítása távoli kiszolgálóra SSH-alagút segítségével
Ebben az esetben az egyetlen mód az SSH-n keresztüli csatlakozásra egy helyi Windows-gépről (ugyanaz, amelyre SSH-n keresztül szeretnénk csatlakozni) egy távoli szerverre. Ebben az esetben SSH-hozzáféréssel kell rendelkeznie az internet valamelyik kiszolgálójához.
"Reverse" SSH alagút beállítása
Az ilyen továbbítás könnyen elvégezhető egy egyszerű SSH kliens Putty segítségével (van is) Ezután a továbbított porton keresztül csatlakozhat ehhez a nagyon távoli szerverhez.
Nos, ha meg kell osztani a Windows SSH portot a világgal, akkor elég az ip_server:3322-t megadni célként a fordított alagút beállításaiban. Bárhonnan csatlakozhat a Windowshoz SSH-n keresztül, ahol elérhető ez a szerver.
Hogyan ellenőrizhető, hogy a port megfelelően van-e továbbítva?
Nagyon egyszerű. Meg kell nézni, hogy nyitva van-e. SSH esetén a nyitott port üzenettel válaszol a verziójáról. A portok ellenőrzésének legegyszerűbb módja a telnet segédprogram.
Csak írja be a parancssorba szóközzel elválasztva:
telnet domain_or_IP port
Ha a port elérhető, valami ilyesmit fog látni:
SSH válasz, ha elérhető port
Ha a port valamilyen okból nem elérhető, akkor a „kapcsolat megtagadva” vagy a „kapcsolat időtúllépése” üzenet jelenik meg. Az első esetben ez azonnali lesz, és azt jelenti, hogy a portot tűzfal zárja le.
A második esetben „lefagyásnak” tűnik, és akár több percig is eltarthat – a telnet kliens megpróbál kapcsolatot létesíteni. Ez jelentheti a tűzfal általi blokkolást is, de más típusú. Vagy egyszerűen csak azt, hogy a megadott gazdagép nem elérhető, vagy a portja le van zárva.
Ha telneten keresztül tudott csatlakozni, nyomja meg a Ctrl+] billentyűkombinációt, és írja be Kilépés, majd Enter. Ellenkező esetben nem tudja megszakítani a munkamenetet, és új konzolablakot kell nyitnia, ha továbbra is szüksége van rá.
Ez a cikk befejezetlenként van megjelölve. Lásd a cikk végén található megjegyzést.
Ez a cikk az Ubuntu biztonságos termináljának (secure shell) kliensének és kiszolgálójának, azok konfigurációjának és használatának szentelt. Az SSH egy speciális hálózati protokoll, amely lehetővé teszi a távoli hozzáférést a számítógéphez magas fokú kapcsolatbiztonsággal. Az ssh protokollról bővebben olvashat.
A működési elvek és az alkalmazott alkalmazások leírása
Az SSH alapvetően két alkalmazás formájában valósul meg - egy SSH-kiszolgáló és egy SSH-kliens. Csatlakozáskor a kliens engedélyezési eljáráson megy keresztül a szerverrel, és titkosított kapcsolat jön létre közöttük. Az OpenSSH szerver az ssh1 és az ssh2 protokollal is működhet. Az ssh1 protokoll jelenleg nem tekinthető biztonságosnak, és használata erősen nem ajánlott. Szándékosan kihagyom a protokoll különböző technikai részleteit, mivel ennek az útmutatónak a fő célja a konfiguráció és a használat leírása. Az interneten sok cikk található magáról a protokollról, működési elveiről, titkosítási algoritmusairól stb., részletesen olvashat róla.
Telepítés
Telepítés OpenSSH Használhatja a parancsot a terminálból:
sudo apt-get install sshAz ssh metacsomag egy klienst és egy szervert is tartalmaz, de ez nagy valószínűséggel csak a szervert telepíti, mivel a kliens alapértelmezés szerint már benne van az Ubuntuban.
Szerver hangolás
Telepítéskor az SSH-kiszolgáló automatikusan hozzáadódik az indításhoz. Az indítását, leállítását vagy újraindítását a következő parancsokkal szabályozhatja:
sudo szolgáltatás ssh stop| start| újrakezdAz SSH-kiszolgáló fő konfigurációs fájlja az /etc/ssh/sshd_config fájl, amelyet csak a szuperfelhasználó olvashat vagy szerkeszthet. A fájl minden módosítása után újra kell indítania az ssh-kiszolgálót a módosítások alkalmazásához.
Példa az Ubuntu alapértelmezett SSH-kiszolgáló konfigurációjára:
# Példa nyílt ssh szerver konfigurációra orosz # # megjegyzésekkel..2010. # # # # # # Konvenciók: # # Az "alapértelmezett" alatt az sshd viselkedését értjük, amikor # # az irányelv nincs kifejezetten megadva. Érdemes megjegyezni, hogy az Ubuntuban # # az sshd_config fájl már számos olyan beállítást tartalmaz, amelyek # # az Ubuntu alapértelmezett beállításai. # # Ilyen beállítások vannak megadva ebben a fájlban. # # # ############################################## ############# ################ Cím/port beállítások stb. ########### ###################################### # ##################### # # ## Port ####################### ### ############################ # # # # Használt port. Többet is megadhat, pl.: # # Port 22 # # Port 23 # # Port 24 # # Nem szabványos port használata javasolt, mert # # A szabványt gyakran ellenőrzik a botok, és keresik a lehetséges lyukakat. Kihagyható, ha egy címen keresztül # # van megadva. Lásd még a ListenAddress paramétert. # # # 22-es port # # ## ListenAddress ####################################### ### # # # Hálózati cím, amelyen a szerver figyel. A cím # # így írható: # # ListenAddress host|IPv4_addr|IPv6_addr # # ListenAddress host|IPv4_addr:port # # ListenAddress :port # # Ha nincs megadva port, az sshd ezen a címen figyel, # # pedig a a Port opcióban megadott port. Ha # # a ListenAddress-t port megadása nélkül használja, akkor a # # Port opciónak meg kell előznie a ListenAddress opciót. Ha nincs # # megadva, akkor alapértelmezés szerint az összes helyi # # címen figyel. Több címet is megadhat. # # # ## CímCsalád ########################################### # # # Megadja, hogy az sshd melyik IP-címcsaládot # # használja. Lehetséges opciók: # # „any” - tetszőleges # # „inet” (csak IPv4) # # „inet6” (csak IPv6) # # Alapértelmezés - „bármilyen”. # CímCsalád inet # # ## UseDNS ######################################### # ######## # # # Megadja, hogy az sshd ellenőrizze-e a gazdagépnevet, és # # használja-e ezt a gazdagépnevet a kliens által küldött IP-cím ellenőrzésére a DNS-től kapott # # ellen. # # Az alapértelmezett érték „igen”. # # # ############################################## ############# ############# Felhasználói hozzáférési beállítások ############## ####### ################################################# ### # # # Egy felhasználó engedélyezését/tiltását a # # DenyUsers, AllowUsers, DenyGroups és AllowGroups direktívák határozzák meg. # # ebben az esetben az ellenőrzés fentről lefelé halad a lánc mentén: # # ## DenyUsers ## # # || # # ## AllowUsers ## # # || # # ## DenyGroups ## # # || # # ## AllowGroups ## # # Csak a felhasználó- és csoportnevek fogadhatók el, a numerikus # # azonosítók (UserID) nem ismerhetők fel. Több felhasználó/csoport helyes rögzítése egymás után, # # szóközzel elválasztva. Ha a user@host alakban írjuk, akkor # # a felhasználó és a gazdagép külön-külön be van jelölve, ez lehetővé teszi, hogy # # korlátozza a hozzáférést bizonyos felhasználókra # # bizonyos gépekről. Érdemes megjegyezni, hogy a # # DenyUsers és AllowUsers direktívák a felhasználó # # nevét veszik fel paraméterként, míg a DenyGroups és az AllowGroups a # # csoportnevet. A felhasználói és csoportnevek rögzítésére szolgáló űrlapokról # # lásd a MINTÁK részt a man ssh_config fájlban. # # # ## DenyUsers ########################################### ### # # # Azon FELHASZNÁLÓK listája, akik NEM használhatják az sshd-t. # # Alapértelmezett - nincs megadva = senki sincs kitiltva. Azok. ha itt # # van megadva egy felhasználó, akkor a rendszer megtagadja a hozzáférését az ssh szerverhez. # # # ## AllowUsers ########################################### ## # # # Az sshd-t használni tudó FELHASZNÁLÓK listája, # # Alapértelmezés szerint - nincs megadva = mindenki számára engedélyezett. Azok. ha # # legalább egy felhasználó meg van adva, az ssh hozzáférés a # # szerverhez csak az adott felhasználó számára érhető el. # # # ## DenyGroups ## # # # Azon CSOPORTOK listája, amelyeket NEM használhat az sshd. # # Alapértelmezett - nincs megadva = nincs tiltva csoport. # # Vagyis ha legalább egy csoport meg van adva, akkor az ebbe a csoportba tartozó # # felhasználók nem fognak hozzáférni az ssh # # szerverhez. # # # ## AllowGroups # # # # Az sshd által használható CSOPORTOK listája. # # Alapértelmezett - nincs megadva = mindenki számára engedélyezett. Azok. ha # # legalább egy csoport meg van adva, akkor csak a benne lévő felhasználók# # kapnak hozzáférést az ssh szerverhez.# # # ################### # ################################################ ### A kapcsolat állapotát meghatározó lehetőségek ############# ############################ ####### ######################### # # ## TCPKeepAlive ############## ######### ######################### # # # Azt jelzi, hogy a rendszernek kell-e TCP üzeneteket küldenie a kliensnek # # a kapcsolat fenntartása érdekében. Ha elküldi ezeket a csomagokat, # # meg tudja állapítani, hogy a kapcsolat megszakadt-e. Ez azonban # # azt is jelenti, hogy a kapcsolat megszakadhat # # pillanatnyi útválasztási kimaradás esetén, és # # ez egyesek számára nagyon bosszantó. Másrészt, ha # # nem küldenek ilyen üzeneteket, a kiszolgálón lévő munkamenetek # # korlátlan ideig tarthatnak, # # „szellem” felhasználókat hozva létre, és felemésztik a szerver erőforrásait. Az alapértelmezett érték „yes”,# # azaz. ilyen üzeneteket küldeni. # # ilyen üzenetek küldésének letiltásához állítsa az értéket „no”-ra. Korábban ezt a # # opciót KeepAlive-nak hívták. Érdemes megjegyezni, hogy # # vannak biztonságosabb módszerek is a # # kapcsolat állapotának ellenőrzésére (lásd alább). # # # TCPKeepAlive igen # # ## ClientAliveCountMax ##################################### # # # Beállítja az üzenetek számát az ügyfeleknek, amelyeket az sshd # # küld el egymás után anélkül, hogy választ # # kapna a klienstől. Ha eléri a küszöböt, és # # az ügyfél nem válaszol, az sshd leválasztja a klienst, és megszakítja az # # ssh munkamenetet. Érdemes megjegyezni, hogy az ilyen # # üzenetek használata teljesen eltér a TCPKeepAlive direktívától. # # A klienseknek szóló/az ügyfelektől érkező üzenetek titkosított # # csatornán keresztül érkeznek, ezért nem hajlamosak a hamisításra. A # # TCPKeepAlive üzenetek hajlamosak a hamisításra. Az ügyfél életben # # mechanizmus különösen értékes azokban az esetekben, amikor a kiszolgálónak és a kliensnek tudnia kell, hogy a kapcsolat mikor vált inaktívvá. Az alapértelmezett # # érték 3. Abban az esetben, ha a ClientAliveInterval # # értéke 15, és a ClientAliveCountMax értéke az alapértelmezett # # értéken marad, a nem válaszoló kliensek körülbelül # # 45 másodperc után lekapcsolódnak. Ez az utasítás csak # # az ssh2 protokollra működik. # # # ## ClientAliveInterval ######################################## # # # Készletek az időintervallum másodpercben. Ha ebben az időszakban # # nincs kommunikáció az ügyféllel, az sshd # # üzenetet küld egy titkosított csatornán, amely # # választ kér a klienstől. Az alapértelmezett 0, azaz. # # ne küldjön ilyen üzeneteket. Ez az utasítás # # csak az ssh2 protokollnál működik. # # # ############################################## ############# ################ Általános hitelesítési lehetőségek ################# ## ################################################# ######## # # ## AuthorizedKeysFile ##################################### # # # # Megad egy fájlt, amely # # a felhasználók hitelesítésére használt nyilvános kulcsokat tartalmazza. Az # # direktíva tartalmazhat %M formátumú tokeneket, amelyek a # # csatlakozási folyamat során kerülnek beszúrásra. # # A következő tokenek vannak definiálva: # # %% - a literális "%"-ra cserélve # # %h - lecserélve a hitelesített felhasználó # # főkönyvtárára # # %u - lecserélve a hitelesített felhasználó nevére # # Így a kulcsfájl megadható # #-ként abszolút módon (azaz egy megosztott fájl kulcsokkal), és # # dinamikusan - felhasználótól függően (azaz egy # # fájl minden felhasználó számára). # # Az alapértelmezett az „.ssh/authorized_keys”. # # Példa egy kulcsfájlra a felhasználó saját mappájában: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Példa egy megosztott fájlra: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # Lásd a Authorized_keys fájl leírását több információ. # # # ## ChallengeResponseAuthentication ########################### # # # # Megadja, hogy engedélyezi-e a kihívás-válasz hitelesítést # # ). A login.conf összes # # hitelesítési típusa támogatott. Az alapértelmezett "yes", # # azaz. lehetővé teszi. # # Ubuntu - biztonsági okokból letiltva. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ########################## # # # # Megadja, hogy a szerver hogyan szerezze be az ügyfél gazdagépnevét # # amikor a gazdagép ellenőrzésén alapuló hitelesítési séma. # # Ha "yes"-re van állítva, az sshd # # a kliens által megadott gazdagépnevet fogja használni, amikor egyezést keres a # # ~/.shosts, ~/.rhosts vagy /etc/hosts.equiv fájlokban. # # (fordított DNS-feloldás végrehajtása) Ha "no"-ra van állítva# # - az sshd magából a TCP-kapcsolatból fogja feloldani a nevet. # # Az alapértelmezés a "nem". # # # ## IgnoreRhosts ########################################### # # # Megakadályozza az .rhosts és .shost fájlok # # használatát a gazdagép alapú hitelesítésben. # # (RhostsRSAAuthentication vagy HostbasedAuthentication). # # Az /etc/hosts.equiv és /etc/ssh/shosts.equiv fájlok még # # használatban vannak. # # Az alapértelmezett „igen”. # # # IgnoreRhosts igen # # ## IgnoreUserKnownHosts ##################################### # # # Azt jelzi, hogy az sshd figyelmen kívül hagyja-e az # # "ismert hosts" ~/.ssh/known_hosts felhasználói fájlt a # # gazdagép alapú hitelesítési folyamat során (RhostsRSAAuthentication vagy HostbasedAuthentication). # # Az alapértelmezés a „nem”. ##### PermitBlacklisterKeys ########################################azt jelzi, hogy elfogadják -e az SSHD -t kulcsok feketelistán # # feltörtként (ismert-kompromittált # # kulcsok (lásd ssh-vulnkey)). Ha „igen”-re van állítva - # # hitelesítési kísérlet ilyen kulcsokkal naplózásra kerül # # és elfogadásra kerül, ha "nem" -re van állítva - # # hitelesítési kísérlet elutasításra kerül. # # Az alapértelmezés a „nem”. # # # ## Engedélyezze az ürítést jelszóval történő hitelesítés esetén a # # jelzi, hogy lehetséges-e a bejelentkezés üres jelszóval. # # Az alapértelmezés a „nem”. # # # PermitEmptyPasswords nem # # ## PermitRootLogin ####################################### # # # # Azt jelzi, hogy lehetséges-e az ssh bejelentkezés szuperfelhasználóként # # (root). A következő értékeket veheti fel: # # „yes” – a szuperfelhasználó bejelentkezhet. # # a jelenlegi globális hitelesítési séma kerül alkalmazásra. # # # # „jelszó nélkül” – a szuperfelhasználó bejelentkezhet. # # A jelszavas hitelesítés letiltásra kerül. # # # # „csak kényszerparancsok” – a szuperfelhasználó # # nyilvános kulcson alapuló hitelesítéssel és # # csak akkor tud bejelentkezni, ha átadja a végrehajtáshoz szükséges parancsot. # # Ez hasznos biztonsági mentések készítéséhez, # # még akkor is, ha a normál (azaz nem ssh-n keresztül) # # a szuperfelhasználói bejelentkezés le van tiltva. A szuperfelhasználó összes többi hitelesítési módszere # # blokkolva lesz.# # # # „nem” – a szuperfelhasználó nem használhatja az ssh-t a # # bejelentkezéshez. # # # # Az alapértelmezett érték „igen”. # # # PermitRootLogin igen # # ## Protokoll ###################################### ######## # # # Meghatározza, hogy az sshd melyik protokollt használja. # # Az '1' és '2' lehetséges értékei az ssh1 és ssh2 # #. Egyidejű írás is lehetséges, ebben az esetben # # az értékeket vesszővel kell elválasztani. # # Az alapértelmezés a „2.1”. # # Érdemes megjegyezni, hogy a # # bejegyzésekben a protokollok sorrendje nem határozza meg a prioritást, mert a kliens kiválasztja, hogy a szerver által javasolt protokollok közül # # melyiket használja. A "2,1" bejegyzés # # teljesen azonos az "1,2" bejegyzéssel. # # # 2. protokoll # # ## ####################################### ########## # # # Engedélyezi a PAM interfészt (Pluggable Authentication Module # # interfész). Ha "igen"-re van állítva, akkor minden hitelesítési típus # # a munkamenet és a fiókmodul feldolgozáson kívül # # PAM hitelesítés lesz # # kihívás-válasz (ChallengeResponseAuthentication és # # PasswordAuthentication) alapján használják, mert # # A kihívás-válasz hitelesítés a PAM-ban általában ugyanazt a szerepet tölti be, mint # # a jelszó-hitelesítést, ezért le kell tiltania a # # PasswordAuthentication vagy # # ChallengeResponseAuthentication-t. Érdemes megjegyezni, hogy # # ha a UsePAM direktíva engedélyezve van, akkor az # # sshd-t csak root felhasználóként futtathatja. # # Az alapértelmezett érték „nem”. # # # Használja PAM igen engedélyezve van-e a hitelesítés # # jelszóval. # # Az alapértelmezett „igen”. # # # ## HostKey ########################################### ##### # # # Megadja az SSH által használt # # privát hosztkulcsot tartalmazó fájlt. Az alapértelmezett érték az /etc/ssh/ssh_host_key # # az ssh1 protokollhoz, az /etc/ssh/ssh_host_rsa_key és # # /etc/ssh/ssh_host_dsa_key az ssh2 protokollhoz. # # Érdemes megjegyezni, hogy az sshd nem használ olyan fájlokat, amelyek # # a felhasználón kívül bárki számára elérhetők. A kulcsokkal # # több fájlt is használhat, a kulcsok a következők: „rsa1” - # # az ssh1 protokollhoz és „dsa”/“rsa” az ssh2 protokollhoz. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # # ############################## ### ############################ ########## Az SSH protokoll 1-es verziójának (ssh1) beállításai ### ########## #################################### ### ################### # ERŐSEN NEM AJÁNLOTT az ssh1 protokoll használata.# # Az ssh2 protokoll sokkal biztonságosabb, mint az ssh1 # ### ######## ######################################### ####### # # ## KeyRegenerationInterval ################################## # # # A ssh1 protokoll - egyszer egy bizonyos időpontban # # automatikusan létrejön egy új ideiglenes szerver # # kulcs (ha használt). Ez azért történik, hogy # # megakadályozza az elfogott munkamenetek visszafejtését, hogy # # később bejelentkezhessen a gépre ezen munkamenetek paramétereivel és # # ellopja a kulcsokat. Az ilyen kulcsot sehol nem tárolják (# # RAM-ban van tárolva). Ez a direktíva # # határozza meg a kulcs élettartamát másodpercben, amely után # # újra előállításra kerül. Ha az érték 0 - # # értékre van állítva, a kulcs nem generálódik újra. # # Az alapértelmezett érték 3600 (másodperc). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ################################### # # # Azt jelzi, hogy a hitelesítés # # rhosts vagy /etc/hosts.equiv fájlok alapján, az RSA-n keresztüli sikeres # # gazdagép hitelesítéssel együtt. # # Csak az ssh1 protokollra vonatkozik. # # Az alapértelmezés a „nem”. # # # RhostsRSAA-hitelesítés nincs # # ## RSAA-hitelesítés ####################################### ## # # # Azt jelzi, hogy engedélyezett-e a "tiszta" RSA hitelesítés. # # Csak az ssh1 protokollra vonatkozik. # # Az alapértelmezett „igen”. # # # RSAA-hitelesítés igen # # ## ServerKeyBits ####################################### ### # # # Meghatározza a bitek számát a kiszolgáló ideiglenes kulcsában # # az ssh1 protokollhoz. A minimális érték 512. # # Az alapértelmezett érték 1024. # ServerKeyBits 768 # # ################################# # ########################### ########### SSH protokoll 2. verziója (ssh2) opciók ## ## ######## ######################################## ### ################### # # ## Rejtjelek ######################## ## ###################### # # # Az ssh2 protokollhoz # # engedélyezett titkosítási algoritmusokat jelzi. Több algoritmust # # kell vesszővel elválasztani. Támogatott algoritmusok: # # „3des-cbc”, „aes128-cbc”, „aes192-cbc”, „aes256-cbc”, # # „aes128-ctr”, „aes192-ctr”, „aes256-ctr”, „ arcfour128”, # # „arcfour256”, „arcfour”, „blowfish-cbc”, „cast128-cbc”. # # Alapértelmezés szerint: # # aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, # # arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, #2-cbc,aes128-ctr, #2-ctr,192 #5 -ctr # # # ## HostbasedAuthentication ################################### # # # Azt jelzi, hogy a hitelesítés megtörtént-e engedélyezve, # # gazdagép ellenőrzése alapján. rhosts vagy /etc/hosts.equiv be van jelölve, # # és ha sikeres, a nyilvános kulcs # # sikeres ellenőrzésével kombinálva a hozzáférés engedélyezett. Ez a # # direktíva megegyezik a RhostsRSAAuthentication direktívával, és a # # csak az ssh2 protokollhoz alkalmas. # # Az alapértelmezés a "nem". # # # Hostbased Authentication nincs # # ## MAC-ok ####################################### ############ # # # Érvényes MAC-algoritmust jelez (üzenet # # hitelesítési kód). A MAC algoritmust # # használja az ssh2 protokoll az adatok integritásának védelmére. Több # # algoritmust vesszővel kell elválasztani. # # Alapértelmezés: # # hmac-md5,hmac-sha1, [e-mail védett] ,hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication ########################### ########## # # # Azt jelzi, hogy engedélyezett-e a # # nyilvános kulcson alapuló hitelesítés. Csak az ssh2 protokollra vonatkozik. # # Az alapértelmezett „igen”. # # # PubkeyAuthentication igen ############################################ # ############### #################### GSSAPI-beállítások ############ ## ############# ################################### ## ######################## # # ############# Csak az ssh2 protokollra vonatkozik #### #### ### # # ## GSSAPIAuthentication ##################################### ## # # # Azt jelzi, hogy a felhasználói hitelesítés # # GSSAPI-n alapul-e. Az alapértelmezett a "nem", azaz. tiltott. # # # ## GSSAPIKeyExchange ######################################## # # # Azt jelzi, hogy a # # GSSAPI-n alapuló kulcscsere engedélyezett-e. A GSSAPI-t használó kulcscsere nem # # támaszkodik az ssh-kulcsokra a gazdagép azonosságának ellenőrzéséhez. # # Az alapértelmezett a "nem" - azaz. csere tilos. # # # ## GSSAPICleanupCredentials ################################ # # # Megadja, hogy automatikusan törlődjön-e # # felhasználói gyorsítótár hitelesítési hitelesítő adatok, amikor # # munkamenet véget ér. # # Az alapértelmezett "igen" - azaz. meg kell semmisíteni. # # # ## GSSAPIStrictAcceptorCheck ################################ # # # Meghatározza, hogy milyen szigorú legyen a személyazonosság-ellenőrzés # # ügyfél a GSSAPI-n keresztül történő hitelesítéskor. # # A "yes" érték hatására az ügyfél hitelesít # # a fogadó gazdagép szolgáltatást az aktuális gazdagépen. A "no" # # érték lehetővé teszi az ügyfél számára, hogy bármely # # szolgáltatáskulccsal hitelesítsen. # # Az alapértelmezett "igen". # # Érdemes megjegyezni, hogy a "nem" értékre # # csak ritka Kerberos GSSAPI könyvtárakkal működik. # # # ############################################## ############# ################### Kerberos-beállítások ################# ########## ####################################### ### ################## # # ## KerberosAuthentication ######################## ### ######## # # # Azt jelzi, hogy a felhasználó által # # hitelesítéshez megadott jelszó # # (PasswordAuthentication) igényel-e érvényesítést a Kerberos KDC-ben. # # Ennek az opciónak a használatához a kiszolgálónak # # ellenőriznie kell, hogy a KDC igaz-e. (A szervernek szüksége van egy # # Kerberos kiszolgálólapra, amely lehetővé teszi a # # KDC identitásának ellenőrzését.) # # Az alapértelmezés a „nem”. # # # ## KerberosGetAFSToken ######################################## # # # Ha az AFS aktív, és a felhasználó Kerberos 5 TGT-t kapott, # # megkísérel-e egy AFS-jogkivonatot szerezni, mielőtt a felhasználó hozzáférhet a saját mappájához. # # Az alapértelmezés a „nem”. # # # ## KerberosOrLocalPasswd #################################### # # # Azt jelzi, hogy mit kell tenni ebben az esetben ha a Kerberoson keresztüli # # hitelesítés sikertelen. Ha # # value = "yes", a jelszó ellenőrzése # # bármely további helyi engedélyezési mechanizmus segítségével történik, # # például /etc/passwd. # # Az alapértelmezett „igen”. # # # ## KerberosTicketCleanup ################################### # # # # # # # # # # # # # Azt jelzi, hogy automatikusan meg kell-e állítani a fájlt # # felhasználói jegy gyorsítótárral a munkamenet végén. # # Az alapértelmezett „igen”. # # # ############################################## ############# ################# Átirányítási lehetőségek ################### # ## ############################################## ## ############# # # ## AllowAgentForwarding ############################## #### ### # # # Azt jelzi, hogy engedélyezni vagy letiltani kell-e az átirányítást # # ssh-agent. Az alapértelmezett "yes", azaz engedélyezve van. # # Érdemes megjegyezni, hogy az átirányítás letiltása nem # # növeli a biztonságot mindaddig, amíg a felhasználók # # shell hozzáférés is meg lesz tagadva, mivel mindig telepíthetik # # saját ügynökanalógjaikat. # # # ## AllowTcpForwarding ###################### # ############### # # # Azt jelzi, hogy engedélyezni vagy letiltani kell-e a TCP-átirányítást. # # Az alapértelmezett "igen", azaz engedélyezve. Érdemes megjegyezni, hogy # # mindkét AllowAgentForwarding esetén az # # átirányítás letiltása nem növeli a biztonságot mindaddig, amíg # # a felhasználók konzolhoz hozzáférnek, mert # # telepíthetik a megfelelőit. # # # # # ## GatewayPorts ######### ## ################################ # # # Megadja, hogy a távoli gazdagépek hozzáférjenek-e a # # továbbított portokhoz. Alapértelmezés szerint az sshd # # csak a helyi loopback interfészen figyeli a továbbított portokhoz való kapcsolatokat. Ez megakadályozza, hogy más távoli # # gazdagépek csatlakozzanak a továbbított portokhoz. A GatewayPorts segítségével # # engedélyezheti az sshd számára, hogy ezt megtegye. A direktíva 3 értéket vehet fel: # # "no" - csak visszahurkolás. # # "igen" - bármilyen cím. # # "clientspecified" - az ügyfél által megadott címek. # # # ## EngedélyMegnyitás ########################################### ## # # # Azt jelzi, hol engedélyezett a TCP port továbbítás. # # Az átirányítás megadásának a következő formákban kell # # lennie: # # PermitOpen host:port # # PermitOpen IPv4_addr:port # # PermitOpen :port # # Szóközökkel elválasztva több bejegyzés is megadható. # # Az „any” argumentum felhasználható a # # porttovábbítás összes korlátozásának eltávolítására. Alapértelmezés szerint minden # # átirányítás engedélyezett. # # # ## PermitTunnel ########################################### # # # Azt jelzi, hogy a tun eszközök átirányítása engedélyezett-e. # # A következő értékeket veheti fel: # # „yes” # # „point-to-point” (3. hálózati réteg) # # „ethernet” (2. hálózati réteg) # # „no” # # Az „igen” érték lehetővé teszi mindkét „pont” -to-point” # # és az „ethernet” egyszerre. Az alapértelmezett a „nem”. # # # ############################################## ############# ################## Naplózási lehetőségek ################## ### ############################################## ## ############# # # ## SyslogFacility ############################## ## ########## # # # Beállítja a naplóobjektum kódját az üzenetek # # syslog-ba írásához az sshd-ről. Lehetséges értékek: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # Az alapértelmezett AUTH. # # # SyslogFacility AUTH # # ## LogLevel ####################################### ######## # # # Beállítja az sshd napló részletességi szintjét. # # Lehetséges lehetőségek: # # CSENDES # # CSENDES # # VÉGZETES # # HIBA # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # Az alapértelmezés az INFO. # # DEBUG és DEBUG1 egyenértékűek egymással. # # DEBUG2 és DEBUG3 állítja be a legmagasabb szintű hibakeresési kimenetet. A DEBUG szintű naplózás # # veszélyezteti a felhasználók adatait, és nem ajánlott. # # # LogLevel INFO # # ########################################## ################ ################### X11 átirányítás ############# ######## ######################################### # ################### # # ## X11 Továbbítás ########################## ### ################ # # # Azt jelzi, hogy az X11 grafikus alrendszer # # átirányítása engedélyezett-e. Felveheti az „igen” vagy a „nem” értéket. # # Az alapértelmezés a „nem”. # # Figyelem – az egyszerű X11 átirányítás engedélyezése # # nagy kockázatot jelent mind a szerver, mind a kliensek számára, mert Egy ilyen átirányításnál az sshd proxy display # # bármilyen címről fogad kapcsolatokat. Használja # # az X11UseLocalhost direktívát, hogy korlátozza a # # X átirányítási kiszolgálójához való hozzáférést. Érdemes megjegyezni, hogy # # az átirányítás letiltása nem garantálja, hogy # # a felhasználók nem tudják átirányítani az X11-et, mert # # konzol hozzáféréssel mindig telepítik a saját # # átirányítójukat. Az X11 átirányítás # # automatikusan le lesz tiltva, ha a UseLogin # # direktíva engedélyezve van. # # # X11 Továbbítás igen # # ## X11UseLocalhost ######################################## # # # # Azt jelzi, hogy az sshd korlátozza-e az # # X11 helyi hurokcímre történő továbbítását, vagy # # engedélyeznie kell-e bármilyen címet. Alapértelmezés szerint az sshd # # beállítja az X11 átirányítási kiszolgálót a # # helyi címre, és a # # DISPLAY környezeti változó gazdagépnév részét "localhost" értékre állítja. Érdemes megjegyezni, hogy # # néhány régebbi X11 kliens nem működik ezekkel a beállításokkal. Az alapértelmezett az "igen", azaz. a # # átirányítást a localhost korlátozza, a "no" érték letiltja a # # korlátozásokat. # # # ## XAuthLocation ########################################### # # # Megadja az xauth program teljes elérési útját. # # Az alapértelmezett érték /usr/bin/X11/xauth. # # # ## X11DisplayOffset ######################################## # # # Az sshd számára # # X11 átirányításként elérhető első képernyő számát jelzi. Ez azért történik, # # hogy az átirányított X-ek ne fedjenek át # # valódi X-eket. Az alapértelmezett 10. # # # X11DisplayOffset 10 # # ###################################### ## ##################### #################### Különféle lehetőségek ##### ## ############################################### ##### ############################ # # ## BejelentkezésGraceTime ############# ####### ######################## # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Ha a szerver leválasztja a felhasználót, ha nem tudta jelentkezzen be # # kielégítően. 0 érték – lehetővé teszi a # # felhasználó számára, hogy korlátlan ideig bejelentkezzen. Az alapértelmezett érték 120 (másodperc). # # # LoginGraceTime 120 # # ## MaxAuthTries ####################################### ### #### # # # A csatlakozásonként engedélyezett # # hitelesítési kísérletek maximális számát jelzi. # # Ha a sikertelen kísérletek száma meghaladja a # # megadott érték felét, minden további kísérlet # # naplózásra kerül. Az alapértelmezett érték 6. # # # ## MaxSessions ###################################### ####### # # # Megadja az egyidejű kapcsolatok maximális számát # # minden hálózati kapcsolathoz. Az alapértelmezett 10. # # # ## MaxStartups ####################################### ###### # # # Megadja az sshd egyidejű # # illetéktelen csatlakozásainak maximális számát. Ha # # a kapcsolatok száma meghaladja a korlátot, minden további # # kapcsolat megszakad mindaddig, amíg a jelenlegi # # kapcsolatok be nem fejeződnek vagy sikeres # # engedélyezéssel, vagy a # # LoginGraceTime direktívában meghatározott időtartam le nem jár. Az alapértelmezett érték 10. # # Opcionálisan beállíthatja a kapcsolatok korai alaphelyzetbe állítását úgy, hogy # # adjon meg három értéket paraméterként, # # kettősponttal elválasztva: "start:rate:full" (például: "10:30" :60"). # # Az sshd # # „rate/100” valószínűséggel utasítja el a csatlakozási kísérletet (pl. példánkban - 30%), ha már van # # „start” (10) illetéktelen kapcsolat. # # A valószínűség lineárisan növekszik, és minden # # csatlakozási kísérlet elutasításra kerül, ha a jogosulatlan # # kapcsolatok száma eléri a „megtelt” (60). # # # ## Tömörítés ########################################### # # # # Azt jelzi, hogy az adattömörítés engedélyezve van-e. Lehet # # "igen" - a tömörítés engedélyezve van. # # "késleltetett" - a tömörítés késleltetett # # a felhasználó sikeres hitelesítéséig. # # "nem" - a tömörítés le van tiltva. # # Az alapértelmezett a "késleltetett". # # # ## Bejelentkezés használata ########################################### #### # # # Azt jelzi, hogy kell-e bejelentkezést használni egy # # interaktív munkamenethez. Az alapértelmezett érték a „nem”. # # Érdemes megjegyezni, hogy a bejelentkezést soha nem # # használták távoli parancsok végrehajtására. Vegye figyelembe azt is, hogy # # a login használata lehetetlenné teszi az X11Forwarding direktíva # # használatát, mert a bejelentkezés nem tudja, hogy # # mit kezdjen az xauth-tal. Ha a # # UsePrivilegeSeparation direktíva engedélyezve van, akkor az # # engedélyezés után letiltásra kerül. # # # ## UsePrivilegeSeparation ###################################### # # # Megadja, hogy az sshd el kell különíteni a jogosultságokat. Ha igen, akkor először a bejövő hálózati forgalom számára egy privilegizált gyermekfolyamat jön létre. A sikeres # # engedélyezés után egy másik folyamat jön létre a bejelentkezett felhasználó jogosultságaival # #. A privilégiumok szétválasztásának fő célja # # a hozzáférési jogokkal való visszaélés megakadályozása. # # Az alapértelmezett érték „igen”. # # # UsePrivilegeSeparation igen # # ## StrictModes ####################################### ### ##### # # # Azt jelzi, hogy az sshd-nek ellenőriznie kell-e a felhasználói mappák és fájlok # # hozzáférési és tulajdonosi módját, mielőtt # # lehetővé tenné a felhasználó bejelentkezését. Ez általában azért van, mert # # újoncok gyakran mindenki által írhatóvá teszik a fájljaikat. Az alapértelmezett az „igen”. # # # StrictModes igen # # ## AcceptEnv ###################################### ####### # # # Meghatározza, hogy a kliens által # # átadott környezeti változók legyenek elfogadva. Lásd a SendEnv opciót a kliensben. # # Érdemes megjegyezni, hogy a változók átadása csak az ssh2 protokollnál lehetséges. A változók név szerint vannak megadva, # # maszk használható ('*' és '?'). Megadhat # # több változót szóközzel elválasztva, vagy feloszthatja az AcceptEnv-t # # több sorra. Legyen óvatos – néhány környezeti változó # # felhasználható a tiltott felhasználói környezetek megkerülésére. Óvatosan használja ezt a # # direktívát. Alapértelmezés szerint # # felhasználói környezeti változók nem fogadhatók el. # # # AcceptEnv LANG LC_* # # ## PermitUserEnvironment ################################### # # # Megadja, hogy az sshd elfogadja-e a # # ~/.ssh/environment és az Environment= paramétert a # # ~/.ssh/authorized_keys mezőben. Az alapértelmezett a „nem”. # # Érdemes megjegyezni, hogy a környezeti feldolgozás engedélyezése # # lehetőséget adhat a felhasználóknak a korlátozások megkerülésére néhány olyan konfigurációban, amelyek olyan mechanizmusokat használnak, mint # # LD_PRELOAD. # # # # # ## PidFile ########################################## # ####### # # # Megad egy fájlt, amely az SSH démon # # folyamatazonosítóját (folyamatazonosító, PID) tartalmazza. # # Alapértelmezett - /var/run/sshd.pid # # # # # ## PrintLastLog ############################# # ############## # # # Megadja, hogy az sshd megjelenítse-e az utolsó munkamenet dátumát és idejét, amikor a felhasználó interaktívan bejelentkezik. # # Az alapértelmezett „igen”. # # # PrintLastLog igen # # ## PrintMotd ###################################### ####### # # # Meghatározza, hogy az sshd megjelenítse-e az /etc/motd # # fájlt, amikor a felhasználó interaktívan bejelentkezik. Néhány # # rendszeren (például Ubuntu) ezt az információt # # a shell is megjeleníti. # # Az alapértelmezett érték „igen”. # # # PrintMotd no # # ## Banner ####################################### ########## # # # Azt jelzi, hogy melyik fájl tartalmaz olyan szöveges szalagcímet, amely # # jelenik meg a felhasználó számára a # # hitelesítési eljárás ELŐTT. Az opció csak az ssh2 protokollhoz érhető el.# # Alapértelmezés szerint - nem mutat semmit. # # Ubuntu esetén az issue.net fájl tartalmazza az Ubuntu (verzió) kifejezést, # # például a karmikus kifejezés az "Ubuntu 9.10". Használható # # a lehetséges támadók félrevezetésére, # # ha odaírja például: "My D-Link Interet Router" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ###### ##### ############################## # # # Ha meg van adva, megadja a # # chrootolás elérési útját hitelesítés után. Az elérési útnak és annak minden tartalmának # # meg kell felelnie a szuperfelhasználó tulajdonában lévő mappáknak, és nem # # írható más felhasználók számára. # # Az elérési út tartalmazhat címkéket, amelyeket a hitelesítési folyamat során # # helyettesítenek: # # %% - a "%" betűszóval helyettesítve # # %h - lecserélve a hitelesített felhasználó # # kezdőkönyvtárára # # %u - lecserélve a hitelesített felhasználó nevére # # chroot -a mappának tartalmaznia kell az összes szükséges fájlt és # # mappát a felhasználói munkamenethez. Az interaktív # # munkamenethez legalább: # # egy shell, általában sh # # alapvető eszközök a /dev-ben, például: # # null, zero, stdin, stdout, stderr, arandom és tty # # egy adatátviteli munkamenethez sftp no # # további beállításokra van szükség, ha a belső # # sftp szerver folyamatot használja. # # további információért lásd: Alrendszer. Alapértelmezés szerint a chroot nem hajtódik végre. # # # ## ForceCommand ########################################### # # # A megadott parancs végrehajtását idézi elő. # # figyelmen kívül hagyja az ügyfél által küldött vagy # # ~/.ssh/rc-re írt parancsokat. A parancs a felhasználó # # parancsértelmezőjéből a -c kapcsolóval hívható meg. Alkalmas shell, # # parancs vagy alrendszer indítására. A leghasznosabb a # # Match blokkon belül. Az ügyfél által eredetileg kiadott parancs # # az SSH_ORIGINAL_COMMAND környezeti változóban van tárolva. Ha # # megadja az "internal-sftp" parancsot, akkor elindul a # # belső sftp szerver, amelyhez nincs szüksége a ChrootDirectory direktívában leírt # # további fájlokra és mappákra. # # # ## Alrendszer ########################################### ### # # # Meghatároz és konfigurál egy külső alrendszert (például # # fájlátviteli démont). # # Az argumentumok a név és a parancs (lehetséges # # argumentumokkal), amelyek az alrendszerek kérésekor # # végrehajtódnak. Az sftp-server parancs elindítja az „sftp” - # # fájlátviteli alrendszert. Ezenkívül megadhatja # # „internal-sftp”-t alrendszerként – amely elindítja # # a belső sftp-kiszolgálót. Ez nagymértékben leegyszerűsítheti a # # konfigurálást a # # ChrootDirectory direktíva használatakor. Alapértelmezés szerint nem hívják meg az alrendszereket. Csak az ssh2 protokollra vonatkozik. # # # sftp alrendszer /usr/lib/openssh/sftp-server # # ################################# ############################ ##################### Mérkőzés Blokk ############################ ##################### ## #################################### # # # speciálisan a végére helyeztem át a fájlt a kényelmesebbé tétel érdekében # # írjon Match szabályokat. # # MadKox. # # # # A Match direktíva egy feltételes # # blokk kezdetét jelenti. Ha a # # Match sorban megadott összes feltétel teljesül, a blokk következő soraiban lévő direktívák végrehajtásra kerülnek, # # lehetővé téve az # # sshd_config fájlban lévő globális direktívák értékeinek megkerülését abban az esetben, ha a a # # Match direktíva kritériumai. Blokknak tekintjük az összes olyan sort, amely a # # sor után jön a (Match - lines) feltétellel a következő # # illesztési sorra vagy a fájl végére. A Match direktíva argumentuma egy vagy # # több pár feltétel bejegyzés. Lehetséges bejegyzéstípusok: # # User # # Group # # Host # # Address # # A bejegyzések tartalmazhatnak egyetlen # # értéket (például User=user), vagy több értéket is # # vesszővel elválasztva (Felhasználó=felhasználó1 ,felhasználó2). Az ssh_config fájl # # PATTERNS szakaszában leírt reguláris kifejezések is használhatók # #. A # # címfeltételek bejegyzései tartalmazhatnak címeket a CIDR # # (Cím/Maszk hossza, pl. „192.0.2.0/24” vagy # # „3ffe:ffff::/32”) jelöléssel. Érdemes megjegyezni, hogy a megadott # # maszk hosszának meg kell egyeznie a címmel, és a címhez tartozó # # hosszú/rövid nem fog működni. # # A Match csak # # egy meghatározott direktívakészletet használhat direktívaként: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KbdInteractiveAuthentication # # Maxthu # KerberosAuthen # # KerberosAut # PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #
A fenti szöveget bemásolhatja saját sshd_config fájljába, és később felhasználhatja a konfigurációhoz.
A rosszul konfigurált SSH-szerver önmagában is óriási biztonsági rést jelent a rendszer biztonságában, hiszen egy esetleges támadónak szinte korlátlan hozzáférése van a rendszerhez. Ezenkívül az sshd számos további hasznos opcióval rendelkezik, amelyeket tanácsos engedélyezni a használhatóság és a biztonság javítása érdekében.
Port, ListenAddress és AddressFamily
Ez a három paraméter határozza meg, hogy a szerver mely portokon és címeken figyeli a bejövő kapcsolatokat. Először is, ha lehetséges, érdemes a feldolgozott címcsaládot a ténylegesen használt címekre korlátozni, azaz ha csak IPv4-et használ, tiltsa le az IPv6-ot, és fordítva. Ezt megteheti például az AddressFamily paraméterrel (az IPv4 engedélyezéséhez és az IPv6 letiltásához):
CímCsaládi inet
Másodszor, tanácsos megváltoztatni a szabványos portot (22), amelyen az sshd figyel. Ez annak a ténynek köszönhető, hogy számos hálózati szkenner folyamatosan próbál csatlakozni a 22-es porthoz, és legalább nyers hozzáférést szerezni az adatbázisából származó bejelentkezési/jelszavak durva kényszerítésével. Még akkor is, ha a jelszavas hitelesítés le van tiltva, ezek a próbálkozások erősen eltömítik a naplókat, és (nagy mennyiségben) negatívan befolyásolhatják az ssh-kiszolgáló sebességét. Ha valamilyen oknál fogva nem akarja megváltoztatni a szabványos portot, különféle külső segédprogramokat, például fail2ban-t és beépített segédprogramokat, például MaxStartups-t használhat.
A portot beállíthatja abszolút értékként az összes interfészhez a Port direktíva használatával, vagy egyedi értékként minden egyes interfészhez a ListenAddress direktíva használatával. Például:
Port 2002
ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004
Távoli hozzáférés megtagadása a szuperfelhasználó számára
Alapértelmezés szerint a root hozzáférés jelszóval tiltott (kulccsal lehetséges) - a PermitRootLogin beállítás jelszó nélkül van beállítva. De tekintettel arra, hogy az Ubuntuban alapértelmezés szerint a rendszertelepítés során hozzáadott felhasználó képes minden adminisztrációs feladatot megoldani sudo-n keresztül, ésszerűtlennek tűnik a rendszerhez való root hozzáférés lehetőségének megteremtése ssh-n keresztül (még kulcshitelesítéssel is). Javasoljuk, hogy teljesen kapcsolja ki. ezt az opciót, vagy csak kényszerített parancsok módban használja. A root hozzáférést a következőképpen tilthatja le:
PermitRootLogin sz
Jelszavas hitelesítés
Az alapértelmezés szerint engedélyezett jelszavas hitelesítés gyakorlatilag a legprimitívebb hitelesítési módszer az sshd-ben. Ez egyrészt leegyszerűsíti az új felhasználók konfigurálását és csatlakozását (a felhasználónak csak a rendszerbelépőjét/jelszavát kell tudnia), másrészt a jelszó mindig kitalálható, és a felhasználók gyakran elhanyagolják az összetett és hosszú jelszavak létrehozását. . A speciális botok folyamatosan átvizsgálják az internetről elérhető ssh-szervereket, és az adatbázisukból nyert bejelentkezési/jelszavak segítségével próbálnak bejelentkezni. Erősen ajánlott, hogy ne használjon jelszavas hitelesítést. Így tilthatod le:
JelszóHitelesítés sz
Ha valamilyen oknál fogva mégis szeretné használni a jelszavas hitelesítést, ügyeljen arra, hogy senki ne tudjon bejelentkezni üres jelszóval. Ehhez állítsa be a PermitEmptyPasswords direktívát:
PermitEmptyPasswords sz
SSH1 és SSH2 protokollok
Mint már említettük, az sshd együttműködhet az SSH1 és SSH2 protokollokkal. A nem biztonságos SSH1 használata azonban erősen nem ajánlott. Kényszerítheti az sshd-t, hogy csak az SSH2 protokollal működjön, így:
SSH2 RSA kulcsokon alapuló hitelesítés
A legelőnyösebb engedélyezési módszer az SSH2 RSA kulcsokon alapuló hitelesítés. Ezzel a módszerrel a felhasználó egy kulcspárt generál az oldalán, amelyek közül az egyik kulcs titkos, a másik pedig nyilvános. A nyilvános kulcsot a rendszer a szerverre másolja, és a felhasználó személyazonosságának ellenőrzésére szolgál. A kulcspár létrehozásával és a kiszolgálón való elhelyezésével kapcsolatos további információkért tekintse meg az SSH-kliens leírását. A nyilvános kulcsú hitelesítést a következőképpen engedélyezheti:
PubkeyAuthentication igen
A szervernek tudnia kell, hol keresse a felhasználó nyilvános kulcsát. Ehhez egy speciális authorised_keys fájlt használnak. A szintaxisa a következő lehet:
# A megjegyzések csak egy új sorba íródnak # a bejegyzések általános megjelenése az authorised_keys fájlban # [opciók] kulcs_típus (ssh-rsa vagy ssh-dss) nagyon_hosszú_karakterlánc_érthetetlen a közember számára [login@host] ssh-rsa AAAAB3Nza...LiPk == [e-mail védett] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [e-mail védett] 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...== [e-mail védett]
Megadhat egy megosztott fájlt kulcsokkal, vagy egy fájlt minden felhasználó számára. Ez utóbbi módszer kényelmesebb és biztonságosabb, mert egyrészt minden felhasználóhoz különböző billentyűkombinációkat adhat meg, másrészt korlátozhatja a hozzáférést a felhasználó nyilvános kulcsához. Megadhat egy fájlt kulcsokkal az AuthorizedKeysFile direktíva használatával:
AuthorizedKeysFile %h/.ssh/my_keys
a séma felhasználói fájlhoz
vagy
AuthorizedKeysFile /etc/ssh/authorized_keys
megosztott fájllal rendelkező sémához. Alapértelmezés szerint az SSH-kliens a ~/.ssh/authorized_keys fájlban keresi a kulcsokat.
Bővebben a biztonságról
További beállítások
Felhasználók és csoportok.
Ha sok felhasználó „él” a szerveren, és csak néhányuknak szeretne hozzáférést ssh-n keresztül engedélyezni, használhatja a DenyUsers, AllowUsers, DenyGroups és AllowGroups direktívákat. Az irányelvekkel kapcsolatos további információkért tekintse meg az sshd_config példa megjegyzéseit.
Csatlakozási állapot beállításai
Alapértelmezés szerint a kapcsolat állapotának meghatározására szolgáló módszerek közül csak a TCP-kapcsolat-ellenőrzési módszer van engedélyezve - a TCPKeepAlive azonban az sshd kényelmesebb és biztonságosabb módon tudja meghatározni a csatlakozási állapotokat. További részletekért lásd az sshd_config példa megfelelő szakaszát.
Teljesítmény. MaxStartups
Port Forwarding
X11 átirányítás
A szerveren az /etc/ssh/sshd_config fájlban állítsa be a paramétert (alapértelmezés szerint engedélyezve van):
ElőreX11 igen
A kliensen állítsa be a paramétereket az /etc/ssh/ssh_config fájlban (alapértelmezés szerint le van tiltva):
ForwardAgent igen ForwardX11 igen
A kliensen a következőképpen futtathatja: ssh yurauname@serverip firefox . Vagy először lépjen az ssh yurauname@serverip címre, majd futtassa például a sudo synaptic parancsot.
SFTP
Az sshd alapértelmezés szerint beépített SFTP-kiszolgálóval rendelkezik. SFTP (SSH File Transfer Protocol) – SSH protokoll fájlok átviteléhez. Úgy tervezték, hogy megbízható és biztonságos kapcsolaton keresztül másoljon és végezzen más fájlműveleteket. Általában az SSH2 protokollt használják a kapcsolatot biztosító alapprotokollként. Az SFTP támogatás engedélyezéséhez adja hozzá a sort az sshd_config fájlhoz
sftp /usr/lib/openssh/sftp-server alrendszer
Alapértelmezés szerint az SFTP-támogatás engedélyezve van.
Kritériumok használata. Match direktíva
SSH kliens beállítása
A kulccsal történő bejelentkezés tekinthető a legbiztonságosabbnak, és a legtöbb esetben ez a szolgáltatás a szerver oldalon engedélyezett, így a használatához nincs szükség szuperfelhasználói jogokra. Az ügyfélgépen létrehozunk egy kulcsot:
ssh-keygen -t rsaA rendszer kéri, hogy adjunk meg egy jelszót a kulcsfájl védelme érdekében (hasznosnak bizonyul, ha a fájl rossz kezekbe kerül). Ha SSH-n keresztül fogunk parancsfájlokat végrehajtani, akkor hagyjuk üresen. A paranccsal átvisszük a nyilvános kulcsot a szerverre
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub user@ szerver
Ennyi, bejöhetsz.
Ha az ssh nem szabványos porton fut:
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub "-p port user@server"
Ha hiba történik: Hibás port "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"
próbáld idézőjelbe tenni a paramétereket:
Ssh-copy-id "-i /home/user/.ssh/id_rsa.pub "-p port user@server""
Kényelmes a képernyő segédprogram használata távoli rendszerhez való csatlakozáskor.
Távoli ssh-könyvtár beállítása a Nautilusban
Távoli könyvtár csatlakoztatása sshfs használatával
Távoli könyvtár csatlakoztatása helyi könyvtárhoz
sshfs user@ hostingserver.ru:/ home/ userdir ~/ sshfsdirLeszerelés
Fusermount -u ~/ sshsfdir
SSH álnevek
Ha több szervert használ különböző hozzáférési paraméterekkel (nem szabványos port, hosszú gazdagépnév, a helyitől eltérő bejelentkezés stb.), néha fárasztó minden kapcsolati beállítást újra megadni. Ennek megkönnyítésére használhat álneveket.
A beállítások a ~/.ssh/config fájlban tárolódnak egyetlen felhasználó számára, és az /etc/ssh/ssh_config mappában globálisan minden felhasználó számára.
Példa konfig. Több szerver is leírható. További részletek a man ssh_config(nem tévesztendő össze sshd_config)
Host AliasName # Tetszőleges gazdagépnév HostName 1.2.3.4 # Megadhatja mind az IP-címet, mind a gazdagépnevet (ha a DNS fut) User YourUserName # Ha a felhasználó nem egyezik a helyi felhasználóval Port YourSSHPort # Ha nem szabványos port
Ezt követően a paranccsal csatlakozhat a szerverhez
ssh AliasNamessh-agent
Csatlakozási problémák diagnosztizálása
Kapcsolati napló elemzése:
Kliens és szerver konfigurációs fájlok elemzése.
A konfigurációs fájlok helye itt található
Man ssh ember sshd
Intelligens kártyák használata
1. A tanúsítvány létrehozása és a nyilvános kulcs exportálása, valamint a kliens rész Windows + Putty SC rendszeren a következő webhelyen található: http://habrahabr.ru/post/88540/ Az ott leírt Key Manager bővítmény csak a Firefox régebbi verzióiban érhető el. A Windows 3.5-ös verzióján tesztelve. Közvetlen link a kiegészítőhöz: https://addons.mozilla.org/ru/firefox/addon/key-manager/
2. A szerver előkészítése. Győződjön meg arról, hogy az sshd konfiguráció lehetővé teszi a nyilvános kulcsok használatával történő hitelesítést. Ehhez meg kell adnia a „PubkeyAuthentication” paraméter értékét „yes”-re az „sshd_config” fájlban. Ezután hozzáadjuk a korábban megszerzett nyilvános kulcsunkat (egy sorban) a „~/.ssh/authorized_keys” fájlhoz. Kérjük, vegye figyelembe, hogy az „.ssh/authorized_keys” fájl a felhasználó saját könyvtárában található, aki ezután a nyilvános kulccsal jelentkezik be.
3. Kliens rész Linuxon. Újra kell építeni az OpenSSH csomagot paraméterek nélkül. Csak címtárelőtagok megadása javasolt, például –prefix=/usr. Azt is meg kell jegyezni, hogy a konfigurációs fájlok a /usr/etc könyvtárban lesznek. Mielőtt elkezdené, a következő csomagokra van szüksége: opensc-lite-devel, zlib-devel, openssl-devel. Telepítse az intelligens kártya illesztőprogramját. A kényelem érdekében az ssh_config config mezőben (nem tévesztendő össze az sshd_config-gal) adja meg a pkcs könyvtár elérési útját: PKCS11Provider=<путь к библиотеке>
4. A kliensen futtassa az ssh user@host parancsot. Ha az intelligens kártya (token) csatlakoztatva van, a rendszer jelszót kér, és be kell jelentkeznie az SSH-munkamenetbe.
Lehetséges problémák használat közben
A szokásos Ctrl + S billentyűkombináció, amelyet sok szerkesztőben használnak a javítások mentésére, amikor egy terminálon ssh-kiszolgálóval dolgozunk, az XOFF parancs végrehajtásához vezet, amely felületesen a munkamenet lefagyására emlékeztet. Azonban nem. A szerver továbbra is elfogadja a bemeneti karaktereket és parancsokat, de nem jeleníti meg a képernyőn. A helyzetből való kilábaláshoz csak használja a Ctrl + Q kombinációt, ezzel kapcsolja vissza az XON módot.
Linkek
Ez azt jelenti, hogy a user1 regisztrálható mind saját magának - a /home/user1/.ssh/keys fájlban), mind egy másik felhasználó számára, amely lehetővé teszi számára, hogy bejelentkezzen a számítógépéről mind a „maga alatt”, mind a „másik” alatt.
Az SSH (Secure Shell) egy hálózati protokoll, amelyet távoli szerverkezelésre és TCP-titkosított kapcsolatokon keresztüli adatátvitelre terveztek. A legtöbb tárhelyszolgáltatás, még a virtuális is, ma FTP-n és SSH-n keresztül is hozzáférést biztosít. Véleményem szerint ez nagyszerű, az SSH használata sokkal kényelmesebb és biztonságosabb.
SSH beállítása
A beállítás egy dedikált szerverhez, VDS-hez, VPS-hez Debian, Ubuntu rendszeren fog megtörténni. A konfigurációs fájl itt található: /etc/ssh/sshd_config.
Ha rendszeres tárhelye van, mindent úgy kell beállítani, ahogy kell, menjen a szakaszhoz.
Alapértelmezés szerint az SSHD démonnak (amelyen módosítunk) nincs szüksége semmilyen beállításra, és jól működik. Csak néhány apró változtatást hajtunk végre annak érdekében, hogy korlátozzuk a nemkívánatos személyek hozzáférését a szerverhez.
A konfigurációs fájl helytelen módosítása következtében elveszítheti az ssh-n keresztüli hozzáférést a szerverhez, ezért győződjön meg arról, hogy van más hozzáférési lehetősége is, például az ISPManager vezérlőpultján keresztül.
Az SSH hozzáférés korlátozása
Minden módosítás az /etc/ssh/sshd_config fájlban történik
Ahhoz, hogy a változtatások életbe lépjenek, meg kell tennie
Port módosítása
9724-es portMost az engedélyezéskor a 9724-et kell megadnia a szabványos 22-es port helyett.
A módszer nagyon egyszerű és hatékony a legtöbb egyszerű hackerbot ellen, amelyek a szabványos portokon kopogtatnak. Itt az a legfontosabb, hogy ne hozzon létre konfliktust más szolgáltatásokkal, és ne válasszon olyan számot, amely nyilvánvalóan nem használt.
Tiltsa le a kommunikációt a régi protokoll használatával
Itt definiáljuk, hogy a kommunikáció csak a v2 protokoll használatával lehetséges
Ha nem vagy bejelentkezve gyökér, minden konzolparancs előtt hozzá kell adni a sudo-t - ez a rövidítés Helyettesítő felhasználó és DO- cserélje ki a felhasználót, és tegye (alatta). Például lehetővé teszi a parancsok végrehajtását szuperfelhasználóként gyökér.
Csökkentse az engedélyezési kísérletek számát
MaxAuthTries 2Jelszóra tett kísérletek száma. Az alapértelmezés 6. Ha a keresés sikertelen, a kommunikációs munkamenet megszakad.
Csökkentse az engedélyezési várakozási időt
BejelentkezésGraceTime 30sAlapértelmezés szerint egy engedélyezési munkamenet 120 másodpercig tarthat. Ezen idő után véget ér. 2 perc az engedélyezésre túlzás, a szerver mindvégig nyitva tartja a kapcsolatot, ami nagyon irracionális. Fél perc is elég.
Zárja be az IP-hozzáférést
Az IP-korlátozások beállítása előtt győződjön meg arról, hogy a beállítások hibája és a saját IP-címe későbbi kitiltása esetén van egy alternatív módja a szerverhez való hozzáférés visszaszerzésére.
Ha csak Önnek van szüksége hozzáférésre, a legegyszerűbb és legmegbízhatóbb módja az, hogy mindenhonnan letiltja a hozzáférést, kivéve az IP-címét, vagy ha dinamikus, akkor az IP-tartományt.
- Nyissa meg az /etc/hosts.allow fájlt, és adja hozzá az SSHD-t: 192.168.1.1
ahol a 192.168.1.1 az Ön IP-címe. Ha dinamikus IP-címe van, adjon meg egy IP-címet alhálózati maszkkal, és írja le az alhálózatát az IP helyett, például:
SSHD: 192.168.0.0/16
- Nyissa meg az /etc/hosts.deny fájlt, és adja hozzá: SSHD: ALL
Az IP-n keresztüli hozzáférés korlátozásának másik módja
A következő direktívát használhatja:
AllowUsers = *@1.2.3.4
Itt csak az 1.2.3.4 IP-hez engedélyezzük a hozzáférést
SSH engedélyezés kulcsokkal
Sokkal biztonságosabb, kényelmesebb és helyesbb lesz jelszó nélkül beállítani az ssh jogosultságot. Erre a célra kulcsengedélyt használunk.
Tehát itt vannak az utasítások.
Rögtön megvásárolta az első VPS-jét, vagy akár egy szervert is. Biztosan van egy webpanel a kezeléséhez. De a kemény adminok mindig átmennek a konzolon 😉 Ezért meg kell tanulnunk, hogyan kell ezt csinálni. Ebben a leckében telepítjük a PuTTY programot, SSH protokollon keresztül csatlakozunk a szerverhez, és megtanuljuk, hogyan határozzuk meg a szerveren lévő foglalt és szabad területet.
Putty program szerverhez SSH protokollon keresztüli csatlakozáshoz
A Putty letöltése a putty.org webhelyről Saját magam számára letöltöttem a „Windows rendszerhez Intel x86-on - PuTTY: putty.exe” verziót.
Csomagolja ki az archívumot, és indítsa el a programot.
Így néz ki a program ablaka indítás után. Már beírtam a szerverem IP-címét a „Host Name (or IP address)” mezőbe:
Adja meg szervere domainjét vagy IP-címét, majd kattintson a „Megnyitás” gombra. Megnyílik egy parancssor ablak. Felhasználónevet és jelszót kér tőlünk. Először adja meg bejelentkezési nevét, majd jelszavát. Figyelem, a jelszó megadásakor a karakterek nem jelennek meg a képernyőn, még a csillagok *** sem jelennek meg. Ezért a jelszót úgy adjuk meg, mintha vakon. Enter, majd nyomja meg az Entert. Ha a jelszót helyesen adta meg, akkor bejelentkezik a kiszolgáló felügyeleti konzoljába. Megjelenik egy sor az utolsó bejelentkezési idővel és az operációs rendszerrel kapcsolatos információkkal.
Parancsok a konzolban
pwd
df
A df parancs megmutatja a kiszolgálón lévő szabad és felhasznált terület mennyiségét az összes csatlakoztatott fájlrendszerben
du
A du parancs megmutatja, hogy egy mappa vagy fájl mennyi helyet foglal el.
Példa parancs:
Du -h /home/
Ez a parancs megmutatja, mennyi helyet foglal el a /home/ könyvtár.
Ez minden. Véget ért az első ismerkedés az SSH-n és a putty programon keresztüli szerverhez való csatlakozással. Ezen információk felhasználásával felkeresheti a szervert, és megnézheti, mennyi helyet foglalnak el rajta az adatok.
