SSH: Secure Shell

SSH je zkratka pro Secure Shell. Je také známý jako Secure Socket Shell. K bezpečnému provozu síťových služeb v nezabezpečených sítích se používá šifrovací síťový protokol zvaný Secure Shell (SSH). Architektura klientského serveru je základem aplikací SSH, které propojují instanci klienta SSH se serverem SSH.

Jako nástupce Telnetu a nebezpečných vzdálených unixových shellových protokolů, jako je Berkeley Remote Shell (rsh) a související protokoly rlogin a rexec, bylo SSH vytvořeno pro operační systémy podobné Unixu, které využívají nezabezpečenou komunikaci s autentizačními tokeny v prostém textu.

Definice

SSH můžeme použít několika různými způsoby. Nejjednodušší implementace šifruje data pomocí automaticky generovaných párů veřejného a soukromého klíče na obou koncích komunikačního kanálu a síťového připojení. Poté ověří uživatele pomocí hesla. Když uživatel ručně vygeneruje pár veřejného a soukromého klíče, autentizace je prakticky dokončena po vytvoření páru klíčů, což umožňuje okamžité spuštění relace bez výzvy k zadání hesla.

řádek příkazu autocad

V tomto případě vlastník uchovává odpovídající soukromý klíč v tajnosti a veřejný klíč je nainstalován na všech počítačích, které musí udělit přístup vlastníkovi. Přestože soukromý klíč slouží jako základ pro autentizaci, klíč se při provádění autentizace nikdy neposílá přes síť. SSH potvrzuje, že poskytovatel veřejného klíče také vlastní odpovídající soukromý klíč.

Propojení neznámého veřejného klíče se známým soukromým klíčem ve všech verzích SSH je zásadní, než je přijmete jako legitimní veřejné klíče s ID. Přijetím veřejného klíče od útočníka bez jeho ověření přijmete nedůvěryhodného útočníka jako legitimního uživatele.

Stvoření

Tatu Ylönen, počítačový vědec z Finska, vytvořil SSH poprvé v roce 1995. Další vývoj sady protokolů probíhal v mnoha vývojářských skupinách, což vedlo k různým iteracím implementace. K dispozici jsou implementace pro všechny populární operační systémy, včetně vestavěných systémů. OpenSSH, který tvůrci OpenBSD zpřístupnili jako open-source software v roce 1999, je nejčastěji používaným softwarovým balíkem.

Správa OpenSSH klíčů pro autentizaci

Schválený seznam veřejných klíčů je na unixových systémech běžně uchováván v souboru ~/.ssh/authorized keys v domovském adresáři uživatele, který má oprávnění pro vzdálené přihlášení. SSH respektuje tento soubor pouze v případě, že jej nemůže upravit nikdo jiný než vlastník a root. Heslo již není nutné, pokud je k dispozici veřejný klíč vzdáleného konce i odpovídající soukromý klíč místního konce. Můžeme však použít přístupovou frázi k uzamčení soukromého klíče pro mnohem větší ochranu. Můžeme také prohledávat tajný kód na běžných místech a můžeme použít volbu příkazového řádku k poskytnutí jeho úplné cesty (volba -i pro ssh).

SSH dále poskytuje automatickou autentizaci založenou na šifrovaném generování klíčů. Útočník se v tomto scénáři může vydávat za důvěryhodnou stranu serveru, vyžádat si heslo a získat ho (útok typu man-in-the-middle). Na straně serveru můžeme vypnout ověřování heslem.

Použití

SSH používá paradigma klient-server. Pro protokolování se obvykle používá SSH. Může také tunelovat TCP porty, předávat X11 spojení a provádět příkazy na vzdáleném systému. Připojení k démonu SSH umožňujícímu vzdálená připojení se obvykle provádí pomocí klientské aplikace SSH. Oba se často vyskytují na většině současných operačních systémů, jako jsou macOS, distribuce Linuxu, OpenBSD, FreeBSD, NetBSD, Solaris a OpenVMS. Některé verze jsou proprietární, freeware a open source s různou mírou složitosti a komplexnosti (jako je PuTTY a verze OpenSSH, která je součástí Cygwin a OpenSSH). Je pozoruhodné, že SSH není ve výchozím nastavení zahrnuto ve verzích Windows až do Windows 10 verze 1709.

