Poslední příspěvky

71

/dev/null / Re:V akom stave je Windows 11?

« Poslední příspěvek od tester3274 kdy 19. 10. 2025, 17:41:58 »

Je myslím naprosto zjevné, že školy univerzitního typu poskytují výuku spíše do šířky oproti školám neuniverzitním. V tomto smyslu význam jejich názvu platí doposud. To není žádný "trik", nýbrž konstatování faktu.

Zjevný pohled do studijních plánů dokazuje pravý opak. Většina technických oborů (Ing.) má mnohem širší záběr, více předmětů a více hodin týdně než obory na inverzitách klasického typu (mgr.). To platilo už před lety, kdy jsem studoval já, a dle letmého porovnání např. studijních plánů informatiky FIT vs. MUNI (někdo to tu dával jako příklad) to evidentně platí i dnes:
https://www.muni.cz/bakalarske-a-magisterske-obory/22955-informatika
https://www.fit.vut.cz/study/program/9500/.cs

72

/dev/null / Re:V akom stave je Windows 11?

« Poslední příspěvek od Marek Staněk kdy 19. 10. 2025, 15:41:07 »

V jakém stavu je W11?

• kdo ví, jak vás to sleduje

...[/list]

Widlo 11 jsou takové veřejné hajzlíky, prostě netušíte, co tam můžete chytnout, kdo vás sleduje a co se tam děje, když odejdete.

Takových systémů ale je spousta, dokonce nejspíš valná většina. Dtto dělá android, dtto chromeos, dtto MacOS a iOS, dtto Harmony, atd ad nauseam.
Dneska už není únosné to všechno řešit, celé je to založeno na důvěře. Většina distribucí linuxu deklaruje, že nic nesleduje, spousta jich ale telemetrii sbírá s odůvodněním, že jde o sběr chybových hlášení a technických dat používaného hardwaru. Teoreticky by to mělo být možné zkontrolovat, ale troufnu si tvrdit, že to prakticky nikdo nikdy neudělal, a opět se spoléhá na to, že tvůrci nebudou chtít zklamat důvěru (a s ohledem na velikost instalované báze to ani nebude stát za eventuální zisk). Stejně tak lze ale říci, že tomu komerčnímu výrobci porušení důvěry nebude stát za to tuplem, protože by tím ohrozil svůj byznys a bolelo by ho to mnohem víc, než garážového tvůrce úzce specializované distribuce pro pár lidí se zcela konkrétním use-casem.

Sečteno a podtrženo: nikdo nikoho nenutí to používat. A pokud to zaměstnavatel požaduje, nikdo zaměstnanci nebrání se sebrat a jít si vydělávat jinam.
Chápu, že se to spoustě lidí může nelíbit, ale ty nenávistný výlevy jsou úplně zbytečný a naprosto mimo mísu.
BTW ad to "kdo ví, jak vás to sleduje" ... když to teda NIKDO NEVÍ, proč ty žlučovitý výrony nenávisti? Na ulici TAKY nevíš, kdo a jak a v jakým rozsahu tě sleduje. Přitom ale nerantuješ, že s každým nechodí policajt, co by na všechny křičel ať na tebe nečumí, že TY chceš mít soukromí.

73

Server / Re:user@server.org: Permission denied (publickey). (SSH)

« Poslední příspěvek od kopevi2 kdy 19. 10. 2025, 15:14:06 »

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

74

Server / Re:user@server.org: Permission denied (publickey). (SSH)

« Poslední příspěvek od kopevi2 kdy 19. 10. 2025, 15:13:21 »

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

75

Server / Re:user@server.org: Permission denied (publickey). (SSH)

« Poslední příspěvek od RDa kdy 19. 10. 2025, 15:07:20 »

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)

76

Server / Re:user@server.org: Permission denied (publickey). (SSH)

« Poslední příspěvek od Ivan Brezina kdy 19. 10. 2025, 14:50:23 »

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.

77

Server / Re:user@server.org: Permission denied (publickey). (SSH)

« Poslední příspěvek od kopevi2 kdy 19. 10. 2025, 14:45:47 »

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

78

Server / Re:user@server.org: Permission denied (publickey). (SSH)

« Poslední příspěvek od RDa kdy 19. 10. 2025, 13:58:59 »

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.

79

Server / Re:user@server.org: Permission denied (publickey). (SSH)

« Poslední příspěvek od kopevi2 kdy 19. 10. 2025, 13:52:21 »

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

80

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

« Poslední příspěvek od kopevi2 kdy 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?