110.3 Lecke 1
Tanúsítvány: |
LPIC-1 |
---|---|
Verzió: |
5.0 |
Témakör: |
110 Biztonság |
Fejezet: |
110.3 Az adatok védelme titkosítással |
Lecke: |
1/2 |
Bevezetés
Az adatok titkosítással történő védelme a mai rendszeradminisztráció számos területén kiemelkedő fontosságú — még inkább, amikor a rendszerekhez való távoli hozzáférésről van szó. Az olyan nem biztonságos megoldásokkal szemben, mint a telnet, rlogin vagy FTP, az SSH (Secure Shell) protokollt a biztonság szem előtt tartásával tervezték. A nyilvános kulcsú kriptográfiát használva hitelesíti a hostokat és a felhasználókat, és titkosítja az összes későbbi információcserét. Az SSH továbbá port alagutak (port tunnel) létrehozására is használható, ami — többek között — lehetővé teszi, hogy egy nem titkosított protokoll titkosított SSH-kapcsolaton keresztül továbbítson adatokat. Az SSH protokoll jelenlegi, ajánlott verziója a 2.0. Az OpenSSH az SSH protokoll szabad és nyílt forráskódú implementációja.
Ez a lecke az OpenSSH kliens alapvető konfigurációját, valamint az OpenSSH szerver host kulcsainak szerepét tárgyalja. Az SSH port tunnelek koncepciója is szóba kerül. Két gépet fogunk használni a következő beállításokkal:
Gép szerepe | OS | IP-cím | Hostnév | Felhasználó |
---|---|---|---|---|
Kliens |
Debian GNU/Linux 10 (buster) |
|
|
|
Szerver |
openSUSE Leap 15.1 |
|
|
|
Az OpenSSH kliens alapvető konfigurációja és használata
Bár az OpenSSH szerver és kliens külön csomagokban érkezik, általában telepíthetünk egy metacsomagot, amely egyszerre biztosítja mindkettőt. Az SSH-szerverrel való távoli munkamenet létrehozásához az ssh
parancsot használjuk, megadva a felhasználót, akinek a nevével a távoli gépen csatlakozni szeretnénk, valamint a távoli gép IP-címét vagy hostnevét. Amikor először csatlakozunk egy távoli hosthoz, egy ehhez hasonló üzenetet kapunk:
carol@debian:~$ ssh ina@192.168.1.77 The authenticity of host '192.168.1.77 (192.168.1.77)' can't be established. ECDSA key fingerprint is SHA256:5JF7anupYipByCQm2BPvDHRVFJJixeslmppi2NwATYI. Are you sure you want to continue connecting (yes/no)?
Miután beírtuk, hogy yes
és megnyomtuk az Entert, a rendszer megkérdezi a távoli felhasználó jelszavát. Ha sikeresen megadtuk, megjelenik egy figyelmeztető üzenet, majd bejelentkezünk a távoli gépen:
Warning: Permanently added '192.168.1.77' (ECDSA) to the list of known hosts. Password: Last login: Sat Jun 20 10:52:45 2020 from 192.168.1.4 Have a lot of fun... ina@halof:~>
Az üzenetek eléggé maguktól értetődőek: mivel ez volt az első alkalom, hogy kapcsolatot létesítettünk a 192.168.1.77
távoli szerverrel, annak hitelességét nem lehetett ellenőrizni egyetlen adatbázis alapján sem. Ezért a távoli szerver a nyilvános kulcsának ECDSA kulcsujjlenyomatát
(key fingerprint) adta meg (az SHA256
hash függvényt használva). A kapcsolat elfogadása után a távoli szerver nyilvános kulcsa hozzá lett adva a known hosts adatbázishoz, így lehetővé vált a szerver hitelesítése a jövőbeli kapcsolatokhoz. Az known hosts nyilvános kulcsainak listáját a known_hosts
fájlban tartjuk, amely az ~/.ssh
-ban található:
ina@halof:~> exit logout Connection to 192.168.1.77 closed. carol@debian:~$ ls .ssh/ known_hosts
Mind az .ssh
, mind a known_hosts
az első távoli kapcsolat létrehozása után jött létre. Az ~/.ssh
az alapértelmezett mappa a felhasználó-specifikus konfigurációs és hitelesítési információk számára.
Note
|
Használhatjuk az |
Ha ugyanazt a felhasználót használjuk a helyi és a távoli gépen, akkor az SSH-kapcsolat létrehozásakor nem szükséges a felhasználónév megadása. Ha például a debian
rendszeren carol
felhasználóként vagyunk bejelentkezve, és a halof
rendszerhez szintén carol
felhasználóként szeretnénk csatlakozni, akkor egyszerűen írjuk be az ssh 192.168.1.77
vagy az ssh halof
parancsot (ha a név feloldható):
carol@debian:~$ ssh halof Password: Last login: Wed Jul 1 23:45:02 2020 from 192.168.1.55 Have a lot of fun... carol@halof:~>
Most tegyük fel, hogy új távoli kapcsolatot hozunk létre egy olyan hosttal, amely történetesen ugyanazzal az IP-címmel rendelkezik, mint a halof
(ez gyakori dolog, ha DHCP-t használunk a helyi hálózaton). Figyelmeztetést kapunk a man-in-the-middle támadás lehetőségére:
carol@debian:~$ ssh john@192.168.1.77 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:KH4q3vP6C7e0SEjyG8Wlz9fVlf+jmWJ5139RBxBh3TY. Please contact your system administrator. Add correct host key in /home/carol/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/carol/.ssh/known_hosts:1 remove with: ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77" ECDSA host key for 192.168.1.77 has changed and you have requested strict checking. Host key verification failed.
Mivel nem egy man-in-the-middle támadással van dolgunk, nyugodtan hozzáadhatjuk az új host nyilvános kulcsának ujjlenyomatát az .ssh/known_hosts
állományhoz. Ahogy az üzenet is jelzi, először az ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77"
parancsot használhatjuk az offending kulcs eltávolításához (alternatívaként választhatjuk az ssh-keygen -R 192.168.1.77
parancsot is, hogy törölje az összes 192.168.1.77
kulcsot az ~/.ssh/known_hosts
-ból). Ezután már tudunk kapcsolatot létesíteni az új hosttal.
Kulcsalapú bejelentkezések
Beállíthatjuk az SSH-klienst úgy, hogy bejelentkezéskor ne jelszavakat adjunk meg, hanem nyilvános kulcsokat. Ez az SSH-n keresztül történő távoli szerverhez való csatlakozás előnyben részesített módja, mivel sokkal biztonságosabb. Először is létre kell hoznunk egy kulcspárt a kliensgépen. Ehhez az ssh-keygen
parancsot kell használnunk a -t
kapcsolóval, amely megadja a kívánt titkosítás típusát (esetünkben Elliptic Curve Digital Signature Algorithm). Ezután megkérdezi a kulcspár mentési útvonalát (az ~/.ssh/
ideális, és egyben ez az alapértelmezett hely is), valamint egy passphrase-t. Bár a passphrase megadása opcionális, erősen ajánlott mindig használni egyet.
carol@debian:~/.ssh$ ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/carol/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/carol/.ssh/id_ecdsa. Your public key has been saved in /home/carol/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:tlamD0SaTquPZYdNepwj8XN4xvqmHCbe8g5FKKUfMo8 carol@debian The key's randomart image is: +---[ECDSA 256]---+ | . | | o . | | = o o | | B * | | E B S o | | o & O | | @ ^ = | | *.@ @. | | o.o+B+o | +----[SHA256]-----+
Note
|
A kulcspár létrehozásakor átadhatjuk az |
Az előző parancs két további fájlt hozott létre a ~/.ssh
mappánkban:
carol@debian:~/.ssh$ ls id_ecdsa id_ecdsa.pub known_hosts
id_ecdsa
-
This is your private key.
id_ecdsa.pub
-
This is your public key.
Note
|
Az aszimmetrikus kriptográfiában (más néven nyilvános kulcsú kriptográfia) a nyilvános és a titkos kulcsok matematikailag úgy kapcsolódnak egymáshoz, hogy amit az egyik titkosít, azt csak a másik tudja visszafejteni. |
A következő dolog, amit meg kell tennünk, az az, hogy hozzáadjuk a nyilvános kulcsát annak a felhasználónak az ~/.ssh/authorized_keys
fájljához, akinek a nevén be szeretnénk jelentkezni a távoli hoston (ha az ~/.ssh
mappa még nem létezik, akkor először létre kell hoznunk). A nyilvános kulcsot többféleképpen is átmásolhatjuk a távoli szerverre: USB pendrive segítségével, az scp
paranccsal — ami az SSH segítségével továbbítja a fájlt — vagy úgy, hogy catoljuk a nyilvános kulcs tartalmát, és átadjuk az ssh
-nak egy pipe segítségével, így:
carol@debian:~/.ssh$ cat id_ecdsa.pub |ssh ina@192.168.1.77 'cat >> .ssh/authorized_keys' Password:
Miután a nyilvános kulcsot hozzáadtuk a távoli gépen lévő authorized_keys
fájlhoz, két eshetőséggel szembesülhetünk, amikor új kapcsolatot próbálunk létrehozni:
-
Ha a kulcspár létrehozásakor nem adtunk meg passphrase-t, akkor automatikusan bejelentkezünk. Bár kényelmes, ez a módszer a helyzettől függően nem feltétlenül biztonságos:
carol@debian:~$ ssh ina@192.168.1.77 Last login: Thu Jun 25 20:31:03 2020 from 192.168.1.55 Have a lot of fun... ina@halof:~>
-
Ha a kulcspár létrehozásakor megadtuk a passphrase-t, akkor azt minden kapcsolódásnál ugyanúgy meg kell adni, mintha jelszó lenne. A nyilvános kulcson kívül ez a módszer egy további biztonsági réteget ad hozzá a passphrase formájában, és ezért biztonságosabbnak tekinthető. Ami azonban a kényelmet illeti, ez pontosan ugyanolyan, mintha minden kapcsolat létrehozásakor meg kellene adni a jelszót. Ha nem használunk passphrase-t, és valakinek sikerül megszereznie a privát SSH-kulcsfájlunkat, akkor hozzáférhet minden olyan szerverhez, amelyen a nyilvános kulcs telepítve van.
carol@debian:~/.ssh$ ssh ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': Last login: Thu Jun 25 20:39:30 2020 from 192.168.1.55 Have a lot of fun... ina@halof:~>
Van azonban egy módszer, amely ötvözi a biztonságot és a kényelmet: az SSH authentication agent (ssh-agent
) használata. Ennek saját shellt kell létrehoznia, és a munkamenet hátralévő részében a privát kulcsokat — a nyilvános kulcsú hitelesítéshez — a memóriában tartja. Lássuk egy kicsit részletesebben, hogy ez hogyan működik:
-
Az
ssh-agent
használatával indítsunk egy új Bash shellt:carol@debian:~/.ssh$ ssh-agent /bin/bash carol@debian:~/.ssh$
-
Az
ssh-add
paranccsal hozzáadhatjuk a privát kulcsot a memória egy biztonságos területéhez. Ha a kulcspár létrehozásakor megadtuk a passphrase-t — ami ajánlott az extra biztonság érdekében --, akkor a parancs el fogja kérni azt:carol@debian:~/.ssh$ ssh-add Enter passphrase for /home/carol/.ssh/id_ecdsa: Identity added: /home/carol/.ssh/id_ecdsa (carol@debian)
Miután hozzáadtuk az identitást, anélkül jelentkezhetünk be bármelyik távoli szerverre, amelyen a nyilvános kulcsunk jelen van, hogy újra be kellene írnunk a passphrase-ünket. A modern asztali számítógépeken bevett gyakorlat, hogy ezt a parancsot a számítógép indításakor kell lefuttatni, mivel a számítógép kikapcsolásáig (vagy a kulcs kézzel történő kitöltéséig) a memóriában marad.
Zárjuk le ezt a szakaszt azzal, hogy felsoroljuk a négyféle nyilvános kulcsú algoritmust, amelyek az ssh-keygen
segítségével megadhatók:
RSA
-
Az 1977-ben megjelent, Ron Rivest, Adi Shamir és Leonard Adleman nevével fémjelzett kiadványt az alkotói után nevezték el. Biztonságosnak számít, és ma is széles körben használják. Minimális kulcsmérete 1024 bit (alapértelmezett 2048).
DSA
-
A Digital Signature Algorithm nem bizonyult biztonságosnak, és az OpenSSH 7.0-tól kezdve elavult. A DSA kulcsoknak pontosan 1024 bit hosszúságúnak kell lenniük.
ecdsa
-
Az Elliptic Curve Digital Signature Algorithm a DSA továbbfejlesztése, ezért biztonságosabbnak tekinthető. Elliptikus görbületű kriptográfiát használ. Az ECDSA kulcshosszát a három lehetséges elliptikus görbeméret egyike határozza meg bitben kifejezve: 256, 384 vagy 521 bit.
ed25519
-
Ez az
EdDSA
— Edwards-curve Digital Signature Algorithm — egy olyan implementációja, amely az erősebb 25519-es görbét használja. Ezt tartják a legbiztonságosabbnak az összes közül. Minden Ed25519 kulcs hossza 256 bit.
Note
|
Ha |
Az OpenSSH szerver hostkulcsainak szerepe
Az OpenSSH globális konfigurációs könyvtára az /etc
mappában található:
halof:~ # tree /etc/ssh /etc/ssh ├── moduli ├── ssh_config ├── ssh_host_dsa_key ├── ssh_host_dsa_key.pub ├── ssh_host_ecdsa_key ├── ssh_host_ecdsa_key.pub ├── ssh_host_ed25519_key ├── ssh_host_ed25519_key.pub ├── ssh_host_rsa_key ├── ssh_host_rsa_key.pub └── sshd_config 0 directories, 11 files
A moduli
, a kliens (ssh_config
), valamint a szerver (sshd_config
) konfigurációs fájljain kívül négy kulcspárt találunk — minden támogatott algoritmushoz egy kulcspárt --, amelyek az OpenSSH szerver telepítésekor jönnek létre. Mint már említettük, a szerver ezeket a hostkulcsokat használja arra, hogy szükség szerint azonosítsa magát a kliensek számára. A nevek mintája a következő:
- Privát kulcsok
-
ssh_host_
prefix + algoritmus +key
suffix (pl.:ssh_host_rsa_key
) - Publikus kulcsok (vagy publikus kulcs ujjlenyomatok)
-
ssh_host_
prefix + algoritmus +key.pub
suffix (pl.:ssh_host_rsa_key.pub
)
Note
|
Az ujjlenyomat egy kriptográfiai hash-függvény nyilvános kulcsra történő alkalmazásával jön létre. Mivel az ujjlenyomatok rövidebbek, mint a kulcsok, amelyekre vonatkoznak, jól jönnek bizonyos kulcskezelési feladatok egyszerűsítéséhez. |
A privát kulcsokat tartalmazó fájlok jogosultságai 0600
vagy -rw-------
: csak a tulajdonos (root
) olvashatja és írhatja. Az összes nyilvános kulcsfájlt pedig a tulajdonos csoport tagjai és mindenki más is olvashatja (0644
vagy -rw-r—r--
):
halof:~ # ls -l /etc/ssh/ssh_host_* -rw------- 1 root root 1381 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key -rw-r--r-- 1 root root 605 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key.pub -rw------- 1 root root 505 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key -rw-r--r-- 1 root root 177 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key.pub -rw------- 1 root root 411 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key -rw-r--r-- 1 root root 97 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key.pub -rw------- 1 root root 1823 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key -rw-r--r-- 1 root root 397 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key.pub
A kulcsok ujjlenyomatait az ssh-keygen
-l
kapcsolójának használatával nézhetjük meg. A kulcsfájl elérési útvonalának megadásához az -f
kapcsolót is meg kell adnunk:
halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519) halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)
A kulcs ujjlenyomatának és a véletlenszerűségének megtekintéséhez csak adjuk hozzá a -v
kapcsolót a következő módon:
halof:~ # ssh-keygen -lv -f /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519) +--[ED25519 256]--+ | +oo| | .+o.| | . ..E.| | + . +.o| | S + + *o| | ooo Oo=| | . . . =o+.==| | = o =oo o=o| | o.o +o+..o.+| +----[SHA256]-----+
SSH port tunnelek
Az OpenSSH hatékony továbbítási funkcióval rendelkezik, amelynek segítségével a forrásporton érkező forgalom tunnelbe kerül egy SSH folyamaton keresztül — titkosítva --, amely aztán átirányítja azt egy célállomás portjára. Ez a mechanizmus port tunnelling vagy port forwarding néven ismert, és olyan fontos előnyei vannak, mint az alábbiak:
-
Lehetővé teszi a tűzfalak megkerülését a távoli host portjainak eléréséhez.
-
Lehetővé teszi a hozzáférést kívülről a privát hálózaton lévő hosthoz.
-
Titkosítást biztosít minden adatcseréhez.
Többé-kevésbé mondhatjuk azt, hogy megkülönböztethetünk helyi és távoli port tunnellinget.
Helyi port tunnel
Helyileg meghatároz egy portot, amely a célállomás felé továbbítja a forgalmat a közbeiktatott SSH-folyamaton keresztül. Az SSH-folyamat futhat a helyi hoston vagy egy távoli szerveren. Ha például valamilyen okból a helyi gépen lévő 8585
portot használó SSH-n keresztül a www.gnu.org
-hoz szeretnénk a kapcsolatot tunnelezni, akkor valami ilyesmit tehetünk:
carol@debian:~$ ssh -L 8585:www.gnu.org:80 debian carol@debian's password: Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 The programs included with the Debian GNU/Linux system are free software; (...) Last login: Sun Jun 28 13:47:27 2020 from 127.0.0.1
A magyarázat a következő: az -L
kapcsolóval a 8585
helyi portot adjuk meg, hogy a www.gnu.org
http port 80
portjához csatlakozzunk a debian
-- a mi localhost-unkon futó SSH folyamat segítségével. Ugyanezt a hatást elérhetnénk, ha azt írnánk, hogy ssh -L 8585:www.gnu.org:80 localhost
. Ha most egy webböngészővel a http://localhost:8585
címre megyünk, akkor a www.gnu.org
címre fog továbbítani minket. A példa demonstrálásához a lynx
-t (a klasszikus, szöveges módú webböngészőt) fogjuk használni:
carol@debian:~$ lynx http://localhost:8585 (...) * Back to Savannah Homepage * Not Logged in * Login * New User * This Page * Language * Clean Reload * Printer Version * Search * _ (...)
Ha pontosan ugyanezt akarnánk csinálni, de a halof
rendszeren futó SSH folyamaton keresztül csatlakozva, akkor a következőképpen járhatunk el:
carol@debian:~$ ssh -L 8585:www.gnu.org:80 -Nf ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': carol@debian:~$ carol@debian:~$ lynx http://localhost:8585 (...) * Back to Savannah Homepage * Not Logged in * Login * New User * This Page * Language * Clean Reload * Printer Version * Search * _ (...)
Fontos, hogy észrevegyünk három részletet a parancsban:
-
Az
-N
kapcsolónak köszönhetően nem jelentkeztünk be a `halof'-ba, hanem helyette port forwardingot végeztünk. -
Az
-f
kapcsoló utasította az SSH-t, hogy a háttérben fusson. -
Megadtuk az
ina
felhasználót a továbbításhoz:ina@192.168.1.77
Távoli port tunnel
A távoli port tunnelling (vagy fordított port forwarding) során a távoli szerver egy portján érkező forgalom a helyi gépen futó SSH-folyamathoz, majd onnan a célszerver (amely lehet a helyi gép is) megadott portjára továbbítódik. Tegyük fel például, hogy meg szeretnénk engedni a hálózaton kívülről valakinek, hogy a helyi gépünkön futó Apache webszervert a halof
(192.168.1.77
) SSH-szerveren futó 8585
porton keresztül érhesse el! A következő parancsot használnánk:
carol@debian:~$ ssh -R 8585:localhost:80 -Nf ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': carol@debian:~$
Mostantól bárki, aki kapcsolódik a halof
-hoz a 8585
porton, a Debian
Apache2 alapértelmezett honlapját fogja látni:
carol@debian:~$ lynx 192.168.1.77:8585 (...) Apache2 Debian Default Page: It works (p1 of 3) Debian Logo Apache2 Debian Default Page It works! This is the default welcome page used to test the correct operation of the Apache2 server after installation on Debian systems. If you can read this page, it means that the Apache HTTP server installed at this site is working properly. You should replace this file (located at /var/www/html/index.html) before continuing to operate your HTTP server. (...)
Note
|
Létezik egy harmadik, összetettebb port forwarding típus, amely nem tartozik ennek a leckének a tárgykörébe: a dinamikus port forwarding. Ahelyett, hogy egyetlen porttal lépne kapcsolatba, ez a fajta továbbítás különböző TCP-kommunikációkat használ egy sor porton keresztül. |
X11 tunnelek
Most, hogy értjük a port tunneleket, fejezzük be a leckét az X11 tunnel (más néven X11forwarding) megvitatásával. Az X11 tunnelen keresztül a távoli hoston lévő X Window System a helyi gépre kerül továbbításra. Ehhez csak át kell adni az ssh
-nak a -X
opciót:
carol@debian:~$ ssh -X ina@halof ...
Most már elindíthatunk egy grafikus alkalmazást, például a firefox
webböngészőt a következő eredménnyel: az alkalmazás a távoli szerveren fog futni, de a megjelenítés a helyi gépre lesz továbbítva.
Ha a -x
kapcsolóval indítunk új SSH-munkamenetet, az X11forwarding le lesz tiltva. Ha most próbáljuk meg elindítani a firefoxot
, a következő hibát fogjuk kapni:
carol@debian:~$ ssh -x ina@halof carol@192.168.0.106's password: (...) ina@halof:~$ firefox (firefox-esr:1779): Gtk-WARNING **: 18:45:45.603: Locale not supported by C library. Using the fallback 'C' locale. Error: no DISPLAY environment variable specified
Note
|
A helyi, a távoli és az X11 port forwardinghoz kapcsolódó három konfigurációs direktíva a következő: |
Gyakorló feladatok
-
A kliensgépen
sonya
felhasználóként bejelentkezve hajtsuk végre a következő SSH feladatokat a távolihalof
szerveren:-
Listázzuk az
~/.ssh
tartalmátserena
felhasználóként a távoli gépen; majd térjünk vissza a helyi terminálba! -
Jelentkezzünk be
serena
felhasználóként a távoli gépre! -
Jelentkezzünk be
sonya
felhasználóként a távoli gépre! -
Töröljük az összes
halof
-hoz tartozó kulcsot a helyi~/.ssh/known_hosts
fájlunkból! -
Hozzunk létre egy 256 bites
ecdsa
kulcspárt a kliensgépen! -
Hozzunk létre egy 256 bites
ed25519
kulcspárt a kliensgépen!
-
-
Rendezzük a végrehajtás szerinti sorrendbe az alábbi lépéseket, amelyek az az SSH authentication agent használatával hozzák létre az SSH-kapcsolatot:
-
A kliensen indítsunk egy új Bash-shellt az authentication agent számára az
ssh-agent /bin/bash
paranccsal! -
A kliensen hozzunk létre egy kulcspárt az
ssh-keygen
segítségével! -
A kliensen adjuk hozzá a privát kulcsot a memória egy biztonságos területéhez az
ssh-add
segítségével! -
Adjuk hozzá a kliens nyilvános kulcsát annak a felhasználónak az
~/.ssh/authorized_keys
fájljához, akit a távoli hoston be akarunk jelentkeztetni! -
Ha még nem létezik, hozzuk létre az
~/.ssh
-t azon felhasználó számára, akit a szerveren be szeretnénk jelentkeztetni! -
Csatlakozzunk a távoli szerverhez!
A helyes sorrend:
1. lépés:
2. lépés:
3. lépés:
4. lépés:
5. lépés:
6. lépés:
-
-
A port forwarding tekintetében milyen opciót és direktívát használnak a következő tunnel típusok esetében:
Tunnel típusa Opció Direktíva Lokális
Remote vagy Reverse
X
-
Tegyük fel, hogy a kliens termináljába beírjuk az
ssh -L 8888:localhost:80 -Nf ina@halof
parancsot. Még mindig a kliensgépen a böngészővel nyissuk meg ahttp://localhost:8888
címet! Mit fogunk kapni?
Gondolkodtató feladatok
-
A biztonsági irányelvek figyelembevételével:
-
Milyen direktívát használnak az
/etc/ssh/sshd_config'-ban a `root
bejelentkezések engedélyezéséhez: -
Milyen direktívát használhatnánk az `/etc/ssh/sshd_config'-ban ahhoz, hogy csak egy helyi fiókot adjunk meg az SSH-kapcsolatok elfogadásához?
-
-
Ha ugyanazt a felhasználót használja a kliens és a szerver, milyen
ssh
paranccsal tudjuk átküldeni a kliens nyilvános kulcsát a szerverre, hogy nyilvános kulcsos hitelesítéssel tudjon bejelentkezni? -
Hozzunk létre két helyi port tunnelt egyetlen paranccsal, amelyek a 8080-as és a 8585-ös nem privilegizált helyi portokat továbbítják a
halof
távoli szerveren keresztül awww.gnu.org
és awww.melpa.org
weboldalakra! Azina
felhasználót használjuk a távoli szerveren, és ne felejtsük el használni az-Nf
kapcsolókat:
Összefoglalás
Ebben a leckében az OpenSSH 2-t tárgyaltuk, amely a Secure Shell protokollt használja a szerver és a kliens közötti kommunikáció titkosítására. Megtanultuk:
-
hogyan jelentkezzünk be egy távoli szerverre.
-
hogyan futtassunk parancsokat távolról.
-
hogyan hozzunk létre kulcspárokat.
-
hogyan lehet kulcs-alapú bejelentkezéseket létrehozni.
-
hogyan használjuk az authentication agentet az extra biztonság és kényelem érdekében.
-
az OpenSSH által támogatott publikus-kulcs algoritmusok:
RSA
,DSA
,ecdsa
,ed25519
. -
az OpenSSH hostkulcsainak szerepe.
-
hogyan hozzunk létre port tunneleket: lokális, távoli és X.
A leckében az alábbi parancsokat tárgyaltuk:
ssh
-
Bejelentkezés vagy parancsok végrehajtása egy távoli gépen.
ssh-keygen
-
Autentikációs kulcsok generálása, menedzselése vagy konvertálása.
ssh-agent
-
OpenSSH autentikációs agent.
ssh-add
-
Privát kulcs identitások hozzáadása az autentikációs agenthez.
Válaszok a gyakorló feladatokra
-
A kliensgépen
sonya
felhasználóként bejelentkezve hajtsuk végre a következő SSH feladatokat a távolihalof
szerveren:-
Listázzuk az
~/.ssh
tartalmátserena
felhasználóként a távoli gépen; majd térjünk vissza a helyi terminálba!ssh serena@halof ls .ssh
-
Jelentkezzünk be
serena
felhasználóként a távoli gépre!ssh serena@halof
-
Jelentkezzünk be
sonya
felhasználóként a távoli gépre!ssh halof
-
Töröljük az összes
halof
-hoz tartozó kulcsot a helyi~/.ssh/known_hosts
fájlunkból!ssh-keygen -R halof
-
Hozzunk létre egy 256 bites
ecdsa
kulcspárt a kliensgépen!ssh-keygen -t ecdsa -b 256
-
Hozzunk létre egy 256 bites
ed25519
kulcspárt a kliensgépen!ssh-keygen -t ed25519
-
-
Rendezzük a végrehajtás szerinti sorrendbe az alábbi lépéseket, amelyek az az SSH authentication agent használatával hozzák létre az SSH-kapcsolatot:
-
A kliensen indítsunk egy új Bash-shellt az authentication agent számára az
ssh-agent /bin/bash
paranccsal! -
A kliensen hozzunk létre egy kulcspárt az
ssh-keygen
segítségével! -
A kliensen adjuk hozzá a privát kulcsot a memória egy biztonságos területéhez az
ssh-add
segítségével! -
Adjuk hozzá a kliens nyilvános kulcsát annak a felhasználónak az
~/.ssh/authorized_keys
fájljához, akit a távoli hoston be akarunk jelentkeztetni! -
Ha még nem létezik, hozzuk létre az
~/.ssh
-t azon felhasználó számára, akit a szerveren be szeretnénk jelentkeztetni! -
Csatlakozzunk a távoli szerverhez!
A helyes sorrend:
1. lépés:
A kliensen hozzunk létre egy kulcspárt az
ssh-keygen
segítségével!2. lépés:
Ha még nem létezik, hozzuk létre az
~/.ssh
-t azon felhasználó számára, akit a szerveren be szeretnénk jelentkeztetni!3. lépés:
Adjuk hozzá a kliens nyilvános kulcsát annak a felhasználónak az
~/.ssh/authorized_keys
fájljához, akit a távoli hoston be akarunk jelentkeztetni!4. lépés:
A kliensen indítsunk egy új Bash-shellt az authentication agent számára az
ssh-agent /bin/bash
paranccsal!5. lépés:
A kliensen adjuk hozzá a privát kulcsot a memória egy biztonságos területéhez az
ssh-add
segítségével!6. lépés:
Csatlakozzunk a távoli szerverhez!
-
-
A port forwarding tekintetében milyen opciót és direktívát használnak a következő tunnel típusok esetében:
Tunnel típusa Opció Direktíva Lokális
-L
AllowTcpForwarding
Remote vagy Reverse
-R
GatewayPorts
X
-X
X11Forwarding
-
Tegyük fel, hogy a kliens termináljába beírjuk az
ssh -L 8888:localhost:80 -Nf ina@halof
parancsot. Még mindig a kliensgépen a böngészővel nyissuk meg ahttp://localhost:8888
címet! Mit fogunk kapni?A webszerver
halof
kezdőoldalát, mintlocalhost
-ot a szerver szemszögéből értendően.
Válaszok a gondolkodtató feladatokra
-
A biztonsági irányelvek figyelembevételével:
-
Milyen direktívát használnak az
/etc/ssh/sshd_config'-ban a `root
bejelentkezések engedélyezéséhez:PermitRootLogin
-
Milyen direktívát használhatnánk az `/etc/ssh/sshd_config'-ban ahhoz, hogy csak egy helyi fiókot adjunk meg az SSH-kapcsolatok elfogadásához:
AllowUsers
-
-
Ha ugyanazt a felhasználót használja a kliens és a szerver, milyen
ssh
paranccsal tudjuk átküldeni a kliens nyilvános kulcsát a szerverre, hogy nyilvános kulcsos hitelesítéssel tudjon bejelentkezni?ssh-copy-id
-
Hozzunk létre két helyi port tunnelt egyetlen paranccsal, amelyek a 8080-as és a 8585-ös nem privilegizált helyi portokat továbbítják a
halof
távoli szerveren keresztül awww.gnu.org
és awww.melpa.org
weboldalakra! Azina
felhasználót használjuk a távoli szerveren, és ne felejtsük el használni az-Nf
kapcsolókat:ssh -L 8080:www.gnu.org:80 -L 8585:www.melpa.org:80 -Nf ina@halof