Podobnou funkcionalitu správy souborů (synchronizaci, kopírování a vzdálené mazání) nabízí bezplatná a open-source aplikace pro Windows WinSCP, která jako back-end používá PuTTY. Bez nutnosti instalace na klientský počítač jsou WinSCP a PuTTY k dispozici zabalené pro provoz přímo z USB disku. Povolení funkce v aplikaci nastavení je často nutné k nastavení serveru SSH ve Windows.

Aby bylo možné zvládnout problémy s připojením a zabránit bezpečnostním rizikům přímého vystavení cloudového virtuálního stroje internetu, je SSH v cloud computingu zásadní. Bezpečné připojení přes internet může být umožněno prostřednictvím virtuálního počítače s tunelem SSH přes firewall. Pro tento protokol určila IANA port TCP 22, UDP port 22 a SCTP port 22.

Již v roce 2001 IANA klasifikovala výchozí port TCP 22 pro servery SSH jako jeden ze známých portů. Protokol transportní vrstvy SCTP orientovaný na spojení lze použít ke spuštění SSH namísto TCP.

faktoriál v c

Historický vývoj

Iterace 1

Útok odhalující heslo na síť jeho instituce inspiroval Tatu Ylönena, výzkumníka z Helsinské technologické univerzity ve Finsku, v roce 1995 vytvořil první iteraci protokolu (dnes známý jako SSH-1).

SSH byl navržen tak, aby převzal roli předchozích protokolů, včetně rlogin, TELNET, FTP a rsh, které postrádaly robustní autentizaci a záruky utajení. Ylönen zpřístupnil svou aplikaci jako freeware. V červenci 1995 se zařízení rychle stalo oblíbeným. Do konce roku 1995 bylo 20 000 uživatelů SSH v 50 různých zemích.

Pro podporu a rozvoj SSH založil Ylönen v prosinci 1995 SSH Communications Security. V prvním vydání programu SSH byly použity různé součásti svobodného softwaru, včetně GNU libgmp, ale pozdější iterace poskytované SSH Communications Security se rozrostly ve stále více proprietární software. Podle odhadů byly do roku 2000 2 miliony uživatelů.

Iterace 2

Skupina Internet Engineering Task Force (IETF) označila ve své oficiální dokumentaci pracovní skupinu odpovědnou za vytvoření protokolu SSH verze 2 jako „Secsh“.

SSH-2, vylepšená iterace protokolu, se stal standardem v roce 2006. SSH-1 není kompatibilní s touto verzí. SSH-2 nabízí upgrady funkčnosti a zabezpečení oproti SSH-1. Například výměna klíčů Diffie-Hellman a robustní ověřování integrity prostřednictvím autentizačních kódů zpráv poskytují vyšší bezpečnost. Schopnost provozovat neomezený počet relací shellu přes jediné připojení SSH je jednou z nových schopností SSH-2. Protože SSH-2 je pokročilejší a široce používaný než SSH-1, některé implementace, jako je libssh (v0.8.0+), Lsh a Dropbear, podporují pouze SSH-2.

Iterace 1,99

RFC 4253 vyžaduje, aby server SSH podporující 2.0, stejně jako dřívější verze, označoval svou verzi protokolu jako 1.99 v lednu 2006, tedy dlouho po vyvinutí verze 2.1. Toto číslo verze se používá spíše k označení zpětné kompatibility než k vyjádření předchozí revize softwaru.

OSSH a OpenSSH

Od poslední verze původního programu SSH, verze 1.2.12, byla distribuována pod open-source licencí v roce 1999, vývojáři pracovali na verzi svobodného softwaru. To bylo použito jako základ pro program OSSH Björna Grönvalla. Brzy poté tým OpenBSD naklonoval Grönvallovu práci, aby vytvořil OpenSSH, které bylo součástí OpenBSD Release 2.6. Z této verze vytvořili větev „přenositelnosti“ pro přenos OpenSSH do různých operačních systémů.

