SSH klient v príkladoch

3.5.2021 22:37 | Přečteno: 3023× | GNU/Linux |

Kto chvíľku pracoval na viac než jednom *nix-ovom systéme, určite sa stretol s programom ssh, ktorý sprístupňuje shell konzolu vzdialeného počítača. Okrem elementárneho použitia spôsobom ssh prihlasovacie_meno@server ponúka ssh množstvo ďalších užitočných vlastností. Tento článok chce ukázať niektoré z nich.

Pre účely nižšie uvádzaných príkladov použijeme model siete podľa nasledujúceho obrázku:

Legenda:
PC0 je klient, počítač za ktorým používateľ fyzicky sedí; všetky príkazy v príkladoch sú zadávané na stroji PC0, pokiaľ nie je uvedené inak
PC1..PC5 sú počítače, ktorých služby chce používateľ využiť, služby dostupné cez sieť (otvorené sieťové porty) sú vymenované za označením PC
šípky predstavujú priamu sieťovú viditeľnosť (z PC0 je priamo dostupné ssh na PC2, ale PC0 nevidí ani PC3, ani PC4)
userN a pod. sú prihlasovacie mená (účty), adresy atď vzťahujúce sa na príslušné PC

PC0 môže byť domáce PC, PC1 nejaký vhodný (má pevnú verejnú IP adresu) stroj na internete, PC2..PC5 môže byť firemná sieť za firewallom/NAT, z ktorej je na pevnej verejnej IP adrese viditeľný iba ssh port PC2.

Kľúč je kľúčový!!!

Ssh umožňuje preukázať totožnosť prihlasujúceho sa používateľa rôznymi spôsobmi, typicky sú to heslo a privátny kľúč. Prihlasovanie heslom má jedinú výhodu v tom, že je jednoduché. K nevýhodám patrí prinajmenšom riziko slabých hesiel a tým možnosť útoku na server a komplikácia pri skriptovaní*. Správca servera by mal prihlasovanie heslom zakázať ako jednu z prvých vecí pri konfigurovaní nového servera.

*) dá sa obísť cez sshpass

Ako získať ssh kľúč

Kľúč si musí nechať vygenerovať každý používateľ sám za seba. Príkaz je

    ssh-keygen -t rsa -C "<Meno> rsa-sha2-512 <dátum generovania>"
    ssh-keygen -t ed25519 -C "<Meno> ed25519 <dátum generovania>"

RSA kľúč má lepšiu kompatibilitu smerom ku starším systémom, ale kombinácia so SHA-1 (čiže ssh-keygen -t ssh-rsa) sa už dnes nepovažuje za bezpečnú. Kľúč na báze eliptickej krivky 25519 je dnes asi najbezpečnejšia voľba (ale napr. starý CentOS 6 ju nepozná). Vygenerovaný kľúč je rozumné chrániť heslom, ssh-keygen vyzve na jeho zadanie.
Je vhodné zadávať pri generovaní kľúča komentár, z ktorého bude jasné, koho alebo čoho sa kľúč týka, aký je to kľúč a aký je starý.

V adresári ~/.ssh/ vznikne vždy dvojica súborov, pokiaľ si používateľ nezvolí vlastné meno súboru, sú to

    id_rsa
    id_rsa.pub

resp.

    id_ed25519
    id_ed25519.pub

Súbory bez koncovky .pub obsahujú kompletný kľúč, vrátane privátnej časti, ktorá je potrebná pri autentifikácií a preto ich treba chrániť. Ak sa útočník dostane ku privátnemu kľúču a prekoná prípadné heslo, môže v plnom rozsahu používať identitu obete na všetkých strojoch, kde je kľúč použitý. Ak používateľ stratí súbor s privátnym kľúčom alebo zabudne heslo, stratí možnosť prihlasovať sa tým kľúčom.
Obsah súboru .pub (verejnú zložku kľúča) je potrebné dostať na server ako nový riadok do súboru authorized_keys (/home/userN/.ssh/authorized_keys). Ak ešte nie je zakázané prihlasovanie iným spôsobom, napr. heslom, môže to spraviť používateľ sám, ručne textovým editorom, alebo utilitou ssh-copy-id. V opačnom prípade musí riadok pridať správca servera.

Stále musím zadávať heslo?!

Aby nebolo nutné zadávať heslo ku ssh kľúču (resp. ku všetkým ssh kľúčom ~/.ssh/id_*) pri každom otváraní ssh spojenia, je rozumné spustiť program ssh-agent. Do vhodného skriptu, spúšťaného po prihlásení, napr. ~/.profile treba pridať riadky

    eval `ssh-agent`
    ssh-add

