Az OpenSSH olyan hálózati kapcsolódási eszközök összessége, amivel biztonságos módon érhetünk el távoli számítógépeket. Az rlogin, rsh, rcp és a telnet direkt kiváltására használható. Emellett SSH-n keresztül TCP/IP kapcsolatok is biztonságosan bújtathatóak vagy küldhetőek tovább.
Az OpenSSH-t az OpenBSD projekt tartja karban, és az SSH 1.2.12 verziójára épül hibajavításokkal és frissítésekkel egyetemben. Az SSH 1 és 2 protokollokkal egyaránt kompatibilis.
A hétköznapi esetben, vagyis amikor a telnet(1) vagy rlogin(1) alkalmazásokat használjuk, az adatok titkosítatlan formában közlekednek a hálózaton. A szerver és a kliens közé bárhova becsatlakozó hálózati kíváncsiskodók így könnyedén el tudják lopni a felhasználói nevünket és jelszavunkat, vagy lényegében bármilyen adatot, ami az adott munkamenetben megfordul. Az OpenSSH ennek kivédésére kínál fel különféle hitelesítési és titkosítási eszközöket.
Az sshd a FreeBSD telepítésekor jelentkező Standard lehetőségek egyike. Az sshd engedélyezését úgy tudjuk kideríteni, ha az rc.conf állományban megkeressük a következő sort:
sshd_enable="YES"
Ez tölti be a rendszer indításakor az sshd(8)-t, az OpenSSH démonát. Vagy az /etc/rc.d/sshd rc(8) szkript segítségével is elindíthatjuk az OpenSSH-t:
/etc/rc.d/sshd start
Az ssh(1) segédprogram az rlogin(1) programhoz hasonlóan működik.
# ssh felhasználó@gép.hu Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'gép.hu' added to the list of known hosts. felhasználó@gép.hu's password: *******
Az üzenetek fordítása:
Nem találtam meg a gépet az ismert gépek között. Biztosan csatlakozni akarunk hozzá (igen/nem)? igen A 'gép.hu' felkerült az ismert gépek közé. Adja meg a felhasználó@gép.hu jelszavát:
Bejelentkezés után minden ugyanolyan, mintha az rlogin vagy a telnet programokat használtuk volna. Az SSH egy kulcs segítségével próbálja azonosítani a számítógépeket, ezzel ellenőrzi a szerver hitelességét a kliensek csatlakozásakor. A felhasználónak ilyenkor először mindig yes választ kell adnia. A későbbi bejelentkezési kísérletek pedig majd mindig az így kapott kulccsal történnek. Ha eltérne a kulcs, akkor az SSH kliens erre figyelmeztetni fog minket. A kulcsok a ~/.ssh/known_hosts vagy az SSH v2 protokoll esetén a ~/.ssh/known_hosts2 állományba kerülnek elmentésre.
Alapértelmezés szerint az
OpenSSH szerverek csak SSH v2
kapcsolatokat fogadnak el. Lehetőség szerint a
kliens is ezt a változatot fogja használni, de ha
nem sikerül, akkor megpróbálkozik a v1-el. A
kliensnek a -1
vagy -2
opciók segítségével elő is
lehet írni, hogy az első vagy a második
változatot használja. A kliensben az első
változat támogatását csupán a
régebbi verziók kompatibilitása miatt
tartják karban.
Az scp(1) parancs az rcp(1) parancshoz hasonlóan működik: egyik gépről másol a másikra, biztonságosan.
# scp felhasználó@gép.hu:/COPYRIGHT COPYRIGHT felhasználó@gép.hu's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 #
Mivel a kulcsot már ismerjük ehhez a távoli géphez (az előbbi példából), ezért az scp(1) használatakor már ezzel hitelesítünk.
Az scp(1) paraméterei hasonlóak a
cp(1) parancséhoz: első helyen az
állomány vagy állományok neveit
adjuk meg, a másodikon pedig a célt. Mivel az
állományokat a hálózaton SSH-n
keresztül küldik át, ezért az
állományok neveit
felhasználó@gép:elérési_út
formában kell megadni.
Az OpenSSH démon és kliens rendszerszintű konfigurációs állományai az /etc/ssh könyvtárban találhatóak.
Az ssh_config tartalmazza a kliens beállításait, miközben az sshd_config tartalmazza a démonét.
Emellett az rc.conf
állományban megadható
sshd_program
(ez alapból a
/usr/sbin/sshd) és
sshd_flags
opciókkal további
beállítási szinteket
nyújtanak.
Jelszavak helyett az ssh-keygen(1) programmal a felhasználók azonosítására DSA- vagy RSA-kulcsokat tudunk készíteni:
% ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/felhasználó/.ssh/id_dsa): Created directory '/home/felhasználó/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/felhasználó/.ssh/id_dsa. Your public key has been saved in /home/felhasználó/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 felhasználó@gép.hu
Az ssh-keygen(1) ekkor a hitelesítésre létrehoz egy publikus és egy privát kulcsból álló párt. A privát kulcs a ~/.ssh/id_dsa vagy ~/.ssh/id_rsa állományba kerül, miközben a publikus kulcs a ~/.ssh/id_dsa.pub vagy ~/.ssh/id_rsa.pub lesz attól függően, hogy DSA vagy RSA a kulcs típusa. A módszer működéséhez a publikus DSA- vagy RSA-kulcsot a távoli számítógép ~/.ssh/authorized_keys állományába kell bemásolni.
Így tehát a távoli számítógépre jelszavak alkalmazása helyett SSH-kulccsal tudunk belépni.
Ha az ssh-keygen(1) parancsnak megadunk egy jelmondatot is, akkor a felhasználó a privát kulcsát csak ennek megadásával tudja használni. A hosszú jelmondatok állandó beirogatásától a 14.11.7 Szakasz szakaszban hamarosan bemutatásra került ssh-agent(1) igyekszik megkímélni minket.
Figyelem: A különböző opciók és állományok eltérhetnek a számítógépünkre telepített OpenSSH verziójától függően. Ilyen esetben javasolt felkeresni az ssh-keygen(1) man oldalát.
Az ssh-agent(1) és ssh-add(1) segédprogramokkal be tudjuk tölteni az SSH-kulcsokat a memóriába, amivel elkerülhetjük a jelmondat állandó begépelését.
A hitelesítést az ssh-agent(1) program kezeli a betöltött privát kulcsok alapján. Az ssh-agent(1) használatával egy másik programot is elindhatunk, egy parancsértelmezőtől kezdve egy ablakkezelőig szinte bármit.
Az ssh-agent(1) programot úgy tudjuk egy parancsértelmezőben használni, hogy először is elindítjuk vele az adott parancsértelmezőt. Ezután az ssh-add(1) lefuttatásával hozzá kell adnunk egy identitást, annak jelmondatának megadásával. Miután ezeket megtettük, a felhasználó bármelyik olyan távoli gépre be tud jelentkezni, ahol a publikus kulcsát ismerik. Például:
% ssh-agent csh % ssh-add Enter passphrase for /home/felhasználó/.ssh/id_dsa: Identity added: /home/felhasználó/.ssh/id_dsa (/home/felhasználó/.ssh/id_dsa) %
Az ssh-agent(1) programot X11-el úgy tudjuk használni, ha az ~/.xinitrc állományba tesszük bele. Ezzel az ssh-agent(1) az összes X11-ben indított program számára rendelkezésre áll. Példának vegyük ezt az ~/.xinitrc állományt:
exec ssh-agent startxfce4
Így az X11 indulásakor mindig elindul az ssh-agent(1), amely pedig elindítja az XFCE alkalmazást. Miután átírtuk a saját állományunkat, a rendszer életbeléptetéséhez indítsuk újra az X11-et, az ssh-add(1) futtatásával pedig töltsük be az összes SSH-kulcsunkat.
Az OpenSSH-val létre tudunk hozni egy tunnelt, amellyel egy másik protokoll adatait tudjuk titkosított módon becsomagolni.
Az alábbi parancs arra utasítja az ssh(1) programot, hogy hozzon létre egy tunnelt a telnet használatához:
% ssh -2 -N -f -L 5023:localhost:23 felhasználó@izé.mizé.hu %
Az ssh parancsnak a következő kapcsolókat adtuk meg:
-2
Az ssh parancs a protokoll második változatát használja. (Ne adjuk meg, ha régi SSH szerverekkel dolgozunk.)
-N
Tunnel létrehozása. Ha nem adjuk meg, akkor az ssh egy hagyományos munkamenet felépítését kezdi meg.
-f
Az ssh a háttérben fusson.
-L
Egy helyi tunnel a helyiport:távoligép:távoliport felírásban.
felhasználó@izé.mizé.hu
A távoli SSH szerver.
Az SSH által létrehozott járatok úgy működnek, hogy létrehozunk egy csatlakozást a localhost (a helyi gép) megadott portján. Ezután minden olyan kapcsolatot, ami a helyi gép adott portjára érkezik, SSH-n keresztül átirányítunk a távoli gép portjára.
Ebben a példában a helyi gép 5023 portját átirányítjuk a helyi gép 23 portjára. Mivel a 23 a telnet portja, ezért az így definiált SSH járattal egy biztonságos telnet munkamenetet hozunk létre.
Ezen a módon tetszőleges nem biztonságos TCP protokollt, például SMTP-t, POP3-at, FTP-t stb. be tudunk csomagolni.
Példa 14-1. Biztonságos tunnel létrehozása SSH-val SMTP-hez
% ssh -2 -N -f -L 5025:localhost:25 felhasználó@levelező.szerver.hu felhasználó@levelező.szerver.hu's password: ***** % telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 levelező.szerver.hu ESMTP
Az ssh-keygen(1) és további felhasználói hozzáférések alkalmazásával ezen a módon ki tudunk alakítani egy minden további problémától és zűrtől mentes SSH tunnelezési környezetet. A jelszavak helyett kulcsokat használunk és minden tunnel külön felhasználóként is futtatható.
Tegyük fel, hogy a munkahelyünkön van egy SSH szerver, amire kívülről lehet csatlakozni, illetve vele egy hálózatban van egy POP3 levelező szerver is. A munkahelyünk és az otthonunk között levő hálózati útvonalat részben vagy teljesen nem tartjuk megbízhatónak. Ezért az e-mailjeinket valamilyen biztonságos módon szeretnénk elérni. Ezt úgy tudjuk megvalósítani, ha otthonról csatlakozunk a munkahelyen levő SSH szerverre és ezen keresztül érjük a levelező szervert.
% ssh -2 -N -f -L 2110:levél.gép.hu:110 felhasználó@ssh-szerver.gép.hu felhasználó@ssh-szerver.gép.hu's password: ******
Miután a tunnel létrejött és működőképes, állítsuk be a levelező kliensünkben, hogy a POP3 kéréseket a localhost 2110 portjára küldje. Innen pedig biztonságos módon megy tovább a levél.gép.hu címre.
Egyes hálózati adminisztrátorok túlságosan szigorú szabályokat adnak meg a tűzfalban, és nem csak a bejövő kapcsolatokat szűrik, hanem a kimenőket is. A távoli gépekhez csak a 22 (SSH) és 80 (böngészés) portjaikon tudunk csatlakozni.
Mi viszont szeretnénk más (nem egészen a munkánkkal kapcsolatos) szolgáltatásokat is elérni, például egy Ogg Vorbis szerverről zenét hallgatni. Ehhez a szerverhez viszont csak akkor tudnánk csatlakozni, ha a 22 vagy 80 portokon üzemelne.
Ezt a problémát úgy oldhatjuk meg, ha felépítünk egy SSH kapcsolatot a hálózatunk tűzfalán kívül levő számítógéppel és segítségével átbújunk az Ogg Vorbis szerverhez.
% ssh -2 -N -f -L 8888:zene.gép.hu:8000 felhasználó@tűzfalazatlan-rendszer.gép.org felhasználó@tűzfalazatlan-rendszer.gép.org's password: *******
A zenelejátszó kliensüknek adjuk meg a localhost 8888 portját, amely pedig a tűzfal sikeres kijátszásával továbbítódik a zene.gép.hu 8000-res portjára.
AllowUsers
felhasználói
beállításGyakran nem árt korlátozni a felhasználók bejelentkezését. Az AllowUsers erre tökéletesen megfelel. Például, ha csak 192.168.1.32 címről engedjük bejelentkezni a root felhasználót, akkor ehhez valami ilyesmit kell beírnunk az /etc/ssh/sshd_config állományba:
AllowUsers root@192.168.1.32
Ezzel pedig csupán nevének megadásával engedélyezzük az admin felhasználó bejelentkezését (bárhonnan):
AllowUsers admin
Egy sorban több felhasználó is megadható, mint például:
AllowUsers root@192.168.1.32 admin
Megjegyzés: Ilyenkor ne felejtsük el megadni az összes bejelentkezésre (valamilyen formában) jogosult felhasználót megadni, máskülönben kizárjuk ezeket.
Miután elvégeztük a szükséges változtatásokat az /etc/ssh/sshd_config állományban, utasítsuk az sshd(8) démont a konfigurációs állományok újraolvasására:
# /etc/rc.d/sshd reload
Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <gabor@FreeBSD.org>.