Nejrozšířenější implementací SSH od roku 2005 byl OpenSSH, výchozí verze v mnoha distribucích operačního systému. Po odstranění podpory SSH-1 z kódové základny ve verzi OpenSSH 7.6 se OpenSSH stále aktualizuje a podporuje protokol SSH-2. Mezitím OSSH již není relevantní.

Použití

Uživatel 'josh' 'SSHed' z místního počítače 'foo fighter' na vzdálený stroj 'tengwar', aby spustil xeyes jako příklad tunelování programu X11 přes SSH. Lidé využívají Windows SSH klienta PuTTY pro přístup k OpenWrt.

SSH je protokol, který funguje s mnoha systémy, včetně Microsoft Windows a většinou unixových variant (Linux, BSD, včetně macOS od Apple a Solaris). Následující aplikace mohou vyžadovat funkce, které jsou exkluzivní nebo kompatibilní s konkrétními klienty nebo servery SSH. V současné době je například možné použít pouze implementaci protokolu SSH OpenSSH serveru a klienta ke konstrukci VPN.

• Přístup k shellu na vzdáleném hostiteli (nahrazení Telnetu a rlogin)
• Pro provedení osamoceného příkazu na vzdáleném hostiteli (nahrazení rsh)
• Pro konfiguraci automatického přihlášení (bez hesla) vzdáleného serveru (například pomocí OpenSSH)
• Jako plně funkční šifrovaná VPN mějte na paměti, že tuto schopnost podporuje pouze klient a server OpenSSH.
• Pro přenos X ze vzdáleného hostitele (možné prostřednictvím více mezilehlých hostitelů)
• Pro použití klientů SSH, kteří podporují protokol SOCKS, k procházení internetu přes šifrované připojení proxy.
• Pro bezpečné připojení adresáře vzdáleného serveru jako souborového systému na místní počítač využívající SSHFS.
• Prostřednictvím jedné nebo více z výše uvedených technologií pro automatické vzdálené monitorování a správu serverů.
• Pro vývoj mobilních nebo vestavěných zařízení kompatibilní s SSH.
• K ochraně mechanismů přenosu souborů.

Metody přenosu souborů

Několik systémů pro přenos souborů využívá protokoly Secure Shell, jako např

• Přes SSH je Secure Copy (SCP) vyvinuta z protokolu RCP.
• rsync, který má být efektivnější než SCP, je často provozován přes SSH připojení.
• Alternativou k FTP, která je bezpečná, je SSH File Transfer Protocol (SFTP) (nezaměňovat s FTP přes SSH nebo FTPS)
• FISH, neboli soubory přenášené přes protokol shellu, byl představen v roce 1998 a vyvinut z instrukcí SSH přes unixový shell.
• Aspera, také známý jako Fast and Secure Protocol (FASP), využívá SSH pro příkazy a přenos dat, UDP porty.

Architektura

Tři různé komponenty tvoří vrstvenou architekturu protokolu SSH:

• Transmission Control Protocol (TCP) TCP/IP je běžně používán transportní vrstvou (RFC 4253), přičemž port číslo 22 je vyhrazen jako naslouchací port serveru. Tato vrstva implementuje šifrování, kompresi, kontrolu integrity, počáteční výměnu klíčů a autentizaci serveru. Ačkoli každá implementace může umožňovat více, vystavuje vyšší vrstvě rozhraní pro vysílání a přijímání paketů otevřeného textu, každý o velikosti až 32 768 bajtů. Obvykle po přenesení 1 GB dat nebo po uplynutí jedné hodiny, podle toho, co nastane dříve, zařídí transportní vrstva opětovnou výměnu klíčů.
  
• Autentizace klienta je řešena prostřednictvím autentizační vrstvy uživatele (RFC 4252), která také nabízí několik autentizačních technik. Klientem řízená autentizace znamená, že klient SSH, nikoli server, může požádat uživatele o heslo. Ze serveru obdrží odpověď pouze požadavky klienta na ověření. Často se používají následující techniky ověřování uživatelů:
  Heslo, jednoduchá technika ověřování hesla, která zahrnuje možnost změnit heslo. Ne každý software tuto techniku ​​používá.
