Név
sshd - OpenSSH SSH démon
Szinopszis
[- g_kiszolgáló_kiszolgáló_ ] [- k_készlet_kiszolgáló ] [- k_kiszolgáló ] [-
Leírás
Az sshd (SSH Daemon) az ssh (1) démonprogramja. Ezek a programok együttesen helyettesítik a rlogint és rsh , és biztonságos titkosított kommunikációt biztosít két megbízhatatlan gazda között egy bizonytalan hálózat fölött. A programokat a lehető legegyszerűbb telepíteni és használni.
Az sshd az a démon, amely figyeli az ügyfelek kapcsolatait. Rendszerint az / etc / rc rendszerindításkor indított. Minden egyes bejövő kapcsolathoz új démont kíván. A villás démonok a kulcscserét, a titkosítást, a hitelesítést, a parancsfuttatást és az adatcserét kezelik. Az sshd ezen implementációja egyszerre támogatja az SSH protokoll 1. és 2. verzióját.
SSH protokoll 1. verziója
Minden gazdagépnek van hostspecifikus RSA kulcsja (általában 1024 bites), amely a gazda azonosítására szolgál. Emellett, amikor a démon elindul, egy szerver RSA kulcsot generál (általában 768 bit). Ezt a kulcsot általában óránként regenerálják, ha használják, és soha nem tárolják a lemezen.
Amikor egy kliens csatlakozik, a démon válaszol a nyilvános fogadó és szerver kulcsaira. Az ügyfél összehasonlítja az RSA-gazda kulcsát saját adatbázisával annak ellenőrzésére, hogy nem változott-e. Az ügyfél ezután 256 bites véletlenszámot generál. Ezt a véletlen számot titkosítja mind a gazda kulcs, mind a kiszolgáló kulcs segítségével, és elküldi a titkosított számot a kiszolgálónak. Mindkét fél akkor használja ezt a véletlen számot session kulcsként, amelyet minden további kommunikáció titkosítására használ a munkamenetben. A munkamenet többi része hagyományos titkosítással titkosítva van, jelenleg Blowfish vagy 3DES, a 3DES alapértelmezés szerint. Az ügyfél kiválasztja a titkosítási algoritmust a kiszolgáló által kínált felhasználástól.
Ezután a kiszolgáló és az ügyfél beírja a hitelesítési párbeszédablakot. Az ügyfél megpróbálja hitelesíteni magát a .rhosts hitelesítés, a .rhosts hitelesítés kombinálva az RSA gazda hitelesítéssel, az RSA kihívás-válasz-hitelesítéssel vagy a jelszóalapú hitelesítéssel .
A Rhosts hitelesítés általában le van tiltva, mert alapvetően bizonytalan, de szükség esetén engedélyezhető a kiszolgáló konfigurációs fájljában. A rendszerbiztonság nem javul, hacsak az rshd rlogind és a rexecd nincsenek letiltva (ezáltal teljesen letiltja a rlogint és az rsh-et a gépbe).
SSH protokoll 2. verziója
A 2-es verzió hasonlóan működik: Minden állomásnak gazdagép-specifikus kulccsal (RSA vagy DSA) kell rendelkeznie a gazda azonosításához. Amikor azonban a démon elindul, nem hoz létre kiszolgáló kulcsot. A továbbítás biztonságát a Diffie-Hellman kulcsfontosságú megállapodás biztosítja. Ez a kulcsfontosságú megállapodás egy megosztott munkamenetkulcsot eredményez.
A munkamenet többi része titkosítva van egy szimmetrikus titkosítással, jelenleg 128 bites AES, Blowfish, 3DES, CAST128, Arcfour, 192 bites AES vagy 256 bites AES. Az ügyfél kiválasztja a titkosítási algoritmust a kiszolgáló által kínált felhasználástól. Ezenkívül a munkamenet-integritást kriptográfiai üzenet hitelesítési kód (hmac-sha1 vagy hmac-md5) biztosítja.
A 2. verzióban nyilvános kulcs alapú felhasználó (PubkeyAuthentication) vagy ügyfél-gazdagép (HostbasedAuthentication) hitelesítési módszer, hagyományos jelszó-hitelesítés és a kihívás-válasz alapú módszerek.
Parancsfuttatás és adatátvitel
Ha az ügyfél sikeresen hitelesítette magát, akkor a munkamenet előkészítéséhez párbeszédpanel kerül beírásra. Ekkor az ügyfél kérheti olyan dolgokat, mint például pszeudo-tty, X11 kapcsolatok továbbítása, TCP / IP kapcsolatok továbbítása vagy a hitelesítési ügynök kapcsolata továbbítása a biztonságos csatornán.
Végül az ügyfél parancsot kér, vagy végrehajt egy parancsot. Az oldalak ezután belépnek a munkamenetbe. Ebben a módban bármelyik fél bármikor elküldheti az adatokat, és ezeket az adatokat továbbítja a kiszolgálói oldal shelljébe vagy parancsára, illetve a kliens oldal felhasználói termináljára.
Amikor a felhasználói program befejeződik, és minden továbbított X11 és egyéb kapcsolatok le vannak zárva, a kiszolgáló kilépési parancsot küld az ügyfélnek, és mindkét fél kilép.
Az sshd konfigurálható parancssori opciók vagy konfigurációs fájl segítségével. A parancssori beállítások felülbírálják a konfigurációs fájlban megadott értékeket.
Az sshd újraolvassa konfigurációs fájlját, amikor egy hangup jelet kap, a SIGHUP a nevével, amelyet elkezdett, azaz / usr / sbin / sshd
A lehetőségek a következők:
-b bitek
Meghatározza a bitek számát az ideiglenes protokoll 1 verziójú kiszolgáló kulcsban (alapértelmezett 768).
-d
Debug mód. A kiszolgáló kiterjedt hibakeresési kimenetet küld a rendszer naplójába, és nem kerül a háttérbe. A kiszolgáló nem fog működni, és csak egy kapcsolatot fog feldolgozni. Ez a beállítás csak a kiszolgáló hibakeresésére szolgál. A többszörös -d opciók növelik a hibakeresési szintet. Maximálisan 3.
-e
Ha ezt az opciót megadta, az sshd a rendszer naplózása helyett a szabványos hibára küldi a kimenetet.
-f configuration_file
Megadja a konfigurációs fájl nevét. Az alapértelmezett beállítás az / etc / ssh / sshd_config sshd nem indul el, ha nincs konfigurációs fájl.
-g login_grace_time
Az ügyfelek türelmi idejét hitelesítheti (alapértelmezett 120 másodperc). Ha az ügyfél nem hitelesíti a felhasználót ezen a sok másodpercen belül, a kiszolgáló megszakad és kilép. A nulla érték nulla határt jelez.
-h host_key_file
Megad egy fájlt, amelyről a gazda kulcsot olvassuk. Ezt az opciót akkor kell megadni, ha az sshd nem fut rootként (mivel a normál gazda kulcsfájlokat általában nem olvashatja bárki más, csak a root). Az alapértelmezett a / etc / ssh / ssh_host_key az 1. protokoll-verzióhoz és / etc / ssh / ssh_host_rsa_key és / etc / ssh / ssh_host_dsa_key a 2. protokoll-verzióhoz. A különböző protokollverziókhoz és a gazda kulcshoz algoritmusok.
-én
Meghatározza, hogy az sshd futtatása az inetd-ből történik. Az sshd általában nem fut az inetd-ből, mert a kiszolgáló kulcsot kell létrehoznia, mielőtt reagálni tud az ügyfélre, és ez tíz másodpercig tarthat. Az ügyfeleknek túl sokáig kellene várniuk, ha a kulcsot minden alkalommal regenerálják. Azonban az inetd sshd- t használó kis méretű kulcsok (pl. 512) lehetnek megvalósíthatók.
-k key_gen_time
Meghatározza, hogy az ideiglenes protokoll 1. verziójú kiszolgáló kulcs mennyire regenerálódott (alapértelmezett 3600 másodperc vagy egy óra). A kulcsa meglehetősen gyakran regenerálta a kulcsot, hogy a kulcsot sehol se tárolják, és körülbelül egy óra elteltével lehetetlen visszaállítani a kulcsot a lehallgatott kommunikáció visszafejtéséhez még akkor is, ha a gépet megrepedték vagy fizikailag lefoglalták. A nulla érték azt jelzi, hogy a kulcs soha nem regenerálódik.
-o opciót
Használható arra, hogy megadja a beállításokat a konfigurációs fájlban használt formátumban. Ez hasznos azon opciók megadásához, amelyekhez nincs külön parancssori zászló.
-p portot
Megadja azt a portot, amelyen a kiszolgáló figyeli a kapcsolatokat (alapértelmezett 22). Több port opció megengedett. A konfigurációs fájlban megadott portok figyelmen kívül maradnak, amikor egy parancssori port van megadva.
-q
Csendes mód. Semmi nem kerül a rendszer naplójába. Általában az egyes kapcsolatok kezdete, hitelesítése és befejezése naplózódik.
-t
Teszt üzemmódban. Csak ellenőrizze a konfigurációs fájl érvényességét és a kulcsok helyességét. Ez hasznos lehet az sshd megbízható frissítéséhez, mivel a konfigurációs beállítások változhatnak.
-u len
Ezzel az opcióval megadható a távoli gazdagépet tartalmazó utmp struktúrában lévő mező mérete. Ha a törölt állomásnév hosszabb, mint len, helyettük a pontozott decimális értéket fogja használni. Ez lehetővé teszi a nagyon hosszú gazdanevekkel rendelkező gazdagépeket, amelyek túlcsordulják ezt a mezőt, még mindig egyedileg azonosíthatók. A - u0 megadása azt jelenti, hogy csak pontozott decimális címeket kell elhelyezni az utmp fájlba. - u0 is használható arra, hogy megakadályozza az sshd DNS-kéréseket, hacsak nem szükséges a hitelesítési mechanizmus vagy konfiguráció. A DNS-t igénylő hitelesítési mechanizmusok közé tartoznak a RhostsAuthentication RhostsRSAAuthentication HostbasedAuthentication és a key file -ban a from = pattern-list opció használatával. A DNS-t igénylő konfigurációs beállítások tartalmazzák a USER @ HOST mintát az AllowUsers vagy DenyUsers elemekben
-D
Ha ezt az opciót megadja, az sshd nem lesz leválasztható, és nem lesz démon. Ez lehetővé teszi az sshd könnyű felügyeletét
-4
Az sshd csak az IPv4-címeket használja.
-6
Az sshd csak az IPv6-címeket használja.
Konfigurációs fájl
Az sshd az / etc / ssh / sshd_config konfigurációs adatait olvassa (vagy a parancssorban a - f paranccsal megadott fájlt). A fájlformátum és a konfigurációs beállítások leírása az sshd_config5.
Bejelentkezési folyamat
Amikor egy felhasználó sikeresen bejelentkezik, az sshd a következőket teszi:
- Ha a bejelentkezés tty-ban van, és nincs megadva parancs, az utolsó bejelentkezési időt nyomtatja ki és / etc / motd (kivéve ha a konfigurációs fájlban vagy a $ HOME / .hushlogin használatával megakadályozza az Sx FILES részeket).
- Ha a bejelentkezés tty-on van, regisztrálja a bejelentkezési időt.
- Ellenőrzi az / etc / nologin fájlt, ha létezik, kinyomtatja a tartalmat és kilép (hacsak nem gyökér).
- Változások a normál felhasználói jogosultságokkal való futtatáshoz.
- Felállítja az alapvető környezetet.
- Megteszi a $ HOME / .ssh / environment értéket, ha létezik, és a felhasználók megváltoztathatják környezetüket. Lásd a PermitUserEnvironment beállítást az sshd_config5-ben.
- A felhasználó főkönyvtárának módosításai.
- Ha $ HOME / .ssh / rc létezik, akkor futtatja; más, ha az / etc / ssh / sshrc létezik, futtatja; egyébként xauth fut. Az `` rc '' fájlok az X11 hitelesítési protokollt és a cookie-t a standard bemenetben kapják.
- Futtatja a felhasználó shelljét vagy parancsát.
Authorized_Keys fájlformátum
A $ HOME / .ssh / authorized_keys az alapértelmezett fájl, amely felsorolja azokat a nyilvános kulcsokat, amelyek az 1-es verzióban az RSA-hitelesítéshez és a nyilvános kulcsú hitelesítéshez (PubkeyAuthentication) engedélyezettek a 2. protokoll-verzióban. Az AuthorizedKeysFile használható egy alternatív fájl megadásához.
A fájl minden sora tartalmaz egy kulcsot (az üres sorokat és sorokat "#" -ként kezdõdõként figyelmen kívül hagyjuk). Minden egyes RSA nyilvános kulcs a következő mezőkből áll: szóközök: opciók, bitek, exponens, modulus, megjegyzés. Mindegyik protokoll 2-es verziójú nyilvános kulcs a következőkből áll: opciók, keytype, base64 kódolt kulcs, megjegyzés. Az opciók mező opcionális; annak jelenlétét határozza meg, hogy a vonal számmal kezdődik-e vagy sem (az opciómező soha nem kezdődik el egy számmal). A bitek, exponens, modulus és comment mezők megadják az RSA kulcsot az 1. protokoll-verzióhoz; a megjegyzésmezőt nem használják semmihez (de a felhasználó számára hasznos lehet a kulcs azonosítása). A 2. protokollverzióhoz a keytype `` ssh-dss '' vagy `` ssh-rsa ''
Vegye figyelembe, hogy ebben a fájlban lévő sorok általában több száz bájt hosszúságúak (a nyilvános kulcs kódolásának mérete miatt). Nem akarod beírni őket; ehelyett másolja az identity.pub id_dsa.pub vagy az id_rsa.pub fájlt, és módosítsa.
Az sshd egy minimális RSA kulcs modulusméretet alkalmaz az 1. protokollhoz és a 768 bites 2. protokoll kulcsokhoz.
Az opciók (ha vannak) vesszővel elválasztott opciós előírásokból állnak. Tilos a szóközök, kivéve a kettős idézeteket. A következő opciókat támogatják (vegye figyelembe, hogy az opciós kulcsszavak esetében nincs kis-és nagybetű):
a = minta-lista
Meghatározza, hogy a nyilvános kulcsú hitelesítésen kívül a távoli állomás kanonikus neve legyen a vesszővel elválasztott minták listájában ("*" és "?" Helyettesítő karakterként). A lista tartalmazhat olyan mintákat is, amelyeket a "!" ; ha a kanonikus gazdanév megegyezik egy negatív mintával, akkor a kulcs nem fogadható el. Ennek a lehetőségnek az a célja, hogy növelje a biztonságot: a nyilvános kulcsú hitelesítés önmagában nem bízik a hálózatban vagy a névszervereken vagy bármi másban (de a kulcs); Ha azonban valaki ellopja a kulcsot, a kulcs lehetővé teszi, hogy egy betolakodó bejusson a világ bármely pontjáról. Ez a kiegészítő lehetőség nehezebbé teszi a lopott kulcs használatát (a névkiszolgálók és / vagy az útválasztók csak a kulcs mellett vannak veszélyeztetve).
command = parancs
Megadja, hogy a parancs végrehajtásra kerül, ha ezt a kulcsot hitelesítésre használja. A felhasználó által adott parancs (ha van ilyen) figyelmen kívül marad. A parancs futtatható egy pty-n, ha az ügyfél kéri a pty-t; különben tty nélkül fut. Ha egy 8 bites tiszta csatorna szükséges, akkor nem kell kérnie a pty-t, vagy meg kell adnia a no-pty parancsot. Ez a beállítás hasznos lehet bizonyos nyilvános kulcsok korlátozására, hogy csak egy adott műveletet hajtson végre. Például lehet egy olyan kulcs, amely lehetővé teszi a távoli biztonsági másolatokat, de nem más. Vegye figyelembe, hogy az ügyfél TCP / IP és / vagy X11 továbbítást adhat meg, kivéve, ha kifejezetten tilos. Ne feledje, hogy ez az opció a shell, a parancs vagy az alrendszer végrehajtására vonatkozik.
környezet = NAME = érték
Megadja, hogy a karakterláncot a környezetbe kell adni, amikor bejelentkezik a kulcs használatával. A környezeti változók ezáltal felülbírálják az egyéb alapértelmezett környezeti értékeket. Többféle ilyen típusú opció megengedett. A környezeti feldolgozás alapértelmezés szerint le van tiltva, és a PermitUserEnvironment opcióval szabályozható. Ez a beállítás automatikusan letiltásra kerül, ha a UseLogin engedélyezve van.
no-kaputovábbítás
A TCP / IP továbbítást tiltja, ha ezt a kulcsot a hitelesítéshez használja. Az ügyféllel szembeni portra vonatkozó kérések hibát adnak vissza. Ezt például a parancs opciójával kapcsolatban lehet használni.
no-X11-továbbítás
Az X11 továbbítást tiltja, ha ezt a kulcsot a hitelesítéshez használja. Minden ügyfél által küldött X11 előretekintés hibát okoz.
no-agent-továbbítás
Az autentikációs ügynök továbbítását tiltja, ha ezt a kulcsot a hitelesítéshez használja.
no-PTY
Megakadályozza a tty kiosztást (a pty lefoglalására vonatkozó kérés sikertelen lesz).
permitopen = host: port
Határozza meg a helyi `` ssh -L '' port továbbítását, hogy csak a megadott gazdagéphez és porthoz tud csatlakozni. Az IPv6 címeket alternatív szintaxissal lehet megadni: host / port A többszörös allowopen opciókat vesszővel elválasztva lehet alkalmazni. A megadott gépneveken nincs minta-illesztés, hanem szó szerinti tartományoknak vagy címeknek kell lennie.
Példák
1024 33 12121 ... 312314325 ylo@foo.bar
"=" *. niksula.hut.fi,! pc.niksula.hut.fi "1024 35 23 ... 2334 ylo @ niksula
command = "dump / home", nincs-pty, nincs port-továbbítás 1024 33 23 ... 2323 backup.hut.fi
permitopen = "10.2.1.55:80", permitopen = "10.2.1.56:25" 1024 33 23 ... 2323
Ssh_Known_Hosts fájlformátum
Az / etc / ssh / ssh_known_hosts és a $ HOME / .ssh / known_hosts fájlok tartalmazzák az összes ismert állomás nyilvános kulcsát. A globális állományt a rendszergazda készítse el (opcionális), és a felhasználói fájl automatikusan karbantartható: minden egyes felhasználó ismeretlen állomástól való csatlakozásakor a kulcsot hozzáadja a felhasználói fájlhoz.
Az egyes fájlok sorai a következő mezőket tartalmazzák: gépnevek, bitek, exponens, modulus, megjegyzés. A mezőket szóközök választják el egymástól.
A hostnevek a vesszők vesszővel elválasztott listája ('*' és '?' Karakterek); mindegyik minta a kanonikus gazdanév ellen (kliens hitelesítésénél) vagy a felhasználó által megadott név ellen (egy kiszolgáló hitelesítése során) illeszkedik. A mintát előzheti a `! ' a negáció jelzésére: ha a gazdanév megegyezik egy negatív mintával, akkor nem fogadja el (abban a sorban) akkor is, ha a vonalon egy másik minta egyezik.
A biteket, exponenseket és modulusokat közvetlenül az RSA-host kulcsból veszik; Ezek például az /etc/ssh/ssh_host_key.pub címen érhetők el. Az opcionális megjegyzésmező folytatódik a vonal végére, és nem kerül felhasználásra.
A (z) "#" és az üres sorokkal kezdődő sorok figyelmen kívül maradnak.
Hoszt-hitelesítés végrehajtásakor a hitelesítés elfogadható, ha bármelyik vonalnak megfelelő kulcsa van. Ezért megengedett (de nem ajánlott), hogy több sor vagy különböző gazda kulcsok legyenek ugyanazon nevekhez. Ez elkerülhetetlenül bekövetkezik, ha a különböző tartományokból származó gazdagépnevek rövid formában kerülnek a fájlba. Lehetséges, hogy a fájlok egymásnak ellentmondó információkat tartalmaznak; a hitelesítés elfogadható, ha érvényes információ található valamelyik fájlból.
Ne feledje, hogy ezek a fájlok általában több száz karaktert tartalmaznak, és határozottan nem szeretné kézzel beírni a gazda kulcsokat. Inkább létrehozza őket egy parancsfájllal, vagy vegye be a /etc/ssh/ssh_host_key.pub fájlt, és adja hozzá a házigazda nevét.
Példák
closenet, ..., 130.233.208.41 1024 37 159 ... 93 closenet.hut.fi cvs.openbsd.org, 199.185.137.3 ssh-rsa AAAA1234 ..... =Lásd még
az ssh-add1, az ssh-agent1, az ssh-keygen1, a login.conf5, a modulok (5), az sshd_config5, az sftp-server8, az scp (1), az sftp (1)
T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "SSH protokoll architektúra" draft-ietf-secsh-architektúra-12.txt 2002. január folyamatban lévő anyag
M. Friedl N. Provos WA Simpson "Az SSH közlekedési réteg protokolljának Diffie-Hellman csoportcseréje " draft-ietf-secsh-dh-group-exchange-02.txt 2002. január folyamatban lévő anyag
Fontos: Az ember paranccsal ( % man ) tekintse meg, hogyan használják a parancsot az adott számítógépen.