Paano Naiiba ang SSH Sa Telnet?


Buod: Ang TELNET ay walang anumang encryption, kaya lahat ay ipinadala sa plaintext. Ang SSH ay naka-encrypt, kaya ito ay pribado at secure. Iyon ang dahilan kung bakit ang SSH ay dapat gamitin sa kagustuhan sa TELNET.

Parehong hinahayaan ka ng SSH at TELNET na kumonekta sa malayuan, naka-network na mga computer at gamitin ang mga ito na parang nakaupo ka sa harap nila. Kaya ano ang pagkakaiba sa pagitan ng dalawang kagalang-galang na protocol na ito, at talagang palaging may bentahe sa paggamit ng SSH sa TELNET?

TELNET at SSH: The Origin Story

Ang pangangailangan ay ang ina ng imbensyon. Ang mga administrator ng system ay nangangailangan ng isang paraan upang ma-access at pamahalaan ang mga computer na pisikal na matatagpuan sa ibang lugar. Kung hindi praktikal o hindi maginhawa para sa administrator na iposisyon ang kanilang sarili sa harap ng computer, kailangan nila ng isang paraan upang ma-access ang remote na computer na nagpapahintulot sa kanila na mag-isyu ng mga command na parang tina-type nila ang mga ito sa computer na iyon.

Ang TELNET, maikli para sa teletype over network protocol, ay binuo noong 1969 bilang sagot sa problemang iyon. Hangga't ang malayong computer ay naa-access sa network, pinapayagan nito ang administrator, o sinumang iba pang awtorisadong tao, na kumonekta dito at gamitin ito na parang pisikal na pinindot nila ang mga key ng remote na keyboard.

Ang SSH ay nilikha sa ibang pagkakataon—noong 1995—bilang isang direktang tugon sa Telnet at iba pang katulad na mga solusyon. Ang pangangailangan sa oras na ito ay seguridad. Ang TELNET, rlogin, FTP, at iba pang mga protocol sa panahong iyon ay idinisenyo nang walang anumang pagsasaalang-alang sa, o inaakalang pangangailangan para sa, seguridad.

Ang SSH ay nangangahulugang secure shell, kaya makikita mo na ang seguridad ay isang gabay na prinsipyo mula sa simula nito. Sa ngayon, halos napalitan na ng SSH ang TELNET.

Ang TELNET ay isang Plaintext Security Bangungot

Ang malaking problema sa TELNET ay gumagamit ito ng plaintext. Hindi nito ine-encrypt ang alinman sa trapiko nito, kabilang ang mga user name at password. Anumang bagay na ipinadala nito sa network ay maaaring makuha sa pamamagitan ng packet sniffing at basahin, nang may pinakamadaling paraan. Isa itong panganib sa seguridad kahit sa isang lokal na network, maliban kung ikaw lang ang gumagamit. Maaaring harangin ng sinumang user ang trapiko ng TELNET at makakuha ng mga kredensyal sa pag-log in na wala silang karapatan.

Kung ang malayong computer ay nasa labas ng site, na nangangailangan ng isang koneksyon na gawin sa buong internet upang maabot ito, ang problema ay pinalaki nang hindi masusukat. Ang TELNET ay isang produkto ng kanyang panahon, at upang maging patas sa kanila, halos tiyak na hindi inaasahan ng mga may-akda na gagamitin ito ng mga tao sa loob ng limampung taon pagkaraan, sa napaka-ibang IT landscape ngayon.

Bagama't karapat-dapat ang TELNET sa lugar nito sa listahan ng mahahalagang programa na sama-samang tumulong na dalhin tayo sa kung nasaan tayo ngayon, hindi ito isang bagay na dapat pa rin nating gamitin sa mundo ngayon.

Paano Naiiba ang SSH Sa TELNET?

Sa mukha nito, ang TELNET at SSH ay dalawang sagot sa parehong problema. Pareho silang hinahayaan kang ma-access ang isang terminal window sa isang malayuang computer at magbigay ng mga utos dito. Ngunit dahil ang SSH ay binuo nang mas huli kaysa sa TELNET, ang problema ay mas lubusang naunawaan, at ang sagot ay mas mahusay na ininhinyero.

Ang TELNET ay idinisenyo nang nasa isip ang pribado mga network, ngunit ang SSH ay idinisenyo upang makayanan ang mga pampubliko network, at ang pangangailangang mapanatili ang privacy at seguridad kapag naglilipat ng data at gumagawa ng malayuang koneksyon.

Gumagamit ang TELNET ng port 23 at hindi mababago ang numero ng port na iyon. Bilang default, gumagamit ang SSH ng port 22, ngunit maaari itong i-configure at baguhin. Ang pag-configure ng SSH upang gumamit ng hindi halatang numero ng port ay nagpapahirap sa mga umaatake na tukuyin ang SSH port. Kung matutukoy ang SSH port, isang maliit na bagay na mag-mount ng isang malupit na pag-atake kung saan libu-libong mga password na na-ani mula sa mga paglabag sa data ay sinubukan naman, sa pamamagitan ng automated na software.

Kahit na mas mabuti, ang SSH ay maaaring magbigay ng mga password sa kabuuan. Maaari itong gumamit ng public key encryption para mag-authenticate sa mga malalayong computer. Ang mga password ay hindi kailanman ipinapadala, dahil hindi na kailangang ipadala ang mga ito sa malayong computer. Ang data encryption at SSH key authentication nito ay nangangahulugan na ang SSH ay nakakapaghatid ng mga secure na koneksyon at komunikasyon sa mga hindi secure na network tulad ng internet.

