Fórum Root.cz
Hlavní témata => Server => Téma založeno: kopevi2 19. 10. 2025, 13:28:24
-
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?
-
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
-
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.
-
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
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 :-))
-
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.
-
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)
-
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).
-
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...
-
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:
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:
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.
-
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 (https://www.root.cz/clanky/bezpecne-prihlasovani-na-ssh-s-hardwarovym-u2f-tokenem/), 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.
-
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:
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:
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
-
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.