Ano ang SSH at Paano Ito Gumagana?

Ano ang SSH?

Ang SSH (secure shell) ay isang protocol para mag-log in sa computer na nasa ibang lokasyon at magpatakbo ng mga command dito sa pamamagitan ng encrypted connection. Ipinapadala ang tina-type mo sa remote machine, ibinabalik ang output nito, at hindi mababasa ng sinumang nagmo-monitor ng network sa pagitan ang alinman sa mga ito. Walang nakakabit na screen at keyboard ang isang nirentahang Linux server, kaya SSH ang ginagamit para ma-access at magamit ang machine.

Dalawang bagay ang tinutukoy ng pangalang ito. Ang SSH ay ang protocol na inilalarawan sa RFC 4251 hanggang RFC 4254. Ang OpenSSH ang program na nag-iimplement nito, at ito ang aktuwal na pinapatakbo ng halos lahat ng Linux server at halos lahat ng laptop. Kapag sinabing “mag-SSH sa server,” ang ibig sabihin ay nakikipag-ugnayan ang client program ssh sa machine mo sa server program sshd sa kabilang panig.

Ang problemang nilikha upang lutasin ng SSH

Mas nauna pa ang remote login kaysa SSH. Nagbukas ang Telnet ng plain TCP connection sa port 23 at ipinadala ang bawat byte kung paano ito eksaktong tina-type. Walang naka-encrypt, pati ang iyong password. Maaaring basahin ito ng sinumang nakakakita ng traffic: isang taong nasa kaparehong office network, o operator ng alinmang router sa dinaanan ng connection. Ganoon din ang kahinaan ng rlogin family. Pinagkakatiwalaan nito ang client machine batay sa pangalan, kaya pinagkakatiwalaan din nito ang anumang pangalang ipinapahayag ng network.

Isinulat ni Tatu Ylönen ang unang SSH noong 1995 sa Helsinki University of Technology, matapos magkaroon ng password sniffing attack sa university network. Pinanatili ng disenyo ang kapaki-pakinabang na bahagi ng Telnet—isang byte stream sa pagitan ng iyong terminal at remote shell—at idinagdag ang dalawang bagay na walang sagot ang Telnet: encryption ng stream, at patunay na ang server sa kabilang dulo ay ang server na talagang nais mong puntahan.

Madaling hindi mapansin ang ikalawang bahaging ito, ngunit kalahati ito ng SSH. Hindi ka sapat na mapoprotektahan ng encryption lamang. Maaaring tanggapin ng isang machine na nasa gitna ang iyong connection, i-encrypt ito nang tama, basahin ang lahat ng ipinapadala mo, at ipasa ito sa totoong server. Hinaharangan ito ng SSH sa pamamagitan ng pagbibigay sa bawat server ng permanenteng identity na tinatawag na host key, at pag-check nito sa bawat connection.

Paano gumagana ang client at server model

May dalawang program. Sa server, tuloy-tuloy na tumatakbo ang sshd at naghihintay ng mga connection. Sa machine mo, ang ssh ang gumagawa ng mga ito. Magkahiwalay na program ang mga ito na may magkahiwalay na configuration file. Ang pagkakalito sa dalawa ang pinakakaraniwang dahilan kung bakit walang epekto ang isang edit.

• Binabasa ng server ang /etc/ssh/sshd_config. Dito ino-off ang password login at sine-set ang listening port.
• Binabasa ng client ang /etc/ssh/ssh_config para sa system defaults, at pagkatapos ay ang ~/.ssh/config para sa sarili mong per-host settings.

Sa Debian at Ubuntu, ssh ang tawag sa service unit. Sa RHEL, Rocky, at Fedora, sshd naman ang tawag dito. Sa mga bagong release ng Ubuntu, socket activated ang installation nito. Kaya maaaring i-report ng systemctl status ssh ang inactive (dead) kahit ganap na reachable ang machine, dahil ssh.socket ang unit na nakikinig at awtomatikong nagsisimula sa service kapag kinakailangan.

Hindi kailangang OpenSSH ang client. Gumagamit din ang PuTTY sa Windows, Termius sa phone, at remote support na built in sa mga editor ng parehong protocol papunta sa parehong sshd. Kasama rin sa Windows 10 at 11 ang OpenSSH client, kaya gumagana ang ssh you@server sa PowerShell nang walang kailangang i-install.

Bakit port 22 ang ginagamit ng SSH?