Sa katunayan, ang SSH ay maaaring gamitin upang magpatotoo sa iba't ibang mga serbisyo, hindi lamang sa mga malalayong computer na nagpapatakbo ng isang SSH server. Halimbawa, maa-access mo ang GitHub, GitLab, at BitBucket na naka-host na mga Git repository gamit ang SSH sa halip na mga password.

Ang isa pang bentahe sa paggamit ng SSH sa TELNET ay ang SSH ay maaaring gumawa ng reverse SSH tunneling. Kinakailangan nito ang server na magtatag ng koneksyon sa computer ng kliyente. Hanggang sa nais ng lokal na gumagamit na gumawa ng isang koneksyon sa server, ang koneksyon ay hindi papansinin.

Kapag nais ng kliyente na kumonekta sa server, ang gumagamit ay nagtatatag ng koneksyon sa SSH sa kanilang sariling computer. Ipinapadala ng SSH ang koneksyon pababa sa naitatag na koneksyon, sa server. Nagbibigay ito ng pribadong tunnel sa loob ng naka-encrypt na koneksyon mula sa server patungo sa kliyente.

Ang tanging panalo para sa TELNET ay gumagamit ito ng mas kaunting bandwidth. Ngunit hindi ito 1969 kung saan kakaunti ang bandwidth, at ang SSH ay hindi rin eksaktong bandwidth hog.

Nagkaroon din ng mga Problema ang SSH

Bagama't nahihigitan ng SSH ang TELNET pagdating sa seguridad, kailangan nating tandaan na ito ay software pa rin, at maaaring magkaroon ng mga bug ang software. Ang mga bug na iyon ay maaaring humantong sa mga kahinaan na maaaring pagsamantalahan ng mga cybercriminal. Gayundin, nagbabago ang mga pamantayan at algorithm ng pag-encrypt sa paglipas ng panahon, at napapalitan. Tulad ng lahat ng software na nakabatay sa pag-encrypt, bilang mga mas lumang bersyon ng edad ng SSH, maaari silang maging mas ligtas. Kaya naman mahalagang tiyaking ginagamit mo ang pinakabagong release ng SSH.

Ang bersyon ng SSH na ginagamit sa karamihan ng mga Linux computer ay OpenSSH, isang pagpapatupad ng SSH na binuo sa OpenSSL toolkit at mga aklatan. Noong 2012, ang OpenSSL library ay hindi sinasadyang nagpakilala ng isang bug na nagpapahintulot sa isang umaatake na humiling ng tugon mula sa SSL server, at upang tukuyin kung gaano karaming data ang ilalagay sa sagot.

Maaari silang humiling ng tugon na (sabihin) 64KB kapag ang aktwal na tugon ay mangangailangan ng hindi hihigit sa 64 byte. Ang unang pagkakasunud-sunod ng mga byte sa data na iyon ay ang tunay, inaasahang tugon, na sinusundan ng anumang nangyari sa memorya na ginamit kamakailan ng OpenSSL. Ang nilalaman ng data na iyon ay pot luck, ngunit maaari itong maglaman ng sensitibong impormasyon tulad ng session cookies at mga password, o iba pang impormasyon na nagpapahintulot sa isang umaatake na makakuha ng mga pribadong key, halimbawa.

Kapag nadiskubre ito, noong 2014, nakilala ang kahinaan bilang Heartbleed. Mabilis itong naayos sa software. Gayunpaman ang kahinaan ay hindi nawawala sa puntong iyon. Ang kahinaan ay ganap na mapawalang-bisa kapag ang lahat ng mga computer na nagpapatakbo ng mahinang software ay may naka-install na nakapirming bersyon. Sa madaling salita, kapag ang mga computer ay na-patch. Dahil maraming administrador ang mabagal na mag-react, mabagal ang paggamit ng nakapirming software.

Nakababahala rin ang dalawang taon sa pagitan ng 2012 kung kailan ipinakilala ang bug at 2014 nang ito ay natuklasan, at natugunan. Para sa dalawang taon na iyon, ang bawat SSH server na nagpapatakbo ng mahinang bersyon ng OpenSSL ay nasa panganib.

Upang maging patas, nangyari iyon halos isang dekada na ang nakalipas, at mula noon ay nagkaroon ng maraming paglabas, pagpapahusay, pag-aayos ng bug at pagsusuri ng code.

Dapat Mo bang Gumamit ng SSH o TELNET?

Mahirap mag-isip ng dahilan kung bakit kailangan mong gumamit ng TELNET ngayon. Hindi iyon katulad ng pagsasabi kung mayroong anumang senaryo kung saan ligtas na gamitin ang TELNET. Sa isang self-contained na network na hindi konektado sa labas ng mundo, at sigurado kang walang mag-packet-sniff sa iyong trapiko, maaari mong gamitin ang TELNET. Ngunit walang dahilan para. Ang trade-off ng seguridad ay hindi mabibigyang katwiran.

Ang SSH ay mas secure at mas nababaluktot—iyan ang kalamangan sa paggamit ng SSH kaysa sa TELNET. Ang pagpapatupad ng OpenSSH ay libre para sa lahat ng paggamit kabilang ang komersyal, at magagamit para sa lahat ng mga sikat na operating system.