abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 18:11 | Nová verze

    Byla vydána verze 1.63.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

    Ladislav Hagara | Komentářů: 1
    včera 17:55 | Nová verze

    Bylo vydáno Ubuntu 22.04.1 LTS, tj. první opravné vydání Ubuntu 22.04 LTS s kódovým názvem Jammy Jellyfish.

    Ladislav Hagara | Komentářů: 0
    včera 08:00 | Komunita

    Microsoft Fluent Emoji jsou nově k dispozici na GitHubu pod licencí MIT. Více v článku na Medium.

    Ladislav Hagara | Komentářů: 2
    včera 00:22 | IT novinky

    O víkendu proběhla v Kolíně nad Rýnem demopárty Evoke 2022. Publikována byla prezentovaná dema. Upozornit lze na Area 5150 (YouTube) běžící na IBM PC s procesorem Intel 8088 běžícím na 4,77 MHz a CGA.

    Ladislav Hagara | Komentářů: 1
    10.8. 19:55 | Zajímavý software

    smenu, nástroj pro příkazový řádek pro generování možností a potvrzení výběru, dospěl do verze 1.0.0.

    Ladislav Hagara | Komentářů: 0
    10.8. 19:11 | Bezpečnostní upozornění

    Byla potvrzena zranitelnost CVE-2021-46778 aneb SQUIP (Scheduler Queue Usage via Interference Probing) v procesorech AMD s mikroarchitekturou Zen 1, Zen 2 a Zen 3. Detaily v publikovaném paperu.

    Ladislav Hagara | Komentářů: 0
    10.8. 13:33 | Nová verze

    Turris OS, operační systém pro síťová zařízení Turris postavený na OpenWrt, byl vydán v nové verzi 5.4. Přehled novinek a diskuse v diskusním fóru.

    Ladislav Hagara | Komentářů: 2
    10.8. 13:11 | Nová verze

    Byla vydána nová stabilní verze 5.4 (aktuálně 5.4.2753.28) webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 104.0.5112.83. Přehled novinek v příspěvku na blogu. Vivaldi Mail byl povýšen na verzi 1.1.

    Ladislav Hagara | Komentářů: 0
    9.8. 23:33 | Bezpečnostní upozornění

    Intel vydal 27 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20220809 mikrokódů pro své procesory. Ta řeší INTEL-SA-00657. Jedná se o bezpečnostní chybu ÆPIC Leak aneb CVE-2022-21233.

    Ladislav Hagara | Komentářů: 2
    9.8. 20:22 | Nová verze

    Byla vydána nová verze 2022.3 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.

    Ladislav Hagara | Komentářů: 0
    Audioknihy ve srovnání s knihami tištěnými (papírovými nebo elektronickými) poslouchám
     (34%)
     (2%)
     (6%)
     (58%)
    Celkem 180 hlasů
     Komentářů: 1, poslední 8.8. 21:17
    Rozcestník

    SSH/GPG agent vs. gnome-keyring-daemon

    31.1.2015 15:12 | GNU/Linux | Výběrový blog | poslední úprava: 15.3.2017 21:22

    Zápisek byl přesunut sem: SSH/GPG agent vs. gnome-keyring-daemon

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Prcek avatar 31.1.2015 16:57 Prcek | skóre: 43 | Jindřichův Hradec / Brno
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    No zrovna nedávno jsem v práci na Kubuntu doinstaloval kleopatru a vyskočila přesně ta chyba s komunikací s agentem. Vyřešil jsem to tak, že jsem to ignoroval :-), neměl jsem čas to moc řešit.

    Takže tenhle zápisek je jako na zavolanou, dík :-).
    Člověk je takový, jak vypadá... A já vypadám jako pravá, nefalšovaná děvka!!!
    31.1.2015 19:02 chrono
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    V KDE nie je nič, v čom by sa dalo nastavovať, aké služby/programy sa majú spúšťať po prihlásení sa do prostredia? (veľmi by som sa čudoval, ak by tam nič také nebolo, pretože napr. aj v Xfce je na to program a Gnome Keyring komponenty sa tam dajú zakázať)
    xkucf03 avatar 31.1.2015 19:14 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Příloha:

    Je – Správce služeb – ale o spuštění těch agentů se starají Xka/Upstart ještě před spuštěním KDE – když nabíhá KDE, tak už jsou AFAIK ty proměnné nastavené a ti agenti běží.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    Nicky726 avatar 4.2.2015 18:52 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    S KDE4 mi to řešily skripty v automatickém spouštění resp. v adresářích .kde4/{Autostart,env,shutdown} přičemž právě v env je skript spouštěný před startem prostředí, aby byly proměnné nastavené včas.
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    pavlix avatar 1.2.2015 10:22 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Celkově mám dojem, že SSH z uživatelského pohledu nefunguje tak, jak bych si představoval.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 1.2.2015 11:38 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Můžeš to rozvést?
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 1.2.2015 12:15 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Ovládání celého toho systému s klíči mi přijde hrozně dřevorubecké a nekonzistentní, od jejich tvorby, sdílení, zveřejňování, až po jejich používání přes agenta. Mně osobně se vůbec nelíbí, když se mě SSH ptá na konzoli a ne celoobrazovkově. Stejnětak se mi nelíbí, když se mě ptá opakovaně, když bych ve skutečnosti radši nechal dekryptovaný klíč v paměti a jen si nastavil parametry jako jak dlouho tam bude, za jakých okolností se vymaže apod. Pak mám pocit, že OpenSSH vůbec neumí multihop SSH. Taky mi nevyhovuje, že SSH selhává na known hosts, když se připojuju jednorázově k IP adrese. Přijde mi, že celý ten software krutě zaspal dobu a potřebuje nahradit něčím příjemnějším.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    1.2.2015 14:06 Vlcek
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Je to už nějaká doba co jsem si s multihopem hrál, a používal jsem to prakticky jen chvilku, ale přes ssh config a možnosti jako ProxyCommand, a případně ControlMaster (kvůli zrychlení inicializace dalších spojení) to nastavit jde...

    Nějaký příklad toho setupu jde najít třeba tady...

    http://sshmenu.sourceforge.net/articles/transparent-mulithop.html

    Jak jsem ale říkal... Používal jsem to jen chvilku, takže je možné, že to má nějaký problémy na který jsem tehdy nenarazil...

    K jednorázovým IPinám... Do configu jde ke konkrétnímu hostname zadat možnost "CheckHostIP no", a pak sshčko IPinu kontrolovat nebude. Jestli zadáváš přímo IP adresu, tak je to horší :-) Možná by ale šlo udělat
    Host 192.*
      UserKnownHostsFile /dev/null
    
    Tohle by mělo matchnout IPiny začínající 192 a záznamy o tom ukládat do /dev/null, tzn. neukládat vůbec.

    pavlix avatar 1.2.2015 14:18 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Já netvrdím, že tam ty vlastnosti nejsou, jen že se velmi špatně používají. Když dojde na věc, používám ty metody, o kterých píšeš, ale typicky jsou ve stylu drbání levou nohou za pravým uchem.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    1.2.2015 14:43 Vlcek
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Aha, zmátla mě ta část
    mám pocit, že OpenSSH vůbec neumí multihop SSH
    Jinak s tím nastavením je to vcelku těžký... OpenSSH je tu už dlouho, spousta lidí má vlastní configy. Kdyby se to najednou začalo komplet předělávat, tak by buď spousta lidí prskala, že jim rozbíjí co funguje, a kdyby chtěli "zpětnou kompatibilitu", tak by to nejspíš se syntaxí configu dopadlo podobně jako u rsyslogu (několik různých vzájemně nekompatibilních verzí, který "jdou" ale nějak spojovat dohromady).

    Napsat novou implementaci ssh serveru od začátku není žádná sranda, a kdo ví kolik let by trvalo než by tomu lidi začali věřit... Nejschůdnější by se asi tvářil fork, ale... :-)

    Nevím ale jak moc lidí tvoje konkrétní příklady trápí...

    Třeba já dělám admina/prográmátora, a většinu z těhle věcí jsme buď obešli a nebo vůbec neřešili. Místo multihopu používám VPNko když nejsem v kanclu. Na problém s IPinama v known hosts jsem narazil nějak významně jen když se stěhovaly servery, to mi ale stačilo "smazat" known hosts, pač jsme si všechny FP host klíčů stihli nastrkat do DNSsek. Práce s klíčama mi taky z větší části odpadla, pač na autentizaci/autorizaci používáme kerbera/LDAP...

    Každýho trápí něco jinýho, otázka je do jaký míry se tím zabývat na úkor něčeho jinýho (třeba teďka novinka ohledně OpenSSH o aktualizaci klíčů v known hosts) :-)
    pavlix avatar 1.2.2015 15:01 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Jo to chápu, myslel jsem jsem to trochu jinak, než jsem to napsal. Mně je osobně jedno, kolik lidí to trápí, ale docela uvažuju, že zkusím kouknout na dropbear a v něm si případně některé věci upravit.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 1.2.2015 15:55 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Ovládání celého toho systému s klíči mi přijde hrozně dřevorubecké a nekonzistentní, od jejich tvorby, sdílení, zveřejňování,

    Pro koncového uživatele by bylo pohodlnější zavedení CA, ale pak bys zase musel distribuovat jejich veřejné klíče a kladlo by to větší nároky na správce serverů. Případně používat pavučinu důvěry ve stylu GnuPG.

    až po jejich používání přes agenta. Mně osobně se vůbec nelíbí, když se mě SSH ptá na konzoli a ne celoobrazovkově.

    Viz zápisek, na který reaguješ – agent se může ptát na heslo jak textově v konsoli, tak pomocí nějakého dialogu. Ten dialog sice není na celou obrazovku, ale zabere si pro sebe klávesnici a myš a nemělo by jít psát nikam jinam.

    Stejnětak se mi nelíbí, když se mě ptá opakovaně, když bych ve skutečnosti radši nechal dekryptovaný klíč v paměti a jen si nastavil parametry jako jak dlouho tam bude, za jakých okolností se vymaže apod.

    Tohle AFAIK jde. Sice to používám tak, že si SSH agent heslo pamatuje pořád, ale jde to nastavit i jinak. Třeba u GPG to mám tak, aby heslo po čase zapomněl. Případně si dovedu představit implementaci agenta, která ti zobrazí, který program chce přístup ke klíči a zeptá se, jestli mu to má povolit. A tohle ani moc nesouvisí s OpenSSH – ten návrh je celkem modulární, takže můžeš nezávisle měnit pinentry program a agenta, ale SSH klienta mít pořád stejného.

    Pak mám pocit, že OpenSSH vůbec neumí multihop SSH.

    Jak to myslíš? Viz SSH přes SSH „proxy“ server – a vyhovuje mi to mnohem víc než nějaké VPNky. Dá se to libovolně zřetězit a nepotřebuji rootovská práva, abych si nastavil „směrování“ pro jednotlivé cílové servery. Případně jde tunelovat agenta, ale to jde použít jen s důvěryhodnými „proxy“ servery.

    ProxyCommand je hodně flexibilní a můžeš použít libovolnou technologii pro tunelování (HTTP, DNS atd. ne jen SSH). Tahle funkcionalita mi u jiných programů/protokolů celkem dost chybí (dobrá je implementace socketů v Javě, kde tohle můžeš dělat přes SocketFactory).

    Co by šlo vylepšit, je: přidat nějakou zkratku typu:

    ssh --hop-over nějaká-proxy.example.com cílový-stroj.example.com

    ale až tak mě to netrápí, protože se většinou připojuji na ty stroje opakovaně, tak mi spíš vyhovuje mít tohle v konfiguračním souboru.

    Taky mi nevyhovuje, že SSH selhává na known hosts, když se připojuju jednorázově k IP adrese.

    A jak má vědět, že je ta adresa jednorázová, že se chceš jen ad-hoc připojit? Asi by tam mohla být nějaká zkratka pro:

    ssh -o UserKnownHostsFile=/dev/null root@192.168.1.123

    aby si nic neukládal a nekontroloval.

    Přijde mi, že celý ten software krutě zaspal dobu a potřebuje nahradit něčím příjemnějším.

    Nemyslím si. SSH je jedna z nejlepších věcí, co nás potkala :-) Co bych uvítal, jsou audity kódu – těch není nikdy dost – a případně přepis vnitřností s ohledem na bezpečnost. Ale z uživatelského hlediska to hodnotím velice kladně a to, co by zasloužilo vylepšit, se dá řešit evoluční cestou – rozhodně není potřeba nic zahazovat a nahrazovat.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 1.2.2015 17:07 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Pro koncového uživatele by bylo pohodlnější zavedení CA, ale pak bys zase musel distribuovat jejich veřejné klíče a kladlo by to větší nároky na správce serverů.
    Já jsem psal o ovládání, nikoli o principu.
    Viz zápisek, na který reaguješ – agent se může ptát na heslo jak textově v konsoli
    Chtěl bych vidět implementaci agenta, který se ptá v textové konzoli. Netvrdím, že to nejde, to rozhodně ne, jen jsem nic takového ještě neviděl.
    tak pomocí nějakého dialogu.
    Jestli to správně chápu, tak se toto explicitně netýká ssh-agenta, který se pokud vím neumí ptát na heslo žádným způsobem. Asi bych měl někdy zkouknout ti alternativní agenty, co se vlastně už umí.
    Tohle AFAIK jde. Sice to používám tak, že si SSH agent heslo pamatuje pořád, ale jde to nastavit i jinak.
    Jaký nástroj tedy používáš? Originální ssh-agent se pokud vím neumí ptát na heslo vůbec.
    A tohle ani moc nesouvisí s OpenSSH
    Souvisí to s OpenSSH velmi úzce, vzhledem k tomu, že součástí OpenSSH je ten SSH klient. Nikde jsem ovšem netvrdil, že každá zmíněná vlastnost vyžaduje změnu kódu SSH klienta.
    Jak to myslíš? Viz SSH přes SSH „proxy“ server – a vyhovuje mi to mnohem víc než nějaké VPNky.
    Dropbear to umí bez těch opičáren, což má obrovskou výhodu v tom, že je to v podstatě transparentní pro všechny ty aplikace, které SSH volají. Jenom mu zadám seznam strojů a on mi na tom posledním otevře shell. To neplatí ani pro tebou navrhovanou variantu.
    ale až tak mě to netrápí, protože se většinou připojuji na ty stroje opakovaně, tak mi spíš vyhovuje mít tohle v konfiguračním souboru.
    I v tom konfiguráku by to mohlo jít bez těch opičáren.
    A jak má vědět, že je ta adresa jednorázová, že se chceš jen ad-hoc připojit?
    U mě osobně je to velice jednoduché, pokud se nepřipojuju pomocí jména, tak mě typicky žádné kontroly nezajímají. Ale stačilo by mi to pro privátní adresy. Systém to pozná podle toho, že mu to napíšu do konfiguračního souboru. Ale jak mám zapsat 172.16.0.0/12 a proč musím používat nějaké opičárny s /dev/null?
    aby si nic neukládal a nekontroloval.
    Co jsi napsal, je pokud vím jenom aby neukládal, nikoliv aby nekontroloval.
    Nemyslím si.
    Ani nemůžeš, když já mluvím o voze a ty o koze. A i kdybys reagoval k tématu, tak by tě po těch letech nemělo překvapit, že míváme na věci kapku odlišný názor.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 1.2.2015 19:25 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Já jsem psal o ovládání, nikoli o principu.

    Když se nezmění princip, tak se nemůže ani moc změnit ovládání. Buď si uživatel klíče kontroluje a spravuje sám, nebo je tam nějaká forma certifikační autority (jedna v případě DNSSEC, několik v případě klasických CA, nebo několik – i současně podepisujících jeden klíč – v případě WoT). Případně ty klíče můžeš spravovat nějak jinak (třeba přes LDAP) a kryptografii (ve smyslu podepisování klíčů) do toho vůbec netahat, ale tím si moc nepomůžeš.

    Jaký nástroj tedy používáš? Originální ssh-agent se pokud vím neumí ptát na heslo vůbec.

    Používám to úplně jednoduše, na tom asi není nic zajímavého: agenti se spustí při startu X serveru resp. KDE; SSH klíč si přidám pomocí ssh-add a pak je tam celou dobu; GPG klíče odemykám jen když něco podepisuji/dešifruji (je tam nějaká výchozí doba, po kterou je ten klíče dostupný, takže si člověk může přečíst několik zašifrovaných e-mailů po sobě, ale pak se klíč vymaže a příště je potřeba heslo zadávat znova).

    Souvisí to s OpenSSH velmi úzce, vzhledem k tomu, že součástí OpenSSH je ten SSH klient.

    Např. GPG agent má volby --enable-ssh-support, --default-cache-ttl-ssh--max-cache-ttl-ssh a měl by jít použít místo ssh-agenta. Takže s OpenSSH (ani klientem) to nesouvisí – nepotřebuješ ho nijak měnit, prostě ho jen použiješ s jiným agentem. V zásadě to jsou tři vrstvy:

    program (OpenSSH, …) → Agent → pinentry (curses, gtk, qt, …)

    a když ti něco nevyhovuje na vrchních dvou, není důvod měnit tu spodní.

    Nikde jsem ovšem netvrdil, že každá zmíněná vlastnost vyžaduje změnu kódu SSH klienta.

    Jen jsi psal:

    Přijde mi, že celý ten software krutě zaspal dobu a potřebuje nahradit něčím příjemnějším.

    což mi přijde nesmyslně radikální a zbytečné.

    Dropbear to umí bez těch opičáren, což má obrovskou výhodu v tom, že je to v podstatě transparentní pro všechny ty aplikace, které SSH volají. Jenom mu zadám seznam strojů a on mi na tom posledním otevře shell.

    Je celkem obvyklé, že omezený jednoúčelový software má jednodušší rozhraní (potažmo používání) než univerzálnější řešení. ProxyCommand je prostě univerzální, protože umožňuje použít libovolný příkaz, libovolnou tunelovací techniku/technologii, ne jen „SSH-hop“. Proto jsem psal, že by tam mohla být ta zkratka – a ta by klidně mohla mít jako argument seznam strojů/adres.

    I v tom konfiguráku by to mohlo jít bez těch opičáren.

    Viz univerzálnost výše. Ale já hlavně nechci ke každému připojení opisovat seznam strojů, přes které to má jít. Já jen zadám, např. že do firmy A se připojuji přes svůj server X a do firmy B se připojuji přes stroj ve firmě A a do instituce C se připojuji přes svůj stroj Y atd. A ta kompletní cesta, posloupnost proxy-serverů, se vypočte automaticky. A když se něco změní, tak to upravím na jednom místě a nebudu to muset všude přepisovat.

    Je to další příklad toho, jak „jednoduchá“ řešení selhávají a nakonec znamenají vyšší složitost, oproti řešením na první pohled „složitějším“, ale promyšleným a flexibilním.

    U mě osobně je to velice jednoduché, pokud se nepřipojuju pomocí jména, tak mě typicky žádné kontroly nezajímají. Ale stačilo by mi to pro privátní adresy. Systém to pozná podle toho, že mu to napíšu do konfiguračního souboru. Ale jak mám zapsat 172.16.0.0/12 a proč musím používat nějaké opičárny s /dev/null?

    Pak je otázka, proč vůbec používat SSH (secure shell) a ne třeba rsh, rcp, telnet, když ti o bezpečnost vůbec nejde. Jsem spíš rád, že tam taková možnost není – IMHO to jde proti filosofii bezpečného vzdáleného shellu. Ale i kdyby to tam být mělo – opět to není důvod proč zahodit OpenSSH a nahrazovat ho něčím jiným – dá se napsat patch nebo třeba nějaký obalovací skript.

    Co jsi napsal, je pokud vím jenom aby neukládal, nikoliv aby nekontroloval.

    Nekontroluje, protože nemá vůči čemu – takže když se ten klíč změní, nebude tě SSH „prudit“ s tím, že máš nejdřív odmazat záznam z known_hosts.

    P.S. To všechno ale neznamená, že bych si nedokázal představit nějaký lepší protokol než SSH. Jen jsem zatím neměl čas ho napsat :-) A do té doby je SSH téměř dokonalé a velmi dobře vyhovující.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 2.2.2015 11:39 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Když se nezmění princip, tak se nemůže ani moc změnit ovládání.
    To je takový nesmysl, že to nehodlám dále komentovat.
    SSH klíč si přidám pomocí ssh-add
    Pak tedy mluvíme každý úplně o něčem jiném.
    Takže s OpenSSH (ani klientem) to nesouvisí
    Variace na „používání SSH s OpenSSH klientem nesouvisí“ již po několikáté.
    nepotřebuješ ho nijak měnit
    Znovu odpovídám, že jsem netvrdil, že každá jednotlivá vlastnost vyžaduje změnu kódu OpenSSH.
    a když ti něco nevyhovuje na vrchních dvou, není důvod měnit tu spodní.
    Non sequitur.
    což mi přijde nesmyslně radikální a zbytečné.
    Vůbec jsi mě o tom ovšem nepřesvědčil.
    Pak je otázka, proč vůbec používat SSH (secure shell) a ne třeba rsh, rcp, telnet, když ti o bezpečnost vůbec nejde.
    Někdy skutečně používám telnet, ale prakticky jen na OpenWRT, kde je dobře integrovaný s natavením systémového hesla a SSH, tedy se nemusíš starat o přechod z telnetu na SSH sám.
    opět to není důvod proč zahodit OpenSSH a nahrazovat ho něčím jiným
    Nakonec si budu používat, co já budu chtít, a tobě je potom v podstatě hovno. Přecijen se nejedná o diskuzi, kde bys mi s něčím radil, ale o prostou výměnu názorů.
    dá se napsat patch
    Právě tady předpokládám, že to bude mnohem jednodušší v případě toho dropbearu.
    Nekontroluje, protože nemá vůči čemu
    Non sequitur. Za normálních okolností kontroluje právě i když nemá vůči čemu (např. prázdný known_hosts) a na základě toho tě nutí potvrdit klíč při prvním přístupu. Jestliže je /dev/null pro OpenSSH speciální hodnota, tak dejme tomu, moc se mi to nelíbí, ale třeba systemd to tak taky používá.
    P.S. To všechno ale neznamená, že bych si nedokázal představit nějaký lepší protokol než SSH.
    Je zvláštní, že to řešíš v diskuzi, kde jsem o kvalitě protokolu neřekl ani slovo.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 4.2.2015 11:29 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    ssh -o UserKnownHostsFile=/dev/null root@192.168.1.123
    aby si nic neukládal a nekontroloval.
    Tak jsem to vyzkoušel a měl jsem pravdu, a skutečně to znamená pouze neukládat, tedy to ve výsledku nefunguje.
    $ ssh -o UserKnownHostsFile=/dev/null root@172.16.2.214
    The authenticity of host '172.16.2.214 (172.16.2.214)' can't be established.
    ED25519 key fingerprint is d9:cd:ea:dd:d1:19:e9:1e:3c:ff:b9:5a:85:ff:e5:b8.
    Are you sure you want to continue connecting (yes/no)? ^C
    
    Místo toho je potřeba následující.
    $ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@172.16.2.214
    
    Velmi pohodlné a dobře zapamatovatelné, že. A ještě to stejně vyhazuje nesmyslná varování.
    Warning: Permanently added '172.16.2.214' (ED25519) to the list of known hosts.
    Warning: Permanently added '172.16.2.214' (ED25519) to the list of known hosts.
    Zde samozřejmě může přijít návrh nepoužívat SSH, jestliže nepoužívám některé jeho klíčové bezpečnostní funkce. Jako protiargument poslouží mimo jiné to, že SSH server je standardní součástí většiny live distribucí a instalačních systémů právě z toho důvodu, aby bylo možné ke stroji od začátku přistupovat vzdáleně. Podle mých zkušeností to neplatí o žádném jiném systému. OpenWRT skutečně používá telnetd, aby mohlo nabídnout funkcionalitu, kterou dropbear ani openssh nenabízejí, jestli je od implementátorů SSH dobrý přístup je k tomu nutit, je věcí názoru.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 4.2.2015 11:34 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Jen pro informaci, mým řešením pro přeskočení kontroly serverových klíčů je následující řádka v ~/.bashrc.
    alias issh="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 4.2.2015 20:03 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Tak jsem to vyzkoušel a měl jsem pravdu, a skutečně to znamená pouze neukládat, tedy to ve výsledku nefunguje.

    Viz výše:

    Nekontroluje, protože nemá vůči čemu – takže když se ten klíč změní, nebude tě SSH „prudit“ s tím, že máš nejdřív odmazat záznam z known_hosts.

    …ale nemá cenu se tu hádat.

    Velmi pohodlné a dobře zapamatovatelné, že. A ještě to stejně vyhazuje nesmyslná varování.

    To je zase ta diskuse, jestli má program aspoň trochu bránit uživateli střelit se do nohy a místo toho ho raději vést nějakým lepším směrem a snažit se ho vzdělat a posunout někam dál.

    Někdo možná namítne, že uživatel nejlíp ví, co chce a program mu do toho nemá mluvit. Ale uživatel, který ví, co chce a ví, co dělá, to vyřeší – třeba jako ty s tím aliasem – a všichni jsou spokojeni. Ale uživatelů, kterým chybí základní znalosti a kteří potřebují trochu popostrčit, aby se něco naučili, těch je stále dost.

    Podle mého by to určitě neměla být nějaká jednopísmenková kryptická volba, kterou by tito uživatelé bezmyšlenkovitě opisovali. Hlavně, když jim ji někdo „chytřejší“ poradí a oni ho za to obdivují, protože „vyřešil“ jejich problém (ještě neví, že se jim to v budoucnu vrátí).

    Když už, tak by to měla být volba typu --with-fucked-up-security, aby to bylo každému na očích. (pokud jde o počet znaků – máme Bash completion).

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 4.2.2015 20:29 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    …ale nemá cenu se tu hádat.
    To nemá, zvlášť když můj výstup ukazuje, že ke kontrole dochází a výsledkem kontroly je chování typické pro připojování k neznámému stroji. Pokud jde o tu volbu, podle mě by bohatě stačilo --insecure jako má curl a kde je zcela jasné, o co jde. Osobně vůbec nemám nic proti curl -k jakožto zkratce k curl --insecure.

    Lidé jsou nepoučitelní a jak vidíš, tak to budou stejně používat a budou si na to dělat aliasy a někteří z nich možná i patche, takže na to lze jen těžko spoléhat. A co je horší, když ty volby budou dlouhé, budou to psát natvrdo do ~/.ssh/config a veškerá tvoje kontrola je marná.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    1.2.2015 18:17 pavele
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Co zkusit sdělit tyto názory Lennartovi, možná by s tím zastaralým software zkusil něco udělat? :-)
    pavlix avatar 2.2.2015 11:42 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Nejsem si jistý, jestli patříme do kasty, od které by se chtěl inspirovat :).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    1.2.2015 17:25 rastos | skóre: 62 | blog: rastos
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    ptal se na heslo pomocí GTK dialogu místo na příkazové řádce, i když jsem ho spouštěl z Konsole.
    Nezávisí to od toho, či má agent nastavenú premennú prostredia DISPLAY ?
    xkucf03 avatar 1.2.2015 18:33 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon

    Možné to je, ale v tomhle směru jsem nic neměnil – pořád používám SSH v Konsoli v KDE pod Xkami.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 2.2.2015 11:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    To se ale týká jenom toho gnomáckého agenta, že?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    2.2.2015 12:24 Vlcek
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    To si myslím, že není nutný...

    Z man ssh-add
         DISPLAY and SSH_ASKPASS
                 If ssh-add needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal.  If ssh-add does not
                 have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11
                 window to read the passphrase.  This is particularly useful when calling ssh-add from a .xsession or related script.  (Note that on some
                 machines it may be necessary to redirect the input from /dev/null to make this work.)
    
    
    Takže se to týká ssh-add, který je součástí openssh. S gnome agentem to nemusí mít nic společnýho.
    pavlix avatar 2.2.2015 16:48 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Tady je ssh-add jaksi mimo hru, vzhledem k tomu, že to není ani agent, ani klient, ani není jedním z nich spouštěno. Jako samostatná utilita nemá pokud vím na chování žádného z nich vliv a stejně tak nemá prostředí žádného z nich vliv na ní.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    2.2.2015 20:45 Vlcek
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Tak podle man ssh-agenta
    The agent initially does not have any private keys.  Keys are added using ssh-add(1).
    
    To by vysvětlovalo, proč se to najednou ptalo na heslo přes gtk a ne přes term.

    bych právě tipoval, že jo :-) Hádal jsem, že gnome agent to dělá stejně, ale podle jejich stránky to dělá automaticky, a ssh-add umožnuje načítat jen ručně, jestli jsem to správně pochopil :-)

    https://wiki.gnome.org/Projects/GnomeKeyring/Ssh
    pavlix avatar 4.2.2015 20:30 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Taky to tak chápu a vyhovuje mi spíše chování, které je vlastní tomu gnomáckému keyringu.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    1.2.2015 17:42 Hynek
    Rozbalit Rozbalit vše Re: SSH/GPG agent vs. gnome-keyring-daemon
    Kdyby to někdo potřeboval vypnout v xfce - xfce-without-gpg-agent

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.