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
formában kell megadni.felhasználó@gép
:elérési_út
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:17felhaszná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 - Az ssh-agent és az ssh-add szakaszban hamarosan bemutatásra került ssh-agent(1) igyekszik megkímélni minket.
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-agentcsh
%
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.
%
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 '^]'. 220levelező.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.
Gyakran 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
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):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.