Změny v sshd v Ubuntu 22 vs. 24

[hknmtt]

Na ubuntu 24 lts bola moja sshd konfiguracia nasledovna:

Kód: [Vybrat]

Port 1234
AddressFamily inet
AllowUsers foo
AuthenticationMethods publickey
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
UsePAM no

na Ubuntu 24 mi ale neustale pise

permission denied (publickey)

. Viem ze na 22 ked som to riesil tak bol problem v tom ze som nemal

PubkeyAuthentication yes

, a

Kód: [Vybrat]

AuthenticationMethods publickey same o sebe nestacilo. Tu som este pre istotu skusil pridat

Kód: [Vybrat]

PubkeyAcceptedAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256 ale stale bez zmeny.

Boli v sshd konfiguracii este nejake zasadne zmeny medzi tymito verziami?

[Reklama]

[k3dAR]

obecne bych doporucil:
- /etc/ssh/sshd_config vratit originalni a restartnout ssh sluzbu
- overit ze se z klienta pripojis
- do /etc/ssh/sshd_config.d/hknmtt.conf pridat ty tve volby zakomentovane
- zkouset je po jedne odkomentovat (a restartnout vzdy ssh sluzbu) abys zjistil s kterou mas problem ;-)

[Filip Jirsák]

Máte správně nastavená práva na složku a soubor s uživatelským klíčem? Jinak je dobré zvýšit na server úroveň logování, pak vám to do logu vypíše, zda se pokoušel klient přihlásit klíčem a proč to selhalo.

[Petr Krčmář]

Tohle nevypadá na problém na serveru, ale na problém s klíči. Tedy že se zkoušíte přihlašovat třeba k jinému účtu na serveru, kde ten klíč nemáte mezi autorizovanými. Nebo máte daný typ klíče zakázaný. Nebo ho klient nemůže načíst. Možností je spousta.

V takové situaci je nejlepší spustit klienta v upovídaném režimu, kdy vypisuje postupně všechny kroky, které dělá a všechny průběžné informace od serveru. Dozvíte se tam třeba, které klíče nabízel, proč byly serverem zamítnuty a jak to celé dopadlo.

Kód: [Vybrat]

$ ssh -vvvv petr@server.example.com

[hknmtt]

Bohuzial ani po par hodinach sa mi problem nepodarilo vyriesit. Skusal som manualne zbehnut kroky, ktore spustam skriptom(vytvorenie pouzivatela, nahratie ssh klucu..), ale bez editacie ssh konfiguracie, a islo to bez problemov. Ale po zmene proste nie. Na koniec som sa vratil na Ubuntu 22 a vsetko slape ako predtym, takze proste v 24 su nejake veci pomenene, na ktore neviem prist nijako.

[Reklama]

[RDa]

Me se nepozdavalo to UsePAM no, tak po chvilce googleni co tim admin mysli jsem nasel podobnou potiz jako mas ty:

https://serverfault.com/questions/475880/ssh-public-key-auth-fails-when-usepam-is-set-to-no

[hknmtt]

Me se nepozdavalo to UsePAM no, tak po chvilce googleni co tim admin mysli jsem nasel podobnou potiz jako mas ty:

https://serverfault.com/questions/475880/ssh-public-key-auth-fails-when-usepam-is-set-to-no

Preco by ale ta konfiguracia fungovala na Ubuntu 22.04 LTS ale uz nie na Ubuntu 24.04 LTS? Ta otazka ma 12 rokov, takze by to mal alebo nemal byt problem na oboch, nie len na jednom.

[RDa]

Me se nepozdavalo to UsePAM no, tak po chvilce googleni co tim admin mysli jsem nasel podobnou potiz jako mas ty:

https://serverfault.com/questions/475880/ssh-public-key-auth-fails-when-usepam-is-set-to-no

Preco by ale ta konfiguracia fungovala na Ubuntu 22.04 LTS ale uz nie na Ubuntu 24.04 LTS? Ta otazka ma 12 rokov, takze by to mal alebo nemal byt problem na oboch, nie len na jednom.

Se podivej do logu. Ubuntu neznam - je milion moznosti jak muze lepic distra podelat veci :)

Zapni jak na klientovi tak na serveru nejaky verbose/debug rezim a porovnej co se deje a kde se to zacne lisit.

[k3dAR]

Se podivej do logu. Ubuntu neznam - je milion moznosti jak muze lepic distra podelat veci

je to marny, je to marny, je to marny... tvurce Ubuntu samozrejme nic nepodelal, ten kdo neco podelal je jen a pouze tazatel/hknmtt... ;-)

Ignoruje co mu lidi radi/pisou, napr. ja sem mu napsal jasnej rychlej postup jak zjistit kde je problem...
On pak pise ze za nekolik hodin se mu to nepodarilo vyresit a nakonec se z 24.04 vratil na 22.,04...

Takze ja tomu venoval par minut, presne postup co sem mu psal a pokud nezatajil jeste nejakou jinou problemovou volbu, tak problem je v "AllowUsers foo", kdy bud se pripojije jinym uzivatelem nez "foo", nebo ten "foo" nema v ~/.ssh/authorized_keys spravny klic...
PROTOZE, jakmile sem vlozit jeho conf, tak "Permission denied (publickey).", jakmile sem zmenil "foo" na "k3dar" tak sem se pripojil, tzn. vsechny jeho ostatni volby fungujou bez problemu...