Trpěli jste následujícím selháním:
Agent přiznal selhání při podpisu pomocí klíče.
Toto je bohužel nediagnostická zpráva. Existují (alespoň) dvě třídy problémů, které by mohla řešit:
Klíč není načten
U většiny problémů to znamená, že vaše ssh-agent
nemá načteny žádné ssh klíče, které jsou akceptovány pro váš účet na cílovém serveru. V tomto případě, jak uvádí odpověď @Networker na tuto otázku, je řešení poměrně jednoduché:přidejte klíč:
ssh-add
Pokud je klíč v jiném než výchozím umístění, musíte to sdělit ssh-add
:
ssh-add /path/to/key
Agent nerozumí klíči
Jednalo se o chybu GNOME 754028, vyřešenou v Seahorse 3.29.90 (stabilní verze 3.30 vydaná 2018-09-03, zahrnuta v Ubuntu 18.10, Fedora 29 a pravděpodobně Red Hat/CentOS 9). Seahorse před verzí 3.29.90 (a tedy klíčenka GNOME) nemohl vytvářet ani přidávat nové typy klíčů, jako je ed25519 a klíče generované pomocí ssh-keygen -o -a 100
(jak navrhuje výukový program Secure Secure Shell).
Diagnóza tohoto problému:
ssh myserver
selže s "ssh Agent uznal selhání"SSH_AUTH_SOCK= ssh myserver
funguje dobře- Závěr:
gnome-keyring
neumí si poradit se složitými klíči
Protože jsem právě našel životaschopné řešení této chyby a nezdá se, že by byla nikde zveřejněna (kromě komentáře, který jsem právě přidal k chybě Ubuntu), vložím ho sem.
Řešení: Spusťte nový ssh-agent
pomocí stejného socketu jako ten z gnome-keyring
:
ssh-agent -a $SSH_AUTH_SOCK
Tím se spustí nová instance ssh-agent
(přepisuje méně schopnou instanci GNOME), takže v ní nebudou žádné klíče (navzdory seahorse
říká, protože to je vázáno na starého agenta). Budete je muset přidat pomocí ssh-add
jak je uvedeno v Klíč není načten sekce výše.
Budete to muset spustit pokaždé, když se přihlásíte (nebo to ručně přidat do spouštěcích skriptů). Pokud chcete zachovat starý soket, spusťte mv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.broken
první.
Problém jsem vyřešil jednoduše spuštěním tohoto příkazu na místním počítači (po vygenerování klíče):
$ ssh-add