Ang port ay isang numerong nagsasabi sa kernel kung aling listening program ang para sa isang papasok na connection. Pareho ang paggana ng mga port sa Linux para sa bawat service. Port 22 ang ginagamit ng SSH dahil itinalaga ito ng IANA noong 1995. Humingi si Ylönen ng libreng numero na katabi ng mga protocol na nilikha upang palitan ng SSH: ang 21 ay para sa FTP, ang 23 ay para sa telnet, at hindi ginagamit ang 22.

Dahil default ang 22, ipinapalagay ito ng lahat. Unang sinusubukan ng Git remote mo, backup script mo, at control panel ng provider mo ang 22. Gayundin ang bawat automated scanner sa internet. Ang bagong server na may naka-enable na password login ay nagsisimulang makatanggap ng mga linyang tulad nito sa /var/log/auth.log ilang minuto lang matapos mag-boot:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Tuloy-tuloy ang traffic na ito, at hindi ito partikular na nakatuon sa iyo. Kapag inilipat ang sshd sa port 2222, mawawala ang karamihan sa mga linyang iyon dahil ini-scan ng mga scanner ang buong internet sa port 22 sa halip na pag-aralan ang server mo. Hindi nito ginagawang mas mahirap pasukin ang machine para sa sinumang talagang sumusuri rito. Ituring ang pagpapalit ng port bilang pagbawas sa ingay at wala nang iba.

Maaari mong obserbahan kung paano sumasagot ang server bago ka pa mag-log in:

nc 203.0.113.10 22

Sa Ubuntu 24.04, magpi-print ito ng halos ganito sa SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. Ipinapadala ang banner bilang cleartext bago magkaroon ng anumang encryption dahil kailangang magkasundo ang magkabilang panig sa protocol version. Pindutin ang Ctrl+C upang isara ang connection.

Ano ang nangyayari sa network kapag kumokonekta ka

Ang sequence sa ibaba ang ginagawa ng isang ssh you@server bago mo makita ang prompt.

1. Nireresolba ng client ang hostname sa isang IP address, pagkatapos ay nagbubukas ito ng TCP connection sa port 22.
2. Ipinapadala ng magkabilang panig ang kanilang version banner sa cleartext.
3. Ipinapadala ng magkabilang panig ang mga listahan ng algorithm na sinusuportahan nila: key exchange, cipher, message authentication, at compression. Cleartext pa rin ang mga ito. Pinipili ang pinakamalakas na opsyong alam ng parehong panig.
4. Tumatakbo ang key exchange. Sa kasalukuyan, mas pinipili ng OpenSSH ang curve25519-sha256. Parehong nagkakaroon ang magkabilang endpoint ng iisang shared secret nang hindi kailanman dumadaan sa network ang secret na iyon, kaya hindi ito makukuwenta kalaunan ng sinumang nag-record ng buong pag-uusap.
5. Sini-sign ng server ang resulta ng exchange gamit ang host private key nito. Sinusuri ng client mo ang signature laban sa host public key na naka-save nito. Ito ang hakbang na pumipigil sa isang machine sa pagitan na magpanggap bilang server mo.
6. Nagsisimula ang encryption. Ang chacha20-poly1305@openssh.com ang default cipher sa kasalukuyang OpenSSH.
7. Ngayon lamang ina-authenticate ng client ang user gamit ang password o key. Dumadaan ang username at password sa loob ng encrypted channel.
8. Nagbubukas ang client ng channel at humihingi ng shell.

Ang pagkakasunod-sunod sa listahang iyon ang buong kaibahan nito sa telnet. Nangyayari ang authentication matapos ma-encrypt ang channel at matapos mapatunayan ng server ang identity nito. Kaya walang sandali na nakalantad sa network ang password mo.

May matututunan pa rin ang sinumang nagmo-monitor ng network. Makikita nila ang IP address mo, ang IP address ng server, port 22, ang dalawang cleartext version banner, at ang timing at tinatayang laki ng bawat packet. Hindi nila makikita ang username mo, password mo, commands mo, o output ng mga ito. Ang hostname lookup sa step 1 ay hindi bahagi ng SSH at karaniwang hindi private, kaya maaaring ibunyag ng DNS query na nagre-resolve sa pangalan ng server mo kung aling machine ang kokonektahan mo kahit nananatiling sealed ang session.

Ang host key at ang prompt para sa fingerprint sa unang connection

Kapag naka-install ang openssh-server, gumagawa ito ng host key pair para sa machine at isinusulat ang mga ito sa /etc/ssh/, gaya ng ssh_host_ed25519_key at ssh_host_ed25519_key.pub. Hindi kailanman lumalabas sa server ang private half. Ang public half ang identity ng server, at dito ikinukumpara ang signature sa step 5.

