SSH s YubiKey píše: Permission denied (publickey)

[kopevi2]

Zdravím,
protože mi blbnul ntb se zápisem na nvme (řešil jsem v téma https://forum.root.cz/index.php?topic=30827.msg426504#msg426504), tak jsem přeinstaloval kompa s formátováním disku na kubuntu 25.04. (zatím mi to kleklo jen jednou)
Všechno šlape zdá se ok, ale problém nastal se ssh klíčema.
Na přihlašování cca rok používám token yubikey, do kterého jsem si dle návodů na Linux expres https://www.linuxexpres.cz/praxe/tokeny-yubikey nahrál klíč a zvesela jsem to používal až do teď. Klíče jsem generoval na ubuntu 22.04. pak jsem přešel na 24.04 a dále na Mint, který jsem cca 4 měsíce používal a vše fungovalo prakticky automaticky. Dělal jsem si i záložní klíče bez tokenu, ty nejedou také.

Jak závada probíhá?
klasika přidám klíč :ssh-add -t 8h klic_na_ssh
To mi klasicky nic nenapsalo
pak když dám
ssh user@server.org -p 22

tak při prvním spuštění na systému dám, že věřím serveru
a pak už mi to jen háže
user@server.org: Permission denied (publickey). (SSH)

Přitom tento token používám i na služebním PC, kde se také připojuji skrze ssh tunel na vnc na jiný stroj, kde to cca před týdnem ještě jelo.
SSH klíče mám uložené v trezoru (CryFS) práva na privátní klíč jsem nastavoval na chmod 600, na složku s klíčema na 700
(dělal jsem to radši znova, viz https://askubuntu.com/questions/311558/ssh-permission-denied-publickey )

Nevíte někdo, co jsem zmotal, že mi to nejde?
 

[Reklama]

[kopevi2]

Ještě jsem zkusil promazat .ssh/known_hosts
a pak když jsem dal
ssh-add -t 8h klic.key

tak mi to dalo toto

Could not add identity "klic.key": agent refused operation

koukam na toto https://stackoverflow.com/questions/60064912/ssh-add-could-not-add-identity-xxx-agent-refused-operation

ale uplne nevim, jak z toho ven

[RDa]

Podivej se na log na serverove strane.

Je mozne, ze v sshd config jsou zakazane nektere typy klicu/sifer, takze ti to v ramci bezpecnosti odmita vzit slabsi klic.

[kopevi2]

Podivej se na log na serverove strane.

Je mozne, ze v sshd config jsou zakazane nektere typy klicu/sifer, takze ti to v ramci bezpecnosti odmita vzit slabsi klic.

Na serveru jsem se koukal, že se nic nezměnilo sshd_config
mám povoleno

Kód: [Vybrat]

AllowUsers xxxxxx
PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com
Spíš jestli jsem něco nepomotal, když jsem si natvrdo kopíroval /home na nově instalovaný disk (zatím mi to vždycky vyšlo :-))

[Ivan Brezina]

Pokud mas root-a na serveru, tak si spust dalsi sshd na foregroundu (na portu 2222) a on ti rekne proc ten klic odmita

/usr/sbin/sshd -D -ddd -p 2222

Muj oblibeny problem je situace kdy je vsechno spravne na strane klienta i na serveru.
Akorat je poradi klicu v ssh-agentovi nahodne a server overuje pouze prvnich 5 klicu.

[Reklama]

[RDa]

Spíš jestli jsem něco nepomotal, když jsem si natvrdo kopíroval /home na nově instalovaný disk (zatím mi to vždycky vyšlo :-))

S cp -a by to melo byt ok - u tech authorized_keys se vyzaduji 600 prava (a na .ssh pak 700)

[kopevi2]

Pokud mas root-a na serveru, tak si spust dalsi sshd na foregroundu (na portu 2222) a on ti rekne proc ten klic odmita

/usr/sbin/sshd -D -ddd -p 2222

Muj oblibeny problem je situace kdy je vsechno spravne na strane klienta i na serveru.
Akorat je poradi klicu v ssh-agentovi nahodne a server overuje pouze prvnich 5 klicu.

