SSH/GPG agent vs. gnome-keyring-daemon

31.1.2015 15:12 | GNU/Linux | | poslední úprava: 15.3.2017 21:22

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

       

Komentáře

[Prcek]

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 .

[chrono]

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]

Příloha:

• KDE - Správce služeb.png (153777 bytů)

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ěží.

[Nicky726]

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.

[pavlix]

Celkově mám dojem, že SSH z uživatelského pohledu nefunguje tak, jak bych si představoval.

[xkucf03]

Můžeš to rozvést?

[pavlix]

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.

[Vlcek]

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]

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.

[Vlcek]

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]

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.

[xkucf03]

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.

[pavlix]

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.

[xkucf03]

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 a --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í.

[pavlix]

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.

[pavlix]

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.

[pavlix]

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"

[xkucf03]

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

[pavlix]

…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á.

[pavele]

Co zkusit sdělit tyto názory Lennartovi, možná by s tím zastaralým software zkusil něco udělat?

[pavlix]

Nejsem si jistý, jestli patříme do kasty, od které by se chtěl inspirovat :).

[rastos]

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]

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.

[pavlix]

To se ale týká jenom toho gnomáckého agenta, že?

[Vlcek]

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]

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

[Vlcek]

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]

Taky to tak chápu a vyhovuje mi spíše chování, které je vlastní tomu gnomáckému keyringu.

[Hynek]

Kdyby to někdo potřeboval vypnout v xfce - xfce-without-gpg-agent