Odbočka do sveta Windows

Úlohu ssh-agent-a plní v balíčku PuTTY program PAGEANT.EXE. Aby identické kľúče, aké spravuje pageant, boli dostupné aj pre programy z prostredia Cygwin, treba použiť (napr. v .bash_profile) utilitu ssh-pageant

    if [ -z "$SSH_AUTH_SOCK" -a -x /usr/bin/ssh-pageant ]; then
        eval $(/usr/bin/ssh-pageant -q)
    fi

Utilitu ssh-pageant je vhodné ukončiť, keď už nie je potrebná, aby nezostávali v systéme bežať zbytočné procesy (riadky do .bash_logout):

    if [ -x /usr/bin/ssh-pageant -a ! -z "$SSH_PAGEANT_PID" ]; then
        eval $(/usr/bin/ssh-pageant -qk 2>/dev/null)
    fi

Čo ak služba sshd očakáva spojenia na neštandardnom porte?

Štandardne sshd "počúva" na port-e 22. Iné číslo portu je potrebné explicitne uviesť

    ssh -p port2 user2@PC2

Čo keď potrebujem pracovať s inou službou?

Možným riešením je otvorenie ssh tunela, ktorým sa vzdialený port danej služby sprístupní ako lokálny port na našom počítači.

    ssh -L lokálna_adresa:lokálny_port_služby:PC3:port_služby user2@PC2

Voľba -L sa može v príkaze opakovať a môže sprístupňovať služby/porty z rôznych počítačov. Kombinácia lokálna_adresa:lokálny_port musí byť unikátna a musí sa jednať o neobsadený port.

    ssh -L 127.2.0.1:5900:PC2:5900 -L 127.3.0.1:5900:PC3:5900 -L 127.3.0.1:4080:PC3:80 user2@PC2

sprístupní službu VNC z PC2 na adrese 127.2.0.1:5900, službu VNC z PC3 na adrese 127.3.0.1:5900 a službu HTTP z PC3 na adrese 127.3.0.1:4080.

Odbočka do sveta Windows: homeoffice

Situácia: Vo firemnej LAN je zapnutý Windows počítač (PC3, PC4). Pracovník má doma svoj Windows počítač (PC0), z ktorého by mohol pracovať. LAN samozrejme nie je priamo prístupná z internetu a firemný správca nemôže natoľko dôverovať domácemu počítaču, aby ho pripojil do LAN cez VPN. Je však k dispozícii server (PC2), ktorý má ssh viditeľné z internetu a súčasne server vidí do LAN.
Príprava: Na PC3 a PC4 povoliť RDP a povoliť používateľovi prihlasovanie cez RDP.
Na PC2 vytvoriť účet pre použivateľa (user2) ako portforward-only, zapísať jeho kľúč do authorized_keys.
Na PC0 nainštalovať PuTTY, pripraviť skripty, vytvoriť rdp súbory.

Skript Pripoj_LAN.cmd. Jedno ssh spojenie dokáže obslúžiť viaceré porty. PuTTY sa predpokladá v C:\bin\putty\.

    @echo off
    TITLE %0 %1 %2
    @set srv=PC2
    set LOGIN=user2
    if not %1_ == _ set LOGIN=%~1
    set LPORT=22
    if not %2_ == _ set LPORT=%~2

    copy /b c:\bin\putty\plink.exe "%TEMP%\Plink_for_LAN.exe"

    tasklist /FI "IMAGENAME eq PAGEANT.EXE" 2>nul: | find "PAGEANT.EXE" 2>nul: >nul:
    if not errorlevel 1 goto :PAGEANT_DONE
    if not exist C:\bin\putty\Pageant-start.cmd goto :PAGEANT_DONE
        call C:\bin\putty\Pageant-start.cmd
    :PAGEANT_DONE

    @echo.
    @echo on
    "%TEMP%\Plink_for_LAN.exe" -batch ^
      -L 127.3.0.1:53389:PC3:3389 ^
      -L 127.4.0.1:53389:PC4:3389 ^
      -P %LPORT% -N -2 -v %LOGIN%@%srv%

Súbory RDP_PC3.RDP a RDP_PC4.RDP: ako adresu, na ktorú sa má pripojiť Remote Desktop protokolom je potrebné uviesť 127.3.0.1:53389 a 127.4.0.1:53389.

