Paano i-manage ang SSH keys nang tama

Paano gumagana ang SSH keys

Ang SSH key ay pares ng mga file: isang private key na mananatili sa iyong device, at isang public key na ikokopya mo sa bawat server na nais mong i-log in. Kapag kumonekta ka, gagamitin ng server ang public key para magpadala ng challenge na ang tanging makakasagot ay ang katugmang private key. Hindi lumalabas ang private key sa iyong device, kaya walang sikretong dumadaan sa network, at walang magagamit na mananakaw ang isang compromised na server. Ito ang dahilan kung bakit mas mabuti ang keys kaysa sa passwords. Ang maayos na pag-manage ng SSH keys ay nakadepende sa apat na habit: isang key bawat device, ang file permissions na kailangan ng sshd, isang ~/.ssh/config file para hindi na kailangang mag-type ng mga options, at ang kaalaman kung paano magtanggal ng key kapag nawala ang isang laptop.

Sakop ng guide na ito ang bawat habit sa Ubuntu 24.04, bagaman halos lahat ng nakasulat dito ay applicable sa kahit anong Linux server at anumang recent na OpenSSH.

Isang mahalagang terminolohiya bago magsimula upang maiwasan ang mga pagkakamali. Ang public key ay hindi sikreto. Maaari mo itong i-paste sa isang ticket, i-send sa email, o i-publish, at walang makakapag-log in gamit ito. Ang private key ang sikreto. Sinumang makakakopya ng file na iyon, at malaman ang passphrase nito (kung mayroon man), ay ituturing na ikaw ng iyong mga server.

Gumawa ng key: ed25519 ang tamang default

Sa sarili mong computer, hindi sa server, i-run ang:

ssh-keygen -t ed25519 -C "laptop"

Pinipili ng -t ed25519 ang key type. Ang Ed25519 ang modernong default: maikli ang mga key, mabilis, at supported ng bawat OpenSSH release simula noong 2014. Gamitin lamang ang ssh-keygen -t rsa -b 4096 kung kailangang kumonekta sa lumang device na hindi nakakaintindi ng ed25519. Naglalagay ang -C "laptop" ng comment. Walang cryptographic effect ang comment, pero ito ang gagamitin mo para makilala ang key na ito sa authorized_keys file ng server pagkalipas ng dalawang taon, kaya ilagay ang pangalan ng device kung nasaan ang key.

Tatanungin ng ssh-keygen kung saan i-save ang key. Tanggapin ang default na ~/.ssh/id_ed25519. Magtatanong din ito ng passphrase. Mag-set ng passphrase; ipinapaliwanag ng passphrase section sa ibaba kung bakit wala itong epekto sa iyong daily workflow. Magkakaroon ka ng dalawang file: ang ~/.ssh/id_ed25519 ay ang private key, at ang ~/.ssh/id_ed25519.pub ay ang public key. Tingnan ang public half:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Isang linya lang ito: ang key type, ang key material, at ang iyong comment. Ang linyang iyon ang ilalagay sa iyong mga server.

Isang key bawat device, hindi isang key bawat server

Ang unang tanong ng lahat: kailangan ko ba ng bagong key para sa bawat server? Hindi. Gumawa ng isang key para sa bawat device na ginagamit mo, at ilagay ang public key na iyon sa lahat ng server na dapat ma-access ng device. Ang key ang nagpapatunay sa identity ng device. Ang authorized_keys file sa bawat server ang listahan ng mga pinapahintulutang device.

Ito ang scalable na modelo, habang ang ibang paraan ay may mga predictable na problema. Ang isang key bawat server ay nangangahulugang ang isang laptop na may dalawampung server ay may dalawampung private keys, at mawawala ang kontrol mo kung alin ang para sa bawat isa. Mas malala ang isang shared key para sa lahat ng iyong device: kapag nanakaw ang laptop, hindi mo maaaring i-revoke ang laptop nang hindi rin bina-block ang iyong desktop, dahil pareho sila ng private key. Kailangan mong palitan ang key sa lahat ng lugar at i-redistribute ito sa lahat ng device nang sabay-sabay.