nefacha server nic nepíše ani když zkusím port 2222 i 22
ssh agent na klientovi nechce akceptovat klíč s tokenem
user@server.org: Permission denied (publickey).

[kopevi2]

Spíš jestli jsem něco nepomotal, když jsem si natvrdo kopíroval /home na nově instalovaný disk (zatím mi to vždycky vyšlo :-))

S cp -a by to melo byt ok - u tech authorized_keys se vyzaduji 600 prava (a na .ssh pak 700)

to jsem radši znovu nastavoval a nic...

[Pavel Rauš]

Předně bych se vykašlal na pkcs11. Vypni agenta v openssh a nahraď ho gpg-agentem.

do ~/.gnupg/scdaemon.conf přídej řádek disable-ccid ( je potřeba od gnupg 2.4 )

Pak můžeš narazit na tento bug https://dev.gnupg.org/T5935
řešením je do klientské konfigurace ssh přidat:

Kód: [Vybrat]

KexAlgorithms -sntrup761x25519-sha512@openssh.com
HostKeyAlgorithms -ecdsa-sha2-nistp256


Pokud je opensc překompilované se zapnutým polkit, tak přidej do adresáře /etc/polkit-1/rules.d soubor s příponou .rules a následujícím obsahem a do subject.user dej jmeno sveho uzivatele:

Kód: [Vybrat]

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_card" &&
        subject.user == "") {
            return polkit.Result.YES;
    }
});

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
        subject.user == "") {
            return polkit.Result.YES;
    }
});

Pokud ti to napíše The agent has no identities, tak restartni pcscd.

[Petr Krčmář]

Nejdřív je potřeba zjistit vůbec nějaké informace, podle kterých by bylo možné poznat, co se rozbilo. Základním krokem je pustit klienta s parametrem -vvv pro zvýšení upovídanosti. Rozepíše veškeré kroky, které dělá během procesu připojování a přihlašování. Tam je možné vykoukat, ve který moment se co rozbilo.

Každopádně bych dnes už zvážil přihlašování pomocí U2F, tedy pomocí klíčů typu SK (Security Keys). Je to bezproblémové a kromě alespoň pět let starého OpenSSH to nevyžaduje žádnou další podporu.

[kopevi2]

Předně bych se vykašlal na pkcs11. Vypni agenta v openssh a nahraď ho gpg-agentem.

do ~/.gnupg/scdaemon.conf přídej řádek disable-ccid ( je potřeba od gnupg 2.4 )

Pak můžeš narazit na tento bug https://dev.gnupg.org/T5935
řešením je do klientské konfigurace ssh přidat:

Kód: [Vybrat]

KexAlgorithms -sntrup761x25519-sha512@openssh.com
HostKeyAlgorithms -ecdsa-sha2-nistp256


Pokud je opensc překompilované se zapnutým polkit, tak přidej do adresáře /etc/polkit-1/rules.d soubor s příponou .rules a následujícím obsahem a do subject.user dej jmeno sveho uzivatele:

Kód: [Vybrat]

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_card" &&
        subject.user == "") {
            return polkit.Result.YES;
    }
});

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
        subject.user == "") {
            return polkit.Result.YES;
    }
});

Pokud ti to napíše The agent has no identities, tak restartni pcscd.

