SSH Keys: Basic Setup at Tamang Pag-manage

Paano gumagana ang SSH keys

Ang SSH key ay pares ng files: isang private key na nananatili sa device mo at isang public key na kino-copy mo sa bawat server na gusto mong pasukan. Kapag kumonekta ka, ginagamit ng server ang public key para magpadala ng challenge na masasagot lang ng katugmang private key. Hindi kailanman umaalis sa device mo ang private key, kaya walang secret na ipinapadala sa network at walang kapaki-pakinabang na makukuha ang isang breached na server. Kaya mas mainam ang keys kaysa passwords. Ang maayos na pag-manage ng SSH keys ay nakabatay sa apat na gawain: isang key bawat device, ang file permissions na hinihingi ng sshd, isang ~/.ssh/config file para hindi mo na kailangang paulit-ulit mag-type ng options, at ang pag-alam kung paano mag-alis ng key sa araw na mawala ang laptop.

Sinasaklaw ng guide na ito ang bawat gawain sa Ubuntu 24.04, pero halos lahat ng nakasaad dito ay naaangkop sa anumang Linux server at anumang kamakailang OpenSSH.

May isang terminong dapat linawin bago tayo magsimula dahil nakaiiwas ito sa totoong mga pagkakamali. Hindi secret ang public key. Maaari mo itong i-paste sa isang ticket, ipadala sa email, o i-publish, at walang makaka-login gamit ito. Ang private key ang secret. Ang sinumang kumopya sa file na iyon at nakakaalam ng passphrase nito kung mayroon man ay maituturing na ikaw sa pananaw ng mga server mo.

Gumawa ng key: ang ed25519 ang tamang default

Sa sarili mong computer, hindi sa server, patakbuhin ang:

ssh-keygen -t ed25519 -C "laptop"

Tinutukoy ng -t ed25519 ang uri ng key. Ang Ed25519 ang modernong default: maikli ang mga key, mabilis, at suportado ng bawat OpenSSH release mula pa noong 2014. Gamitin lamang ang ssh-keygen -t rsa -b 4096 kapag kailangan mong kumonekta sa lumang device na hindi nakauunawa ng ed25519. Nagtatakda ang -C "laptop" ng comment. Walang cryptographic na gamit ang comment, pero dito mo makikilala ang key na ito sa authorized_keys file ng server pagkalipas ng dalawang taon. Kaya pangalanan ang device na kinaroroonan ng key.

Itinatanong ng ssh-keygen kung saan ise-save ang key. Tanggapin ang default na ~/.ssh/id_ed25519. Pagkatapos, hihingi ito ng passphrase. Magtakda nito; ipinapaliwanag sa seksyon tungkol sa passphrase sa ibaba kung bakit wala itong dagdag na abala sa pang-araw-araw na paggamit. Magkakaroon ka ng dalawang file: ang ~/.ssh/id_ed25519 ang private key, at ang ~/.ssh/id_ed25519.pub ang public key. Tingnan ang public half:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Isang linya lamang ito: ang uri ng key, ang key material, at ang comment mo. Ang linyang ito ang ilalagay sa mga server mo.

Isang key bawat device, hindi isa bawat server

Ang unang tanong ng lahat: kailangan ba ng bagong key para sa bawat server? Hindi. Gumawa ng isang key para sa bawat device na ginagamit mong mag-type, at ilagay ang public key na iyon sa bawat server na kailangang maabot ng device. Tinutukoy ng key ang device. Ang authorized_keys file sa bawat server ang listahan ng mga device na pinapayagang makapasok.

Ito ang modelong madaling i-scale, at palaging may mahuhulaang problema ang mga alternatibo. Kapag isang key bawat server, ang laptop na kumokonekta sa 20 server ay magdadala ng 20 private key, at mawawala sa iyo ang track kung alin ang para sa alin. Mas masama ang isang key na ibinabahagi ng lahat ng device: kapag nanakaw ang laptop, hindi mo mai-revoke ang laptop nang hindi rin bina-block ang desktop, dahil pareho silang may hawak ng parehong private key. Kaya kailangan mong palitan ang key sa lahat ng server at sabay-sabay itong i-distribute sa bawat device.

