SSH klient v príkladoch (diskuse)

[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.

[❗Červivý Hřib krade❗]

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.