Hlavný skript, Spusti_PC3_Remote_Desktop.cmd, ktorým bude používateľ spojenie štartovať (skript Spusti_PC4_Remote_Desktop.cmd sa bude líšiť len vo výpisoch a vo volaní iného RDP; v prípade zbierky skritpov, kde dochádza ku pripájaniu sa do rôznych lokalít (rôznych LAN), bude zmena ešte v manažmente procesu Plink_for_XY a vo volaní iného skriptu Pripoj_XY.cmd).

    @echo off
    @echo Start PC3 Remote Desktop
    set RP=%~dp0
    set RP=%RP:~0,-1%
    set PLINK_IMG=Plink_for_LAN.exe
    tasklist /FI "IMAGENAME eq %PLINK_IMG%" 2>nul: | find "%PLINK_IMG%" 2>nul: >nul:
    if not errorlevel 1 goto :CONNECTED
    start "Connect to LAN" "%RP%\Pripoj_LAN.cmd"
    @echo Waiting for connection to LAN
    :WAIT_CONNECT
        tasklist /FI "IMAGENAME eq %PLINK_IMG%" 2>nul: | find "%PLINK_IMG%" 2>nul: >nul:
    if errorlevel 1 goto :WAIT_CONNECT
    :CONNECTED

    @echo Starting
    ping 127.0.0.1 >nul:
    start "PC3 RDP" mstsc.exe "%RP%\RDP_PC3.RDP"

Použivateľ pokliká na Spusti_PC3_Remote_Desktop.cmd, zadá heslo ku svojmu SSH kľúču (iba prvý krát), po chvíľke sa mu objaví prihlasovací dialóg do RDC, po prihlásení normálne pracuje na svojom počítači v práci len pri tom používa domácu klávesnicu, myš a obrazovku.

Ako sa pripojiť na ssh na stroji v LAN?

Mohlo by sa zdať, že táto otázka je iba špeciálny prípad pre použitie tunela ssh -L, ako bolo popísané vyššie. Takýto prístup by bol ovšem veľmi nepraktický: najskôr cez ssh -L 127.3.0.1:53022:PC3:22 PC2 otvoriť tunel a potom v inom terminálovom okne robiť ssh -p 53022 127.3.0.1. Elegantnejšie riešenie je použiť sshd na PC2 ako proxy

    ssh -o 'ProxyCommand /usr/bin/ssh -W PC3:22 user2@PC2' user3@PC3

Ak sa jedná o PC "hlbšie" v sieti, napr. PC5, tak je šikovnejšie

    ssh -J user2@PC2,user3@PC3 user5@PC5

Čo keď potrebujem sprístupniť službu na stroji, kam server nevidí?

Stačí, ak ten stroj vidí server a je na ňom ssh. (Príklad: PC5 je domáci serverík niekde za skriňou, domáca sieť nemá verejnú adresu, ale je k dispozícii server (PC1), ktorý verejnú adresu má. Obrázok si predstavíme bez PC2.) Riešením môže byť reverzný ssh tunel, ktorý bude iniciovať PC5.

Príprava: Na PC1 je potrebné zabezpečiť nejaký voľný port, viditeľný z internetu. Na obrázku je to port 54321.
Na PC5 je potrebné zabezpečiť spustenie*

    ssh -R '*:54321:localhost:22' user1@PC1

a používateľ zo svojho počítača zadá

    ssh -p 54321 user5@PC1

a je pripojený na ssh na stroji PC5. Hoci spojenie sprostredkúva PC1, použivateľ sa prihlasuje ku účtu na PC5, preto user5!

*) Holé ssh -R samozrejme v praxi stačiť nebude: treba pravidelne spúšťaný skript (crontab), ktorý bude kontrolovať, či je reverzný tunel funkčný a v prípade potreby ho obnoví. SSH kľúč, uložený na PC5, ktorým sa bude skript prihlasovať na PC1 pri vytváraní tunela, musí byť pochopiteľne bez hesla.

Ako si ušetrím písanie na príkazovom riadku?

Voľby na príkazovom riadku pre pripájanie sa ku niektorým PC môžu zadávanie príkazu slušne skomplikovať. Navyše ich zadávanie sa opakuje. Jednu z ciest, ako si spríjemniť život, ponúka konfiguračný súbor ~/.ssh/config (/home/user0/.ssh/config). Kľúčové slovo Host uvádza nastavenia pre konkrétny server (alebo skupinu serverov, ak sa použijú divoké znaky *,?).