Sa isang key bawat device, isang line bawat server lang ang kailangang baguhin kapag nawala ang laptop: i-delete ang line ng laptop mula sa authorized_keys, at patuloy na gagana ang lahat ng iba pang device. Ang comment na sine-set mo gamit ang -C ang nagpapadali sa paghahanap sa line na iyon.

Ito ang patakaran sa likod ng modelong ito: ginagawa ang private key sa isang device at namamatay ito kasama ng device na iyon. Huwag kailanman kumopya ng private key sa pangalawang machine, at huwag kailanman mag-upload nito sa server. Kapag kailangan ng bagong device ng access, gumawa ng bagong key dito.

Ilagay ang public key sa server

Ang pinakamadaling paraan ay ang ssh-copy-id, na kasama sa OpenSSH:

ssh-copy-id matt@10.0.0.10

Nagla-log in ito gamit ang anumang login method na gumagana pa, karaniwang password. Idinadagdag nito ang public key mo sa ~/.ssh/authorized_keys sa server. Ginagawa rin nito ang directory at file na may tamang permissions kung wala pa ang mga ito. Subukan ito sa pamamagitan ng pagbukas ng bagong SSH session. Dapat kang papasukin ng server nang hindi hinihingi ang password ng account. Kung may passphrase ang key mo, maaaring iyon ang hingin ng sarili mong machine. Local ang prompt na iyon at hindi iyon ang password ng server.

Kapag naka-disable na ang password login, hindi makakapasok ang ssh-copy-id. Kaya kailangan mong manu-manong idagdag ang line. Mag-log in gamit ang session na gumagana pa, o gamitin ang web console ng provider mo, at patakbuhin ito sa server:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

I-paste ang aktuwal mong public key sa loob ng quotes. Gamitin ang buong single line mula sa id_ed25519.pub. Isang public key bawat line ang authorized_keys. Ito ang buong access database: ang pagdaragdag ng device ay pagdaragdag ng isang line, at ang pag-revoke ng device ay pagbura ng isang line. Sa bagong server, dapat gawin ang hakbang na ito sa unang 10 minuto sa bagong VPS, bago mo i-disable ang password login.

Mga permission na nakakasira sa key login