Sa unang pag-connect mo sa isang bagong server, wala pang maikukumpara ang client, kaya tinatanong ka nito:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ang fingerprint ay SHA256 hash ng host public key na naka-print sa base64, kaya sapat ang ikli nito para maikumpara nang manu-mano. Kapag nag-type ka ng yes, isinusulat nito ang key sa ~/.ssh/known_hosts sa sarili mong machine. Sa bawat susunod na connection sa parehong address, ikinukumpara ang key na iniaalok ng server sa naka-store na key. Kapag magkatugma ang mga ito, walang napi-print at diretso kang mapupunta sa prompt.

Tinatawag na trust on first use ang modelong ito, at dapat malinaw kung ano ang kapalit nito. Ang unang connection ang tanging sandali na hindi ka protektado, dahil tumatanggap ka ng key na hindi mo pa nakikita. Para maalis ang puwang na ito, kunin ang fingerprint sa ibang paraan at paghambingin ang mga ito. Karamihan sa provider ay nagpi-print nito sa boot output na ipinapakita sa kanilang web console, at maaari mo rin itong i-print sa server mismo:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Ipi-print nito ang parehong SHA256: string na ipinakita sa prompt. Ang pagpipiliang [fingerprint] sa prompt ay para mismo rito: i-paste ang fingerprint na inaasahan mo, at magpapatuloy lang ang client kung tumutugma ito sa ipinakita ng server.

Sa Debian at Ubuntu, naka-hash bilang default ang known_hosts, kaya naglalaman ang file ng mga linyang nagsisimula sa |1| sa halip na mga hostname na madaling basahin. Patakbuhin ang ssh-keygen -F 203.0.113.10 para mahanap ang entry para sa isang host.

Bakit sinasabing nagbago ang host key ng SSH?

Sa kalaunan, makikita mo ang ganitong mahabang mensahe:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Nagtatapos ito sa Host key verification failed. at tumatangging kumonekta ang client. Ipinapakita rin nito ang Password authentication is disabled to avoid man-in-the-middle attacks., dahil ang paglalagay ng password mo sa isang hindi kilalang machine ang mismong panganib na pinipigilan ng check na ito.

Mukhang emergency ang mensahe, pero kadalasan ay hindi naman. Karaniwang mga sanhi:

• Ni-rebuild o ni-reinstall mo ang server, kaya bumuo ang sshd ng mga bagong host key sa unang boot. Ito ang pinakakaraniwang dahilan.
• Binura mo ang isang VPS at gumawa ng bago, at ibinigay ng provider sa bagong machine ang dating IP address.
• Kumokonekta ka sa pamamagitan ng forward o load balancer na ngayon ay napupunta sa ibang backend machine.
• May totoong humaharang o sumasagap sa koneksyon.

Tukuyin muna kung alin dito ang dahilan bago ka mag-clear ng anuman. Kung ni-reinstall mo ang machine sampung minuto ang nakalipas, malinaw ang sanhi. Kung walang nagbago sa panig mo, huminto at magsiyasat, dahil gumagana ang check na ito ayon sa layunin nito. Kapag nakatiyak ka na, alisin ang stale entry at kumonekta muli:

ssh-keygen -R 203.0.113.10

Sa susunod na koneksyon, ipapakita muli ang fingerprint prompt. Magkakaroon ka ng panibagong pagkakataong ikumpara ito sa provider console.

Password login kumpara sa key login

Ipinapadala ng password authentication ang iyong password sa loob ng naka-encrypt nang channel, at sinusuri ito ng sshd laban sa account database, karaniwan sa pamamagitan ng PAM (pluggable authentication modules). Wala itong kailangang paghahanda. Kaya maaaring ibigay sa iyo ng isang provider ang bagong server na may root password lamang.

Hindi ang encryption ang kahinaan. Ang problema ay maikli lamang na secret ang password, ipinapadala mo ito sa server sa bawat login, at buong magdamag na hinuhulaan ang port 22 ng mga machine na hindi napapagod.

Iba ang paraan ng public key authentication. Gumagawa ka ng key pair sa sarili mong machine. Inilalagay ang public half sa ~/.ssh/authorized_keys sa loob ng account mo sa server. Nananatili ang private half sa iyong laptop at hindi ito kailanman ipinapadala. Para mag-login, lumalagda ang client sa isang data piece na kasama ang session identifier mula sa key exchange, at bine-verify ng server ang signature gamit ang public key na hawak na nito. Dahil nakatali ang nilagdaang data sa session na ito, walang silbi ang nakuhang signature laban sa iba pang session.

