Klient je téměř ve všech distribucích, co jsem viděl, samostatný balíček. Takže i když ho někdo má nainstalovaný na přístup do embedded krabiček nebo třeba jako diagnostický nástroj, tak se ho ta chyba v serverové části netýká. U telnet serveru si, krom nějakých úplně specifických použití , nedokážu úplně představit, že by to mělo na běžném serveru nebo stanici využití.
telnetd je server – to „d“ je zkratka z „daemon“, obdobně je třeba httpd HTTP server (někde se tak jmenuje binárka Apache serveru).
Na běžném serveru nebo stanici se Telnet server obvykle nenajde, ale jak psal RDa, různá proprietární zařízení, která spoléhají na to, že se k nim po síti nikdo nepovolaný nedostane, to mít mohou.
Asi slabsi chvilka Michale? :D
Ahoj, to vůbec nevylučuju, v poslední době mám trochu pocit, že moje slabší chvilka trvá už docela dlouho :)
Ale tady nejsme v rozporu, možná jsem to jen blbě napsal. Myslel jsem to v podstatě stejně. Když už dneska někdo vůbec používá telnet protokol i přes ty bezpečnostní problémy, co jsi popsal, tak používá nejspíš jen klienta pro přístup třeba do těch starších zařízení (některé síťové prvky nebo třeba i AV technika, co se pomocí telnetu dala automatizovat, monitorovat) a ta zranitelnost telnetd na Linuxu se ho tedy vůbec netýká.
Vlastně jsem se vůbec nesetkal se zařízeními, co by se potřebovaly přihlašovat na obecný telnet server s pseudoterminály PTY jako telnetd. I když něco takového možná existuje.
Jediné snad byly průmyslové čtečky kódů, co se po startu rovnou připojily na předvolený telnet server a pak už se na displeji ovládaly přes aplikaci běžící terminálu na serveru. Ale na tom serveru stejně neběžel standardní systémový telnet, ale nějaká proprietární služba, co si přímo otevřela ty sockety, řešila přihlášení z jednotlivých zařízení, navazování předchozích přerušených spojení atp.