Ito ang pinakakaraniwang dahilan kung bakit nabibigo ang key login, at hindi ito malinaw na ipinapakita sa client side. Ang sshd ay tumatakbo gamit ang StrictModes yes bilang default sa Ubuntu 24.04. Ibig sabihin, tumatanggi itong gumamit ng authorized_keys file na maaaring baguhin ng ibang user. Kung maaaring sulatan ng sinumang hindi ikaw ang file, ang ~/.ssh directory, o ang iyong home directory, hindi pinapansin ng sshd ang key mo at bumabalik sa paghingi ng password. Walang paliwanag na ipinapakita sa client. (May isang partikular na exception na pinapahintulutan ng Ubuntu's OpenSSH: maaaring writable ng group ang file kung ang group ay sarili mong private group at walang ibang kasapi rito. Huwag itong gamitin bilang batayan; gamitin ang mga mode sa ibaba.) Sa server log lamang makikita ang dahilan:

sudo grep 'Authentication refused' /var/log/auth.log

Sa minimal image na walang rsyslog, walang auth.log; nasa journal ang parehong linya: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

Ang ayos ay binubuo ng dalawang pagbabago sa permission at isang ownership check. Patakbuhin ito sa server bilang user na apektado:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

Ang dapat tandaan: 700 sa .ssh directory, at 600 sa lahat ng nasa loob nito. Pareho ring ginagamit ang mga numerong ito sa sarili mong computer dahil nagsasagawa rin ng check ang client. Kapag mababasa ng ibang user ang private key, tuluyang tinatanggihan ito ng ssh. Sa pagkakataong ito, malinaw na ipinapakita ang error:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

Inaayos ito ng chmod 600 ~/.ssh/id_ed25519.

~/.ssh/config: itigil ang paulit-ulit na pag-type ng options

Ang ~/.ssh/config file sa sarili mong computer ang nagbibigay ng maikling pangalan sa bawat server at nagse-save ng mga option na palagi mong tina-type. Gawin ito gamit ang 600 permissions at magdagdag ng Host block para sa bawat server:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Ngayon, pinapalitan ng ssh web1 ang ssh -p 22 matt@10.0.0.10, at gumagana ang parehong maikling pangalan sa scp, rsync, at git dahil binabasa nilang lahat ang file na ito. Ang HostName ang aktuwal na address, tinatanggal ng User ang pangangailangang i-type ang account name, at itinatakda ng IdentityFile kung aling key ang iaalok.

Nararapat banggitin ang IdentitiesOnly yes dahil nilulutas nito ang isang nakalilitong failure. Kapag maraming key ang hawak ng agent, isa-isa itong iniaalok ng client, at binibilang ng server ang bawat offer bilang failed attempt. Kapag sapat ang dami ng naka-load na key, matatanggap mo ang Received disconnect: Too many authentication failures bago pa man subukan ang tamang key. Pinapagawa ng IdentitiesOnly yes sa client na ang key lamang na tinukoy sa IdentityFile ang i-alok, kaya hindi mangyayari ang failure na ito.

Mga Passphrase at ssh-agent

Ini-encrypt ng passphrase ang private key file sa disk. Kung walang passphrase, magagamit agad ito ng sinumang makakakopya sa file; kung mayroon, walang silbi ang nanakaw na file hangga't hindi nahuhulaan ang passphrase. Para sa key na nasa laptop, ito mismo ang proteksiyong kailangan mo dahil nananakaw ang mga laptop at maaaring ma-leak ang mga backup ng mga ito.

Walang praktikal na dagdag na gastos ang paggamit ng passphrase dahil sa ssh-agent. Hawak ng agent sa memory ang iyong decrypted key. Kaya isang beses mo lang ita-type ang passphrase sa bawat login session, at instant na ang bawat kasunod na connection. May agent na agad na tumatakbo para sa iyo ang karamihan sa desktop Linux distributions at macOS. I-load ang iyong key dito gamit ang:

ssh-add ~/.ssh/id_ed25519

Inililista ng ssh-add -l ang mga key na kasalukuyang hawak ng agent. Isang paalala: pinapahintulutan ng agent forwarding (ssh -A) ang remote server na gamitin ang iyong agent para mag-authenticate sa susunod na server habang nakakonekta ka. Kaya i-enable lang ito para sa mga server na lubos mong pinagkakatiwalaan, at panatilihin itong naka-off bilang default.

Pag-rotate at pag-revoke: drill para sa nawawalang laptop

Ang pag-revoke ng plain SSH key ay simpleng pag-alis ng linya nito sa authorized_keys sa bawat server na mayroon nito. Walang certificate authority na kailangang abisuhan at walang expiry date na kailangang hintayin. Kapag nawala na ang linya, mabibigo ang mga bagong login gamit ang key na iyon.

Isagawa ang drill ngayon, habang hindi pa emergency. Pumili ng server, buksan ang ~/.ssh/authorized_keys, at hanapin ang key gamit ang comment nito. Burahin ang linya gamit ang editor, o i-filter ito batay sa comment:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Pagkatapos, kumpirmahin mula sa device na kaka-revoke mo lang na nabibigo na ang login, at mula sa ibang device na gumagana pa rin ang login. Tandaan ang isang detalye: hindi isinasara ng pag-alis ng key ang mga session na bukas na, dahil sinusuri lamang ang key sa oras ng login. Kung nire-revoke mo ang key ng ninakaw na device, suriin din ang who sa server at wakasan ang anumang session na hindi mo nakikilala.

Pareho ang operation sa rotation, ngunit iba ang pagkakasunod-sunod: gumawa ng bagong key sa device, i-install ito gamit ang ssh-copy-id, kumpirmahing nakakapag-login ang bagong key, saka burahin ang lumang linya. Gawin ito kapag nagpalit ng gumagamit ang isang device, kapag posibleng na-expose ang isang key, o kapag umalis ang isang tao sa team. Ayos lang itong gawin nang mano-mano sa dalawang server; kapag dalawampu na, trabaho na ito para sa automation. Ipinapakita ng pamamahala ng maraming Linux server kung paano i-push ang parehong authorized_keys state sa buong fleet.

Mga hindi dapat gawin

• Huwag gumamit ng iisang private key sa lahat ng device mo. Dahil dito, imposibleng bawiin ang access ng isang ninakaw na device nang hindi pinapalitan ang key sa lahat ng device.

• Huwag mag-commit ng private key sa isang git repository, kahit private repository pa ito. Minomonitor ng mga automated scanner ang mga public repository at sinusubukan ang mga na-leak na key sa loob ng ilang minuto matapos ang push. Kapag ginawang public ang repository sa susunod, malalantad ang buong history nito.

• Huwag i-upload ang private key ng laptop mo sa isang server para ma-access ng server na iyon ang isa pang server. Bumuo ng hiwalay na key mismo sa server, at i-authorise ang key na iyon sa eksaktong lugar kung saan ito kailangan.

• Huwag mag-paste ng private key sa chat, email, o ticket. Ang public key, ang .pub file, lamang ang bahaging ibinabahagi.

Kapag maaasahan nang nagla-log in ang key mo, gawin ang susunod na hakbang at i-off ang password authentication para tuluyang hindi magtagumpay ang tuloy-tuloy na paghula ng password laban sa server mo. Nasa Pagpapatibay ng seguridad ng SSH sa isang VPS ang drop-in configuration para rito.

FAQ

Paano gumagana ang SSH keys nang hindi nagpapadala ng password?

Nasa server ang iyong public key sa ~/.ssh/authorized_keys. Sa pag-login, nagpapadala ito ng challenge; pini-pirmahan ng iyong client ang challenge gamit ang private key, at bine-verify ng server ang signature gamit ang public key. Hindi umaalis sa iyong device ang private key, kaya walang maaaring ma-intercept habang ipinapadala at walang reusable na credential na maaaring manakaw mula sa server. Ang isang breached na server ay mga public key lamang ang maaaring ma-leak, at hindi magagamit ang mga ito para mag-login kahit saan.

Dapat ba akong gumamit ng iisang SSH key para sa lahat ng server ko?

Tama ang paggamit ng iisang key sa maraming server, basta nananatili ang key na iyon sa iisang device. Ang patakaran ay isang key bawat device, hindi isang key bawat server: inilalagay ang public key ng iyong laptop sa bawat server na kailangang ma-access ng laptop, at may sarili namang key ang iyong desktop. Pinapadali nito ang revocation, dahil kapag nawala ang isang device, isang madaling makilalang linya lamang ang kailangang alisin sa bawat server, habang patuloy na gumagana ang ibang device.

Anong permissions ang dapat gamitin sa .ssh directory at authorized_keys?

Itakda ang 700 sa ~/.ssh at 600 sa authorized_keys at sa bawat private key. Dapat pagmamay-ari ang mga ito ng account na gumagamit sa mga ito. Bilang default, tumatakbo ang sshd gamit ang StrictModes yes, kaya tahimik nitong binabalewala ang iyong key kapag maaaring magsulat rito ang sinumang iba sa iyo, o kapag maaaring magsulat ang sinumang iba sa home directory. Ang tanging bakas nito ay Authentication refused: bad ownership or modes sa auth log o journal ng server.

Paano ko aalisin ang isang SSH key mula sa server?

Burahin ang linya ng key mula sa ~/.ssh/authorized_keys sa account kung saan ito pinahintulutan. Hanapin ang tamang linya gamit ang comment nito, ang label pagkatapos ng key material. Agad mabibigo ang mga bagong login gamit ang key na iyon, pero mananatiling bukas ang mga session na kasalukuyang nakakonekta. Kung ninakaw ang device, tapusin din ang anumang aktibong session para rito. Ulitin ito sa bawat server na kinopyahan ng key.

Kailangan ko ba ng passphrase sa aking SSH key?

Oo, kung ang key ay nasa laptop o desktop. Ini-encrypt ng passphrase ang key file, kaya walang silbi sa sarili nito ang nanakaw o na-leak na kopya. Sa ssh-agent, isang beses mo lamang itong ita-type bawat session sa halip na sa bawat connection. Karaniwang walang passphrase ang mga key na ginagamit ng unattended automation sa server, dahil walang taong magta-type nito. Protektahan ang mga iyon sa pamamagitan ng paglilimita sa mga operasyong maaaring gawin ng target account.