• Obvykle podporují alespoň páry klíčů DSA, ECDSA nebo RSA veřejný klíč je technika pro ověřování na základě veřejného klíče. Jiné implementace navíc přijímají certifikáty X.509.
Klávesnice-interaktivní(RFC 4256) je flexibilní technika, ve které server poskytuje jednu nebo více výzev k zadání informací, klient je zobrazí a poté odešle zpět odpovědi, které klient zadal. Používá se v některých nastaveních OpenSSH k efektivnímu nabízení ověřování heslem při PAM je základním poskytovatelem autentizace hostitele, který může příležitostně bránit přihlášení s klientem, který podporuje pouze techniku ​​jednoduchého ověřování heslem.
• Funkce jednotného přihlášení pro relace SSH je poskytována prostřednictvím GSSAPI autentizační techniky, které nabízejí rozšiřitelný systém pro zpracování autentizace SSH pomocí externích mechanismů, jako je Kerberos 5 nebo NTLM. Ačkoli OpenSSH má funkční implementaci GSSAPI, komerční implementace SSH často integrují tyto techniky pro použití ve společnostech.
• Myšlenka kanálů, které definují nabízené služby SSH, je definována spojovací vrstvou (RFC 4254). Můžeme multiplexovat více SSH připojení z jednoho. Oba přenášejí data v obou směrech. Kanálové požadavky přenášejí mimopásmová data konkrétní danému kanálu, jako je výstupní kód procesu na straně serveru nebo změna velikosti okna terminálu. Navíc pomocí velikosti přijímacího okna řídí každý kanál svůj tok. Klient SSH provede globální požadavek na předání portu na straně serveru. Mezi běžné typy kanálů patří:
  • Shell pro SFTP, exec a terminálové shelly (včetně převodů SCP)
  • Direct-TCPIP pro předávaná připojení z klienta na server.
  • Přesměrovaná spojení server-klient pomocí forwarded-tcpip
  • Pro potvrzení legitimity hostitele nabízí záznam DNS SSHFP (RFC 4255) otisky veřejného klíče hostitele.

Díky jeho otevřenému designu můžeme kromě zabezpečení shellů používat SSH pro širokou škálu úkolů, což mu dává velkou všestrannost.

Zranitelnosti

SSH-1

Kvůli nedostatečné ochraně integrity dat poskytované CRC-32 v této verzi protokolu byla v roce 1998 identifikována zranitelnost v SSH 1.5, která umožňovala neoprávněné vkládání materiálu do šifrovaného streamu SSH. Ve většině implementací přidali opravu známou jako SSH Compensation Attack Detector. Několik z těchto revidovaných implementací zahrnovalo novou chybu přetečení celého čísla, která útočníkům umožnila spouštět libovolný kód pomocí root nebo schopností démona SSH.

Chyba, která útočníkům umožňuje změnit poslední blok relace šifrované IDEA, byla nalezena v lednu 2001. Ve stejném měsíci byla nalezena další chyba, která umožnila podvodnému serveru předat přihlášení klienta jinému serveru.

Kvůli svým přirozeným zranitelnostem je SSH-1 obecně považován za zastaralý a je třeba se mu vyhnout výslovným odstraněním záložního SSH-1. Většina současných serverů a klientů podporuje SSH-2.

inurl:.git/head

Obnova prostého textu pro CBC

V listopadu 2008 byla ve všech verzích SSH objevena teoretická zranitelnost, která umožňovala získat až 32 bitů prostého textu z bloku šifrovaného textu zašifrovaného dobovou standardní šifrovací metodou CBC. Nejjednodušší opravou je přejít na CTR, čítač režim namísto režimu CBC, díky kterému je SSH imunní vůči útoku.

NSA podezřelá z dešifrování

Uvolnění citlivých dokumentů Edwardem Snowdenem pro Der Spiegel 28. prosince 2014 naznačuje, že Národní bezpečnostní agentura bude schopna potenciálně dekódovat určitou SSH komunikaci.