Sa modelong isang key bawat device, ang nawalang laptop ay magreresulta lamang sa isang linya bawat server: burahin ang linya ng laptop mula sa authorized_keys, at ang lahat ng ibang device ay patuloy na gagana. Ang comment na itinakda mo gamit ang -C ang nagpapadali sa paghahanap ng linyang iyon.

Ang prinsipyo sa likod ng modelong ito: ang private key ay ginagawa sa isang device at mawawala kasama ang device na iyon. Huwag kailanman mag-copy ng private key sa pangalawang machine, at huwag mag-upload ng key sa isang server. Kapag kailangan ng bagong device ang access, gumawa ng bagong key sa loob nito.

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

Mag-log in ito gamit ang anumang working method, kadalasan ay password. Ididikit nito ang iyong public key sa ~/.ssh/authorized_keys sa server. Gagawa rin ito ng directory at file na may tamang permissions kung wala pa ang mga ito. I-test ito sa pamamagitan ng pagbubukas ng bagong SSH session: dapat payagan ka ng server na mag-log in nang hindi hinihingi ang password ng account. Kung may passphrase ang iyong key, maaaring ito ang hingin ng iyong sariling machine; ang prompt na iyon ay local at hindi ang password ng server.

Kapag naka-disable na ang password login, hindi makakapasok ang ssh-copy-id, kaya dapat mong idagdag ang linya nang manual. Mag-log in gamit ang session na gumagana pa, o gamit ang web console ng iyong provider, at i-run 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 iyong totoong public key sa loob ng quotes, ang buong single line mula sa id_ed25519.pub. Ang authorized_keys ay may isang public key bawat linya, at ito ang kabuuan ng access database: ang pagdagdag ng device ay pag-append ng linya, at ang pag-revoke ng device ay pag-delete ng linya. Sa isang bagong server, dapat gawin ang step na ito sa unang 10 minuto sa isang bagong VPS, bago i-off ang password login.

Ang mga permission na nagiging sanhi ng pagkabigo ng key login

Ito ang pinakakaraniwang dahilan kung bakit nagfe-fail ang key login, at hindi ito nagbibigay ng error sa client side. Ang sshd ay tumatakbo gamit ang StrictModes yes sa Ubuntu 24.04, kaya tumatanggi itong gumamit ng authorized_keys file na pwedeng i-edit ng ibang users. Kung ang file, ang ~/.ssh directory, o ang iyong home directory ay pwedeng sulatan ng sinuman maliban sa iyo, i-ignore ng sshd ang iyong key at hihingi na lang ng password nang walang paliwanag sa client. (Ang OpenSSH ng Ubuntu ay tumatanggap lamang ng isang exception: isang file group na writable ng iyong sariling private group, kung saan wala ang ibang users. Huwag itong gawing basehan; sundin ang mga modes sa ibaba.) Ang dahilan ay lalabas lamang sa log ng server:

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

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

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

Ang solusyon ay dalawang pagbabago sa permission at isang ownership check, na dapat patakbuhin sa server bilang ang apektadong user:

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 laman nito. Ang parehong mga numero ay dapat ding gamitin sa iyong sariling computer, dahil nagche-check din ang client. Ang private key na pwedeng basahin ng ibang users ay magiging sanhi ng pagtanggi ng ssh sa key, at sa pagkakataong ito, malinaw ang error:

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

chmod 600 ~/.ssh/id_ed25519 ang solusyon dito.

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

Ang ~/.ssh/config file sa iyong computer ay nagbibigay ng maikling pangalan sa bawat server at iniimbak ang mga options na madalas mong i-type. I-create 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, papalitan na ng ssh web1 ang ssh -p 22 matt@10.0.0.10. Ang parehong maikling pangalan ay gagana sa scp, rsync, at git dahil binabasa ng lahat ng ito ang file na ito. Ang HostName ang tunay na address, ang User ay nag-aalis ng pangangailangang i-type ang account name, at ang IdentityFile ang nagtatakda kung anong key ang gagamitin.