Děkuji za radu, jen bych se chtěl zeptat (abych nenastavoval nesmysly) - subject.user == "" zde tedy dám přihlašovací jméno klienta tzn. user_NTB namísto user_VPS ?
Bude mi to fachat na ten token od yubikey s tím starým klíčem? (tento klíč používám na asi 15 soukromých strojů, k některým se jinak než přes ssh (a ty moje staré klíče) nedostanu, tak bych nechtěl vše dělat úplně znova.

na tom Yubikey 5 NFC mám klíče které používají šifry sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com

[Pavel Rauš]

Děkuji za radu, jen bych se chtěl zeptat (abych nenastavoval nesmysly) - subject.user == "" zde tedy dám přihlašovací jméno klienta tzn. user_NTB namísto user_VPS ?
Bude mi to fachat na ten token od yubikey s tím starým klíčem? (tento klíč používám na asi 15 soukromých strojů, k některým se jinak než přes ssh (a ty moje staré klíče) nedostanu, tak bych nechtěl vše dělat úplně znova.

na tom Yubikey 5 NFC mám klíče které používají šifry sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com

Jméno uživatele, který je v tom lokálním systému ze kterého se přihlašujete. Za normálních okolností má k té kartě ( pokud je opensc překompilováno s polkit ) přístup pouze root. Takto se přidá oprávnění pro dalšího konkrétního reálného uživatele v systému. Případně lze celou tu číst s tím subject.user vynechat a tím bude mít možnost z té karty číst každý uživatel ... ale to je z pohledu bezpečnosti ošklivé.

Ano, bude to fungovat, ten privátní klíč je uložený v tom yubikey.

[kopevi2]

Děkuji všem za pomoc.Tak jsem toho agenta ssh zkoušel i s výřečným režimem a nic

Kód: [Vybrat]

ssh-add -vvv -t 8h klic.key
Could not add identity "klic.key": agent refused operation
zkusil jsem to i na nově založeném účtu...
Jak jsem již psal, tak na služebním PC (Kubuntu 24.04.) to funguje předpisově(přidám klíč do ssh, vložím token do usb, a pak se stačí dotknout tokenu a jsem na vps), ale asi s novou verzí agenta, něco dělám špatně.
Zkusím tedy gpg-agenta...

[aaa158]

...

Kód: [Vybrat]

ssh-add -vvv -t 8h klic.key
Could not add identity "klic.key": agent refused operation
..

https://stackoverflow.com/a/60065314 : Your ssh-agent is not running or ssh-add can not connect to it via SSH_AUTH_SOCK.

[kopevi2]

Děkuji za radu, jen bych se chtěl zeptat (abych nenastavoval nesmysly) - subject.user == "" zde tedy dám přihlašovací jméno klienta tzn. user_NTB namísto user_VPS ?
Bude mi to fachat na ten token od yubikey s tím starým klíčem? (tento klíč používám na asi 15 soukromých strojů, k některým se jinak než přes ssh (a ty moje staré klíče) nedostanu, tak bych nechtěl vše dělat úplně znova.

na tom Yubikey 5 NFC mám klíče které používají šifry sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com

Jméno uživatele, který je v tom lokálním systému ze kterého se přihlašujete. Za normálních okolností má k té kartě ( pokud je opensc překompilováno s polkit ) přístup pouze root. Takto se přidá oprávnění pro dalšího konkrétního reálného uživatele v systému. Případně lze celou tu číst s tím subject.user vynechat a tím bude mít možnost z té karty číst každý uživatel ... ale to je z pohledu bezpečnosti ošklivé.

Ano, bude to fungovat, ten privátní klíč je uložený v tom yubikey.

Tak jsem to zkusil, nastavuji podle Vás a návodu
https://ryanlue.com/posts/2017-06-29-gpg-for-ssh-auth

Ale mám zmatky v tom, jak do toho dostanu ten otisk klíče (jde mi to, že mám privátní klíč:soubor klic.key, který bez toho tokenu od Yubikey nefunguje) podle sekce:

Adding keys
Tell gpg-agent which subkey to pass to ssh by adding its “keygrip” to ~/.gnupg/sshcontrol:

Kód: [Vybrat]

$ gpg -k --with-keygrip
/Users/you/.gnupg/pubring.kbx
------------------------------
pub   rsa2048/93BDD96B 2017-06-29 [SC]
      D03833D3D52F5FFCCC73452461671825E8DEC139
      Keygrip = 8A6CDC5FCE05A5B251BD8C397B269607534B4702
uid         [ultimate] Big John <big.john@gmail.com>
sub   rsa2048/0424163D 2017-06-29 [E]
      Keygrip = E110250E32B811D45879A66F487CE95BC1906D77
sub   rsa2048/8F228EDB 2017-06-29 [A]
      Keygrip = 32BC5688805A640D495E8A7B41EC78F74E77E098
$ echo 32BC5688805A640D495E8A7B41EC78F74E77E098 > ~/.gnupg/sshcontrol