Tandaan ang direksyon dahil karaniwang nababaligtad ito at mapanganib ang resulta: nasa server ang public key, at nasa iyo ang private key. Ang private key na nakopya sa server ay private key na hindi mo na mapagkakatiwalaan.

May sarili ring mga failure mode ang key login. Binabalewala ng sshd ang mga key kapag masyadong maluwag ang file permissions, at ipinapakita nito iyon sa server log:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Ang sinasabi lamang sa iyo ng client ay Permission denied (publickey). Pareho ang mensaheng ito para sa dose-dosenang posibleng sanhi, kaya mahalagang matutunang basahin nang tama ang publickey error bago ka ma-lock out. Ang praktikal na gawain ng paggawa ng mga key, pagprotekta sa mga ito gamit ang passphrase, at pag-load sa mga ito sa isang agent ay nasa pamamahala ng SSH key. Ang pag-disable ng password login nang hindi naiiwan ang sarili mong walang access ay nasa pag-hardening ng SSH sa isang VPS.

SFTP, scp at port forwarding ay gumagamit ng iisang connection

Narito ang ideyang nagpapalinaw sa iba pang bahagi ng SSH. Nagbubukas ang authentication ng naka-encrypt na connection, at maaaring magdala ang connection na iyon ng ilang independent channel nang sabay-sabay. Isang uri lamang ng channel ang shell.

• Remote shell. Binubuksan ng ssh you@server ang isang session channel at humihingi ito ng interactive shell.
• Isang command. Binubuksan ng ssh you@server uptime ang isang channel, nagpapatakbo ng isang command, ipinapakita ang output, at lumalabas.
• SFTP. Hinihiling ng client sa sshd na simulan ang sftp subsystem nito, at tumatakbo ang file transfer sa loob ng parehong connection. Ang SFTP ay isang file transfer protocol na gumagamit ng SSH, at wala itong kaparehong disenyo ng FTP. Ang protocol na FTP na nilagyan ng encryption ay tinatawag na FTPS, at wala itong kaugnayan sa SFTP.
• scp. Kumokopya ito ng mga file gamit ang parehong login. Mula OpenSSH 9.0, na inilabas noong 2022, ginagamit ng scp ang SFTP protocol sa ilalim bilang default.
• Port forwarding. Ginagawang daanan ng ssh -L 8080:localhost:80 you@server ang port 8080 sa iyong laptop patungo sa port 80 sa server, sa loob ng naka-encrypt na connection. Nagfo-forward naman si -R sa kabilang direksiyon, at ginagawang SOCKS proxy ng -D 1080 ang session.
• Git. Ang remote gaya ng git@github.com:user/repo.git ay isang SSH login kung saan nagpapatakbo ang remote side ng command handler sa halip na shell.
• Mga SSH client din ang rsync at Ansible. Nagbubukas ang mga ito ng channel, nagpapatakbo ng isang bagay, at binabasa ang output pabalik.

Gumagamit ang bawat item sa listahan ng parehong port, parehong host key check, at parehong credentials. Kaya sulit agad ang pag-set up ng key authentication nang isang beses: awtomatikong ginagamit ito ng bawat tool na iyon. Ito rin ang dahilan kung bakit ang parehong ~/.ssh/config file na nagpapaiikli sa iyong mga login ang ginagamit kapag mas marami na ang pinamamahalaan mong ilang Linux server mula sa isang laptop.

Ano ang hindi ginagawa ng SSH

• Hindi nito ginagawang secure ang iyong server. Pinoprotektahan ng SSH ang path papunta sa pintuan. Nariyan pa rin ang pintuan, at patuloy na susubukan ng mga tao ang handle nito. Tinutugunan ng Pag-block sa paulit-ulit na login attempt gamit ang fail2ban ang dami ng mga pagtatangka, habang inaalis ng key-only authentication ang bagay na sinusubukan nilang hulaan.
• Hindi ka nito pinoprotektahan laban sa sarili mong machine. Ang sinumang may access sa iyong laptop ay may private key at loaded agent mo.
• Hindi nito itinatago na gumagamit ka ng SSH. Ipinapakita ito ng port number at ng cleartext version banner.
• Hindi nito sinasaklaw ang mga nangyayari bago maitatag ang connection. Nauuna ang name lookup at ang desisyon mo kung aling address ang pagkakatiwalaan.