Dapat talakayin ang IdentitiesOnly yes dahil inaayos nito ang isang nakakalitong error. Kapag maraming keys ang nasa agent mo, sinusubukan ng client ang mga ito nang isa-isa, at binibilang ng server ang bawat subok bilang isang failed attempt. Kapag masyadong maraming keys ang naka-load, makakakuha ka ng Received disconnect: Too many authentication failures bago pa masubukan ang tamang key. Ginagawa ng IdentitiesOnly yes na ang client ay mag-aalok lamang ng key na nakasaad sa IdentityFile, kaya hindi na mangyayari ang error na ito.

Passphrases at ssh-agent

Naka-encrypt ang passphrase sa private key file sa disk. Kung walang passphrase, magagamit agad ng sinumang makakakopya ng file; kung mayroon, hindi magagamit ang nakaw na file hangga't hindi nahuhulaan ang passphrase. Ito ang tamang proteksyon para sa mga key sa laptop, dahil madalas manakaw ang mga laptop at magkaroon ng leaks sa mga laptop backup.

Ang dahilan kung bakit walang extra cost ang passphrase sa praktikal na aspeto ay dahil sa ssh-agent. Hawak ng agent ang iyong decrypted key sa memory, kaya isang beses mo lang itatype ang passphrase bawat login session at magiging instant na ang lahat ng susunod na connection. Karamihan sa mga desktop Linux distribution at macOS ay mayroon nang tumatakbong agent para sa iyo. I-load ang iyong key sa agent gamit ang:

ssh-add ~/.ssh/id_ed25519

Ipinapakita ng ssh-add -l ang mga key na kasalukuyang hawak ng agent. Isang babala: ang agent forwarding (ssh -A) ay nagpapahintulot sa remote server na gamitin ang iyong agent para sa authentication habang connected ka, kaya i-enable lamang ito sa mga server na lubos mong pinagkakatiwalaan, at panatilihin itong naka-off by default.

Pag-rotate at pag-revoke: ang drill para sa nawalang laptop

Ang pag-revoke ng plain SSH key ay ang pagtanggal lamang ng kaukulang linya nito mula sa authorized_keys sa lahat ng server kung saan ito nakalagay. Walang certificate authority na kailangang i-notify at walang expiry date na dapat hintayin. Kapag natanggal na ang linya, hindi na magiging successful ang mga bagong login gamit ang key na iyon.

Gawin ang drill na ito 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 gamit ang comment:

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

Pagkatapos, i-confirm mula sa device na ni-revoke mo na fail na ang login, at mula sa isa pang device na gumagana pa ang login. Tandaan ang isang detalye: ang pagtanggal ng key ay hindi magsasara ng mga session na kasalukuyan nang bukas, dahil ang key ay chine-check lamang sa oras ng login. Kung nagre-revoke ka ng nakaw na device, i-check din ang who sa server at i-end ang anumang session na hindi mo kilala.

Ang rotation ay parehong operasyon na may ibang pagkakasunod-sunod: mag-generate ng bagong key sa device, i-install ito gamit ang ssh-copy-id, i-confirm na nakaka-login gamit ang bagong key, at pagkatapos ay burahin ang lumang linya. Gawin ito kapag nagpapalit ng may-ari ang device, kapag maaaring na-expose ang key, o kapag may aalis sa team. Ayos lang na gawin ito nang manual sa dalawang server; ngunit kung dalawampung server na ang kasama, kailangan na ng automation, at ang managing multiple Linux servers ay nagpapakita kung paano i-push ang parehong authorized_keys state sa buong fleet.

Mga dapat iwasan

• Huwag gumamit ng iisang private key sa lahat ng iyong devices. Kapag nawala ang isang device, hindi mo maaaring i-revoke ang key na iyon nang hindi pinapalitan ang key sa lahat ng iba pang device.

