SSH pro správce
SSH lze z pohledu administrátora chápat jako šifrovaný tunel mezi dvěma počítači na bázi klient/server. Přes něj můžeme přistupovat k shellu vzdáleného počítače, ale také kopírovat soubory, spouštět vzdáleně Xkové aplikace, vytvářet roury z místního počítače na vzdálený či vytvářet šifrované tunely pro vzdálený přístup k nějaké službě, která je za firewallem. Prostřednictvím sshfs je dokonce možné připojit vzdálený souborový systém přes FUSE na místní adresář.
Přehled možností SSH
Jelikož základy SSH včetně spektra jeho možností probral již miniseriál Michala Vyskočila s názvem SSH receptem na bezpečnost - první díl, druhý díl, nebudu se o možnostech SSH příliš rozepisovat, dovolím si pouze v rychlosti projít možnosti SSH s jednoduchými příklady:
Přihlášení se ke vzdálenému shellu (všimněte si parametru -p, který umožňuje zvolit jiný než standardní port 22 na cílovém serveru):
ssh -p cislo_portu uzivatel@server
Pro provedení jediného příkazu nepotřebujete přístup na vzdálený shell, příkaz můžete volat přímo. Příkladem může být získání výpisu obsazeného místa na připojených souborových systémech na serveru, který má SSH server na nestandardním portu, a sice 8022:
ssh -p 8022 uzivatel@server "df -h"
Prostřednictvím SSH můžete vytvořit rouru začínající na jednom počítači a končící na jiném:
mistni_program | ssh -p cislo_portu uzivatel@server 'cat > vdaleny_soubor.dat'
Výše zmíněný příkaz pošle výstup místního programu přes SSH tunel vzdálenému programu cat, který data uloží do souboru. Použít můžete samozřejmě kterýkoliv program schopný přijímat data ze standardního vstupu. Tímhle způsobem se dají snadno provádět rychlé zálohy:
tar cf - /adresar | xz | ssh uzivatel@server "dd of=zaloha.tar.xz"
Dají se tak také zálohovat celé diskové oddíly:
dd if=/dev/disk | xz | ssh uzivatel@server "dd of=zaloha_disk.img.xz"
Dodávám, že toto se hodí výlučně v případě okamžité potřeby, na pravidelné zálohování máme jiné nástroje. Stejně tak je jasné, že zálohování tohoto rázu by se nemělo provádět na systému s běžícími službami.
SSH dokáže také vytvářet šifrované tunely pro TCP/IP komunikaci. Je tedy možné si na port místního počítače namapovat vzdálenou službu, která je třeba za firewallem, jako v případě vzdálené PostgreSQL databáze v tomto příkladu:
ssh -p ssh_port_firewallu -N -f uzivatel@firewall -L 5000:server:5432
V tomto případě se asi hodí menší komentář - SSH vytvoří šifrovaný tunel mezi místním počítačem a firewallem, který provozuje SSH server na portu ssh_port_firewallu. Tento tunel bude směřovat na port 5432 počítače s názvem server. Tento vzdálený port pak bude k dispozici jako služba běžící na portu 5000 místního počítače. Tudíž, pokud se po provedení tohoto příkazu spojím s portem 5000 na místním počítači, požadavek se přenese šifrovaným tunelem na firewall, a ten pak požadavek předá (pozor, již nešifrovaně!) serveru, jehož odpověď pak pošle zpět. Parametr -N signalizuje, že se nebude na serveru spouštět žádný příkaz, jen se vytvoří tunel. Parametr -f zařídí, že se tunel po přihlášení vytvoří na pozadí.
Pokud by byl server přístupný přímo, a PostgreSQL na něm běžel jako místní služba (tj. na localhostu), postačil by následující příkaz:
ssh -N -f uzivatel@server -L 5000:127.0.0.1:5432
SSH umí vytvářet i "reverzní" tunely, pomocí kterých můžete naopak zpřístupnit místní službu na vzdáleném počítači:
ssh -N -f uzivatel@server -R 5000:localhost:22
Tento příkaz vytvoří šifrovaný tunel mezi vaším počítačem a serverem, který zpřístupní váš místní port 22 (kde obvykle běží SSH) klientům serveru na portu 5000. Tudíž, pokud se nějaký klient spojí s portem 5000 na serveru, bude přes tunel přistupovat k vašemu místnímu portu 22.
Přes SSH je možné pouštět i aplikace využívající grafického rozhraní, je-li to na serveru povoleno (volba X11Forwarding). Pro každý vzdálený server si můžete vytvořit specifickou konfiguraci v souboru .ssh/config ve svém domovském adresáři, kde můžete specifikovat i konkrétní SSH klíč, který se má k přístupu k serveru použít. Pro správu serverů přes nespolehlivé spojení se vám může hodit program screen, o kterém se dozvíte vše potřebné v tomto článku.
sshfs
Sshfs je FUSE modul, který umožňuje připojovat vzdálené souborové systémy prostřednictvím SSH/SCP:
sshfs uzivatel@server:/cesta /kam/pripojit
Souborový systém sshfs má celou řadu konfiguračních voleb, které se dozvíte z manuálové stránky. Já si dovolím upozornit na jednu věc, se kterou jsem se setkal, a sice problém s připojením Git repozitáře přes sshfs. Pokud se provede připojení s výchozím nastavením, Git odmítá poslušnost. Tento problém lze vyřešit následující volbou:
sshfs -o workaround=rename uzivatel@server:/cesta /kam/pripojit
Na tomto příkladu je patrné, že sshfs není úplně bezproblémová záležitost a neměl by být brán jako ekvivalent lokálně připojeného souborového systému.
fish
V KDE aplikacích je možné využít pro přístup k vzdálenému souborovému systému protokol "fish", který umí pohodlně připojit vzdálený souborový systém přes SSH, a to prostřednictvím URL ve tvaru fish://uzivatel@server.
SSH servery
Nejznámějším SSH serverem je OpenSSH, vyvinut původně jako součást unixového operačního systému OpenBSD. Tento nástroj převzaly díky jeho licenci prakticky všechny linuxové distribuce. OpenSSH ale není jediným SSH serverem, těch je dokonce celá řada. Kromě komerčních a proprietárních variant máme pro GNU/Linux k dispozici Dropbear, který vyniká především svou lehkostí, pro kterou se výborně hodí jak na embedded zařízení, tak třeba na virtuální servery s hodně omezenou pamětí (obvykle ty levnější tarify), kde vám ušetří nějaký kus paměti. Na ostatní SSH servery se můžete podívat sem. Dodávám, že některé funkce SSH, které jsem tu popsal, nemusí být k dispozici ve všech SSH serverech.
SSH klienti
SSH klientů je také celá řada. Kromě klasického ssh klienta z balíku OpenSSH vás upozorním na grafického klienta Putty, který je velmi známý zejména v prostředí MS Windows. Umí toho celou řadu a nehodí se ani zdaleka jenom k přihlašování přes SSH. Podpora SSH klíčů je samozřejmostí, i když klíče je třeba před použitím konvertovat (Putty nepodporuje klasické klíče generované v rámci OpenSSH, tedy ne přímo). Putty funguje dokonce i nativně v Linuxu, i když v Linuxu nám stačí emulátor terminálu a řádkový klient. Něco málo o klíčích v Putty se dozvíte zde.
Pro kopírování souborů (scp/sftp) je možné použít řádkového klienta scp, výše zmíněného "protokolu" fish v KDE aplikacích nebo sshfs. V prostředí MS Windows lze použít grafický nástroj WinSCP, který se podobá klasickému dvoupanelovému diskovému manažeru.
SSH klíče
Toto téma je z teoretického i praktického hlediska rozebráno v tomto článku, já si dovolím toto téma v rychlosti prolétnout a připravit pro vás opět menší kuchařku.
SSH klíče fungují na bázi asymetrického šifrování, podobně jako GnuPG a jiné aplikace. Vygenerujete si pár klíčů, jeden soukromý (chráněný heslem, obvykle $HOME/.ssh/id_rsa) a jeden veřejný (obvykle $HOME/.ssh/id_rsa.pub). Veřejný klíč nahrajete do souboru .ssh/authorized_keys v domovském adresáři vzdáleného uživatelského účtu, a poté se můžete na server hlásit pomocí svého soukromého SSH klíče. Soukromý klíč není nutné chránit heslem, avšak pak je jasné, že případné zcizení souboru s klíčem může útočník přistupovat ke všem účtům na serverech, kde je umístěn veřejný klíč v authorized_keys. Chránění soukromého klíče heslem je proto vhodné bezpečnostní opatření.
Vygenerování páru klíčů provedete příkazem:
ssh-keygen
Po vygenerování páru klíčů máte svůj soukromý klíč k dispozici v .ssh/id_rsa (pokud jste se nerozhodli jej vygenerovat jinam) - tento klíč byste měli střežit jako oko v hlavě. Naopak veřejný klíč, který máte k dispozici v .ssh/id_rsa.pub, můžete nahrávat do souboru .ssh/authorized_keys uživatelských účtů na vzdálených serverech, kam se chcete přihlašovat:
scp $HOME/.ssh/id_rsa.pub uzivatel@server: ssh uzivatel@server uzivatel@server$ mkdir .ssh uzivatel@server$ cat id_rsa.pub >> .ssh/authorized_keys
V authorized_keys může být veřejných klíčů více, proto je vhodné používat přesměrování vstupu v režimu append (dvě většítka za sebou). Klíč lze pak "revokovat" prostým výmazem odpovídajícího řádku v tomto souboru.
Pokud máte více soukromých klíčů na různé servery, můžete buď využít ssh agent popsaný dále, nebo jednoznačně specifikovat soukromý klíč, který chcete použít při připojení k serveru (výchozí je ~/.ssh/id_rsa):
ssh -i .ssh/soukromy_klic uzivatel@server
SSH Agent a Keychain
Pokud se přihlašujete na servery přes SSH často, popřípadě chcete své klíče chránit heslem, ale současně nechcete být obtěžováni neustálým zadáváním hesla k danému klíči, můžete využít nástroj ssh-agent, který si jedno nebo více hesel ke klíčům zapamatuje, a pak už se vás ssh klient na hesla ptát nebude. Více informací o ssh-agentovi se dozvíte v tomto článku.
Já si dovolím doplnit informaci o nástroji keychain, který vám může usnadnit práci se ssh-agentem. V jeho případě postačí do .bashrc přidat následující dva řádky:
/usr/bin/keychain $HOME/.ssh/id_rsa source $HOME/.keychain/$HOSTNAME-sh
Tím si zajistíte, že si Keychain vyžádá hesla ke klíčům, o které se má starat, a podle potřeby spustí ssh-agenta nebo jej pouze přidá do proměnných prostředí, pokud už běží. To vše provede po spuštění shellu. Každá další instance shellu (třeba v rámci virtuálního terminálu) se pak připojí k už spuštěnému ssh-agentovi, bez nutnosti opět zadávat heslo. Keychain má řadu voleb, které můžete využít. Já používám tyto (potlačují zbytečné výpisy a ignorují proměnnou SSH_ASKPASS):
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_rsa
Závěr
SSH je velmi mocný nástroj, který umí mnohé. Proto je vhodné vnímat SSH z pohledu správce nikoliv jako nástroj pro vzdálenou práci se shellem, ale jako komplexní nástroj umožňující vytvářet šifrované, zabezpečené tunely mezi dvěma nebo více počítači, a posílat přes ně nejrůznější data a přistupovat k nejrůznějším službám. SSH je samozřejmě pouze nástroj, jehož faktická bezpečnost záleží na správcích i uživatelích. V příštím díle se podívám právě na bezpečnost SSH, zejména pak z pohledu správců serverů.