Saan susunod na pupuntahan

Kung may bago kang server na kasalukuyang bukas sa provider console, nakatakda na ang praktikal na pagkakasunod-sunod. Mag-access, gumawa ng normal na user, i-install ang iyong key, at pagkatapos ay isara ang mga madaling daanan para sa pag-access. Sinasaklaw ng Ang unang sampung minuto sa bagong VPS ang pagkakasunod-sunod na iyon mula simula hanggang dulo. Ipinapaliwanag naman ng kung ano talaga ang VPS ang machine sa likod nito kung bago pa sa iyo ang mga termino. Pagkatapos nito, basahin ang mga post tungkol sa keys at hardening, sa ganitong pagkakasunod-sunod.

FAQ

Ano ang ibig sabihin ng SSH?

Ang SSH ay nangangahulugang secure shell. Isa itong protocol para mag-log in sa remote computer at magpatakbo ng mga command dito sa pamamagitan ng encrypted connection, ayon sa depinisyon sa RFC 4251 hanggang RFC 4254. Ang OpenSSH ang implementation na halos lahat ay gumagamit: ang ssh client sa iyong machine at ang sshd server sa remote machine. Pinalitan nito ang telnet, na nagpapadala ng lahat, kabilang ang mga password, sa network bilang plain text.

Bakit gumagamit ang SSH ng port 22?

Itinalaga ng IANA ang port 22 para sa SSH noong 1995, kasunod ng FTP sa 21 at telnet sa 23—ang mga protocol na nilikha nitong palitan. Walang nag-uutos na gamitin ang numerong iyon: binabago ito ng Port sa /etc/ssh/sshd_config sa server, at pumipili ng ibang port ang ssh -p sa client. Dahil default ang 22, palaging sinusuri ito ng mga automated scanner. Kaya napupuno ang /var/log/auth.log ng bagong server ng mga linya mula sa Failed password for invalid user. Binabawasan ng pagpapalit ng port ang ingay na ito, pero wala itong tunay na idinadagdag na proteksiyon.

Ano ang dapat kong gawin kapag nagbabala ang SSH na nagbago ang host key?

Alamin muna ang sanhi bago mag-clear ng anuman. Karaniwang hindi nakapipinsala ang dahilan: maaaring ni-rebuild ang server kaya bumuo ang sshd ng mga bagong host key, o maaaring may bagong machine na binigyan ng dating IP address. Kung alam mong ni-rebuild ang machine, patakbuhin ang ssh-keygen -R <host> upang alisin ang naka-store na key, kumonekta muli, at ihambing ang fingerprint na ipinapakita sa iyo sa fingerprint na ipinapakita ng provider console mo. Kung walang nagbago sa panig mo, huwag kumonekta at huwag i-type ang iyong password. Tumatanggi na ang OpenSSH sa password authentication sa ganitong sitwasyon dahil mismo sa dahilang iyon.

Magkaiba ba ang SFTP at scp sa SSH?

Tumatakbo ang mga ito sa ibabaw ng SSH. Pagkatapos mong mag-authenticate, maaaring magdala ang SSH connection ng ilang channel, at isa lamang sa mga ito ang shell. Ang SFTP ay file transfer protocol na gumagamit ng sftp subsystem ng sshd sa parehong connection. Ginagamit na rin ng scp ang SFTP protocol sa ilalim nito mula noong OpenSSH 9.0. Mga channel din sa parehong connection ang port forwarding at Git over SSH. Pare-pareho silang gumagamit ng parehong port, parehong host key check, at parehong login. Tandaan na hindi FTP na nilagyan ng encryption ang SFTP. FTPS ang tawag sa FTP na may encryption, at hiwalay itong protocol.

Mas mabuti ba talaga ang key authentication kaysa password?

Oo, para sa anumang server na naaabot mula sa internet. Ang password ay maikling secret na ipinapadala mo sa server sa bawat login, at patuloy itong hinuhulaan ng mga automated client sa port 22. Kapag key pair ang ginamit, hindi umaalis sa machine mo ang private half: nagsa-sign ang client ng data na nakatali sa kasalukuyang session, at tinitingnan ng server ang signature na iyon laban sa public key sa ~/.ssh/authorized_keys. Hindi maaaring i-replay sa ibang server ang na-record na signature. Protektahan ang private key gamit ang passphrase, dahil ang key file na walang passphrase ay gumaganang login para sa sinumang makakopya nito.