Použití ssh -A a odpojení

[tadeas]

Mám program, který dělá spoustu SSH spojení a běží několik dní. Z tohoto důvodu ho nemůžu pouštět na svém notebooku, ale pouštím ho na serveru. Na všech zúčastněných serverech mám veřejný klíč. Soukromý klíč nesmím nikam nahrát, maximálně se můžu přihlásit přes ssh -A. Přístup mám pouze uživatelský, nemám root.

Pustím program přes nohup (to funguje dobře), ale když se odhlásím, tak program stejně spadne, protože mu zmizí soukromý klíč z paměti a začnou selhávat SSH.

Dá se nějak udržet v paměti klíč nahraný přes "ssh -a" i po logoutu? Nebo vás napadá nějaké jiné řešení, nebo workaround?

Dík

[Reklama]

[Sten]

ssh -A forwarduje požadavky poslané SSH agentovi na lokální počítač. Když se lokální počítač odpojí, není kam požadavky forwardovat.

Lze na serveru spustit ssh-add - a klíč mu předat z notebooku pomocí SSH spojení. Tím dojde ke spuštění SSH agenta na serveru a nahrání daného klíče do něj, nicméně to znamená, že daný soukromý klíč je dostupný na serveru a vytáhnout jej z RAM už není moc složité.

Druhá možnost je všechna potřebná SSH spojení otevřít při startu programu a během běhu je nezavírat, takže nebude SSH agent potřeba.

Třetí a asi nejlepší možnost je vygenerovat soukromý klíč pro server, rozkopírovat jej na SSH servery, kam se ten program připojuje, a v authorized_keys na nich omezit použití toho klíče jen na definované úlohy.

[tadeas]

ssh -A forwarduje požadavky poslané SSH agentovi na lokální počítač. Když se lokální počítač odpojí, není kam požadavky forwardovat.

Jo takhle.. Já žil v domnění, že to kopíruje soukromý klíč. Takhle to je všechno složitější...

Popřemýšlím o tom, každopádně díky za vysvětlení!

[Jenda]

Soukromý klíč nesmím nikam nahrát, maximálně se můžu přihlásit přes ssh -A. Přístup mám pouze uživatelský, nemám root.

Nechápu tento požadavek. Pokud je vzdálený počítač evil, je už asi celkem jedno, jestli zneužije klíč přes SSH agenta nebo rovnou…

[tadeas]

Soukromý klíč nesmím nikam nahrát, maximálně se můžu přihlásit přes ssh -A. Přístup mám pouze uživatelský, nemám root.

Nechápu tento požadavek. Pokud je vzdálený počítač evil, je už asi celkem jedno, jestli zneužije klíč přes SSH agenta nebo rovnou…

Corporate policy.

[Reklama]

[Ondřej Caletka]

Soukromý klíč nesmím nikam nahrát, maximálně se můžu přihlásit přes ssh -A. Přístup mám pouze uživatelský, nemám root.

Nechápu tento požadavek. Pokud je vzdálený počítač evil, je už asi celkem jedno, jestli zneužije klíč přes SSH agenta nebo rovnou…

Použiješ-li ssh-add -c, vyskočí při každém požadavku na podpis pop-up okýnko. takže přesně víš, kolik certifikátů jsi vydal. Pokud -c nepoužiješ, je to jedno.

[Mirek Prýmek]

Pokud -c nepoužiješ, je to jedno.

Ani tak to neni uplne jedno - muze klic pouzit, ale nemuze ho ukrast. To muze (a nemusi) byt velky rozdil.

U security tokenu taky neni zas tak tezke klic pouzit (stejne tezke jako pouzit klic v souboru), ale je nemozne ho ukrast.

[Ondřej Caletka]

Ani tak to neni uplne jedno - muze klic pouzit, ale nemuze ho ukrast. To muze (a nemusi) byt velky rozdil.

U security tokenu taky neni zas tak tezke klic pouzit (stejne tezke jako pouzit klic v souboru), ale je nemozne ho ukrast.

To je pravda, musí klíč zneužít v reálném čase, nebo nagenerovat dostatečné množství podpisů pro všechny možné challenge (což je asi nereálné).

K původnímu dotazu: elegantní řešení je použít sdílené spojení, po manuálním přihlášení otevřít všechna master spojení a skript nechat pracovat ve slave režimu. Více v článku.

[Jenda]

Soukromý klíč nesmím nikam nahrát, maximálně se můžu přihlásit přes ssh -A. Přístup mám pouze uživatelský, nemám root.

Nechápu tento požadavek. Pokud je vzdálený počítač evil, je už asi celkem jedno, jestli zneužije klíč přes SSH agenta nebo rovnou…

Použiješ-li ssh-add -c, vyskočí při každém požadavku na podpis pop-up okýnko. takže přesně víš, kolik certifikátů jsi vydal. Pokud -c nepoužiješ, je to jedno.

To je pravda, na druhou stranu sám tazatel popsal počet vydávaných certifikátů jako „spoustu“.

[Mirek Prýmek]

To je pravda, na druhou stranu sám tazatel popsal počet vydávaných certifikátů jako „spoustu“.

Spoustu _spojení_.

[tadeae]

Tak reseni je nakonec novy server vyhrazeny pro toto pouziti a vygenerovani noveho klice, jehoz soukroma cast bude na tom novem serveru. Je to trosku skoda, doufal jsem, ze to pujde vyresit pouze softwarove, ale neda se nic delat (na druhou stranu to neplatim ja, tak mi to muze byt fuk). Aspon mam jistotu, ze mi to nebude nikdo jiny zatezovat.

[Jenda]

Tak reseni je nakonec novy server vyhrazeny pro toto pouziti a vygenerovani noveho klice, jehoz soukroma cast bude na tom novem serveru. Je to trosku skoda, doufal jsem, ze to pujde vyresit pouze softwarove

To prostě nevyřešíš, když má někdo na tom vzdáleném stroji roota, tak se prostě nijak skrýt nemůžeš.

ale neda se nic delat (na druhou stranu to neplatim ja, tak mi to muze byt fuk). Aspon mam jistotu, ze mi to nebude nikdo jiny zatezovat.

Hele a třeba o virtualizaci jste slyšeli?

[Sten]

To prostě nevyřešíš, když má někdo na tom vzdáleném stroji roota, tak se prostě nijak skrýt nemůžeš.

Řešení by bylo vytvořit na tom stroji jeho vlastní klíč a v authorized_keys omezit, co smí ten klíč na klientech spouštět.

[tadeae]

Na tom puvodnim kde jsem to chtel spoustet soukromy klic byt proste nesmi. Nic s tim nenadelam. Ani s verejnym klicem omezenym na konkretni prikazy (ty by stejne zahrnovaly modprobe a hrabani do /proc...).

Ten novy virtualni pravdepodobne je, ale to je principielne jedno, stejne to musi bezet na nejakem zeleze, ktere by jinak nebylo potreba.

[Mirek Prýmek]

To prostě nevyřešíš, když má někdo na tom vzdáleném stroji roota, tak se prostě nijak skrýt nemůžeš.

Pokud je kompromitovaný stroj, na kterém klíče používám*, tak nepomůže žádné řešení.

* tj. je tam nějaký socket na který pošlu "podepiš mi tohle" a on mi to pošle zpátky podepsaný