Príklad možného config súboru pre situáciu na obrázku

    Host PC1
    Hostname pc1server.example.com
    Port 22
    User user1
    
    Host PC2
    Hostname firewall.example.com
    User user2
    
    Host PC3
    Hostname pc3.lan
    ProxyJump user2@firewall.example.com
    User user3
    
    Host PC5cezLAN
    Hostname pc5.lan
    ProxyJump user2@firewall.example.com,user3@pc3.lan
    User user5
    
    Host PC5cezPC1
    Hostname pc1server.example.com
    Port 54321
    User user5

a príkazový riadok potom bude iba

    ssh PC3

Súbor ~/.ssh/config využije nielen samotný ssh klient, ale aj ďalšie programy: scp, rsync a pod. Takže

    rsync -az --delete PC3:projekt1/ ~/mirror_projekt1/

prenesie stav z /home/user3/projekt1/ na PC3 do /home/user0/mirror_projekt1/

    ssh PC5cezPC1 ls -l | grep -E ^- | wc -l

spočíta súbory (okrem skrytých) v /home/user5/ na PC5
atď.

Tento text pokrýva iba zlomok možností ssh. Viac informácií: man ssh a man ssh_config.

       

Obrázky

Komentáře

[Michal Kubeček]

…je rozumné spustiť program ssh-agent. Do vhodného skriptu, spúšťaného po prihlásení, napr. ~/.profile treba pridať riadky…

To ale jen pokud nepoužíváte desktopové prostředí, které vám ssh-agent spustí rovnou a příslušné proměnné zdědí všechno, co spustíte v rámci toho prostředí. Pokud ano, pak bych spíš doporučil podívat se na pam_ssh pro další zjednodušení.

Mimochodem, ne všude se také dá spolehnout na to, že emulátory terminálu v grafickém desktopu budou spouštět shell jako login shell, aby se načetl ~/.profile

[Vlado99]

Díky za tip, pam_ssh som zatiaľ nepoužil.

Jediný stroj, kde momentálne používam linuxový desktop, je KUbuntu a ak mi pamäť dobre slúži, aj tam som pridával ssh-agent do ~/.profile.

[Jendа]

ssh -R s posloucháním jinde než na localhostu většinou bývá defaultně zakázané, je potřeba nastavit GatewayPorts clientspecified v konfiguraci SSH serveru.

treba pravidelne spúšťaný skript (crontab), ktorý bude kontrolovať, či je reverzný tunel funkčný a v prípade potreby ho obnoví