• Huwag i-commit ang private key sa isang git repository, kahit private pa ito. Ang mga automated scanner ay nagbabantay sa mga public repository at sinusubukan ang mga leaked keys ilang minuto matapos ang isang push. Kapag naging public ang isang repository sa hinaharap, mabubunyag din ang buong history nito.

• Huwag i-upload ang private key ng iyong laptop sa isang server para lamang makakonekta ang server na iyon sa isa pang server. Gumawa ng hiwalay na key sa mismong server, at i-authorize ang key na iyon kung saan lamang ito kailangan.

• Huwag i-paste ang private key sa chat, email, o ticket. Ang public key, ang .pub file, lamang ang dapat ibahagi.

Kapag gumagana na nang maayos ang iyong key para sa login, i-off na ang password authentication. Ginagawa ito para hindi na magtagumpay ang mga constant guessing attacks sa iyong server. Ang drop-in configuration para dito ay nasa SSH hardening on a VPS.

FAQ

Paano gumagana ang SSH keys nang hindi nagpapadala ng password?

Naka-store ang iyong public key sa ~/.ssh/authorized_keys ng server. Sa pag-login, magpapadala ang server ng challenge, papirmahan ito ng iyong client gamit ang private key, at i-ve-verify ng server ang signature gamit ang public key. Hindi lumalabas ang private key sa iyong device, kaya walang ma-i-intercept sa transit at walang pwedeng nakawin mula sa server. Public keys lang ang nakukuha kapag na-breach ang server, at hindi ang mga ito pwedeng gamitin para mag-log in sa ibang lugar.

Dapat ko bang gamitin ang iisang SSH key para sa lahat ng aking servers?

Tama lang ang paggamit ng iisang key sa maraming servers, basta't ang key na iyon ay nasa iisang device lang. Ang rule ay isang key bawat device, hindi isang key bawat server: ang public key ng iyong laptop ay dapat nasa lahat ng server na kailangan ng laptop, at ang iyong desktop ay dapat may sariling key. Dahil dito, madali ang revocation, dahil ang pagkawala ng isang device ay nangangahulugan lang ng pagtanggal ng isang identifiable line sa bawat server, at gagana pa rin ang ibang devices.

Ano ang dapat na permissions ng .ssh directory at authorized_keys?

I-set ang 700 sa ~/.ssh at 600 sa authorized_keys at sa bawat private key, na pagmamay-ari ng account na gumagamit sa mga ito. Ang sshd ay tumatakbo gamit ang StrictModes yes by default, kaya kung ang isang file o home directory ay pwedeng i-write ng ibang user, hindi ito babasahin ng sshd, at ang tanging trace ay Authentication refused: bad ownership or modes sa auth log o journal ng server.

Paano ko tatanggalin ang SSH key mula sa isang server?

I-delete ang line ng key mula sa ~/.ssh/authorized_keys sa account kung saan ito naka-authorize. Hanapin ang tamang line gamit ang comment nito, ang label pagkatapos ng key material. Mabibigo agad ang mga bagong login gamit ang key na iyon, pero ang mga kasalukuyang open sessions ay mananatiling open, kaya i-end din ang anumang live session para sa device na iyon kung ito ay nanakaw. Gawin ito sa lahat ng server kung saan na-copy ang key.

Kailangan ko ba ng passphrase sa aking SSH key?

Para sa key sa laptop o desktop, oo. Ang passphrase ay nag-e-encrypt sa key file, kaya ang nakaw na kopya ay walang silbi, at ang ssh-agent ay nangangahulugang isang beses mo lang itong itatype bawat session sa halip na sa bawat connection. Ang mga keys na ginagamit ng unattended automation sa isang server ay karaniwang walang passphrase, dahil walang tao na magta-type nito; protektahan ang mga ito sa pamamagitan ng pag-restrict sa mga pwedeng gawin ng target account.