Tohle mi fungovalo tak strašně blbě (například se stane, že jedna strana zůstane viset, to blokuje port na serveru, a nový forward tiše selže; trochu pomůže ssh -o "ExitOnForwardFailure yes" -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"), že všude kde to není úplně adhoc spojení dávám OpenVPN.

[Vlado99]

Debian má GatewayPorts yes, takže toto som nepotreboval riešiť.

Skript na obsluhu reverzného tunela možno pridám dodatočne, musím ho trochu zovšeobecniť.

[kvr]

Hezky, ProxyCommand znám, ale o -J jsem nevěděl.

V souvislosti s port forwarding je ještě dobré zmínit -N (nepouští žádný příkaz, jenom forwarduje porty) a -f (pustí se na pozadí).

Ještě doplnění ohledně kopírování (pokud nebude v pokračování) - docela osvědčená (oproti rsync) kombinace je:

ssh já@remote 'cd /whatever && tar fcv - --exclude whatever .' | ( cd localdir && tar fxv - )

[Michal Kubeček]

Hint: tar má také option -C

[kvr]

Pěkné, další nová věc

[Vlado99]

Použitie tar záleží od okolností. Ak je dát veľa, a potrebujem preniesť iba zmeny, ktorých je zopár, je rsync neprekonateľný!

Inak pri skriptovaní zložitejších vecí pozor na to, že na strane sshd sa string parsuje ešte raz! Takže

whatever1='projekt1_$platby'
ssh já@remote "cd $whatever1 ..."

dostane sshd ako

cd projekt1_$platby ...

a keďže premenná $platby je (takmer určite) nedefinovaná, výsledkom bude

cd projekt1_ ...

Samozrejme konkrétny prípad sa dá konkrétne riešiť, ale ak programátor nemá kontrolu nad tým, aké dáta dostáva na vstupe (ja som sa stretol so súbormi, kde sa v mene bežne objavovali $, ', "), tak je to oriešok. Túto vlastnosť má nielen ssh, ale aj scp a rsync.

[Jendа]

set -u

[pavele]

Připojení na vzdálenou plochu přes prostředníka:

ssh -A -L 5909:localhost:5909 -c blowfish-cbc karel@192.168.0.17 -o 'ProxyCommand = ssh -L 5909:localhost:5909 root@ip-prostředníka -p port-prostředníka -W 192.168.0.17:22' "x11vnc -autoport 5909 -noxrecord -noxfixes -noxdamage -nomodtweak -xkb -display :0 -localhost"

sshfs přes prostředníka:

sshfs -o reconnect,ConnectTimeout=20,allow_other -o 'ProxyCommand=ssh -W %h:%p root@ip-prostředníka -p port-prostředníka' karel@192.168.0.17:/home/karel /home/adam/pripojnybod

rsync přes prostředníka:

rsync -P -av --append-verify -e 'ssh -T -c arcfour -o "ProxyCommand=ssh -c aes128-cbc -T -W %h:%p root@ip-prostředníka -p port-prostředníka"' /home/adam/Plocha/diskgenius karel@192.168.0.17:/home/karel/Plocha/

[Vlado99]

set -u moc nepomôže, aj keby som ho vedel nejako injektovať do scp alebo do rsync volania.

Scenár: Používatelia nahrávajú súbory do primárneho úložiska. O platných súboroch sa vedie evidencia v SQL databáze. Potrebujem raz za čas balancovať obsadenosť úložísk, tj. preniesť súbory z primárneho na niektoré zo sekundárnych úložísk. U súborov, ktoré sa podarí úspešne skopírovať, musím poznačiť zmenu uloženia do SQL databázy a následne môžem ten súbor z primárneho úložiska zmazať.

Súbory si používatelia nazývajú (takmer) ľubovoľne, v mene jedného súboru môže byť kombinácia znakov $, ', ".

Toto celé sa deje na manažovanom webhostingu, kde si nemôžem nič inštalovať a musím použiť to, čo hosting ponúka.

[Jendа]

set -u moc nepomôže, aj keby som ho vedel nejako injektovať do scp alebo do rsync volania.

Máš pravdu, přehlédl jsem kde používáš ' a kde " a myslel jsem, že expanze je už na lokálním počítači.

[jiwopene]

Za zmínku stojí ještě volba -D, která nastaví SOCKS proxy.

[Jendа]

To + tsocks + FoxyProxy do Firefoxu. Nechápu jak může někdo žít bez toho.

[Gréta]

supr fígle :D ;D

[Heron]

Pěkný článek, jen poznámka:

Kľúč na báze eliptickej krivky 25519 je dnes asi najbezpečnejšia voľba (ale napr. starý CentOS 6 ju nepozná).

S tou nejbezpečnější volbou opatrně. Klíč Ed25519* je ekvivalentní 128b symetrické šifry. Jeho hlavní výhoda spočívá v tom, že je malý a že pro generování není potřeba hledat prvočísla (jako u RSA), ale jen náhodná čísla (s tím, že tomu nemá vadit ani cinklý generátor).

Takže výhody jsou malé klíče, rychlé generování i použití klíče (tj přihlašování, podepisování). Nevýhodou je pevně daná velikost.

Já osobně pro "velké servery" stále jedu RSA-4096. Na druhou stranu pro slabé krabičky je ed25519 výhodný a přihlášení je rychlejší.

*) Navíc já osobně mám proti eliptickým křivkám filozofickou výhradu spočívající v tom, že zatímco u RSA je jasně daný algoritmus a všechny parametry si lze vygenerovat u sebe (tj. je nikdo nemůže podstrčit) tak u eliptických křivek (kterých je nekonečně mnoho) je ze samé podstaty nutné vybrat jednu konkrétní a na té potom počítat. A je tady neodstranitelná pochybnost o původu té konkrétní navržené křivky a je úplně jedno, jestli pochází od NSA, NIST nebo Bernsteina.

[Vlado99]

... najbezpečnejšia voľba ...

Ok, mohol som zvoliť vhodnejšiu formuláciu.

To, že niekto rozhodol, že práve krivka 25519 je "tá správna", mne osobne problém nerobí - celý svet okolo nás je taký zložitý, že bez dôvery by sme nemohli fungovať.

RSA je určite skvelé v tom, ako dlho problém faktorizácie odoláva úsiliu o matematické riešenie. Zatiaľ sa zdá, že vydrží až do času, kedy mu zlomí väz kvantové počítanie.

Výpočty na eliptických krivkách, problém diskrétneho logaritmu, vnímam ja (nie-matematik) ako "modernejšiu" matematiku, možno aj preto ten príklon ku ed25519. Kvantové počítanie (taktiež Shorov algoritmus ako pri faktorizácii) údajne rozbije aj túto skupinu šifier, takže z tohto pohľadu ed25519 výhoda nie je.