SSH key: pag-set up ng login sa server nang walang password

Isang pares ng file ang SSH key: nananatili sa iyong makina ang private key, at inilalagay sa server ang public key. Sa pagkonekta, sinusuri ng server kung may hawak kang private key na tugma sa isa sa mga pinapayagang public key, at kung oo, pinapapasok ka nito nang walang password. Mas maginhawa at mas ligtas ito kaysa password: halos imposibleng hulaan ang key sa pamamagitan ng brute force. Nasa ibaba ang gabay sa pag-set up ng SSH key mula sa paggawa hanggang sa pag-disable ng password login, kasama ang pagtalakay sa mga pinakakaraniwang pagkakamali.

Paano gumagana ang authentication gamit ang key

Asymmetric ang mga key. Maaaring ibigay ang public key (id_ed25519.pub) sa sinuman — hindi maibabalik mula rito ang private key. Hindi kailanman umaalis sa iyong makina ang private key (id_ed25519) at hindi ito ipinapadala sa network.

Sa login, sinasabi ng client sa server kung aling key ang gusto nitong gamitin. Hahanapin ng server ang public key na iyon sa ~/.ssh/authorized_keys ng user, at kung makita, hihilingin nito sa client na pirmahan ang datos ng session gamit ang private key. Sinusuri ang pirma gamit ang public key, at pinapapasok ang user. Hindi ipinapadala ang password sa anumang bahagi nito.

Hakbang 1. Gumawa ng key: ssh-keygen

Sa iyong makina (Linux, macOS, o Windows 10/11 na may built-in na OpenSSH), patakbuhin:

ssh-keygen -t ed25519 -C "alena@laptop"

Itinatakda ng -t ang algorithm, at ang -C ay komento na idudugtong sa dulo ng public key para madaling makilala kung kanino ito. Ang Ed25519 ang inirerekomendang modernong algorithm: maiikli, mabilis, at ligtas ang mga key nito. Kung napakatanda ng server at hindi nito sinusuportahan ang Ed25519, gamitin ang RSA na hindi bababa sa 3072 bits: ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

Kailangan ba ng passphrase

Ine-encrypt ng passphrase ang private key sa disk. Kung manakaw ang laptop o mailabas ang file, walang silbi ang key kung walang passphrase. Para sa personal na key, magandang maglagay ng passphrase, at para hindi ito itatype sa bawat koneksyon, gamitin ang ssh-agent: itinatago nito ang na-decrypt na key sa memorya hanggang matapos ang session.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # listahan ng mga key na na-load

Makatwiran ang key na walang passphrase para sa automation lamang — halimbawa CI o backup script. Dapat limitahan ang ganitong key sa server (tingnan sa ibaba).

Hakbang 2. Kopyahin ang public key sa server: ssh-copy-id

Pinakasimpleng paraan ang ssh-copy-id. Kakonekta ito gamit ang password sa huling pagkakataon, idadagdag ang iyong public key sa ~/.ssh/authorized_keys sa server, at itatakda ang tamang permissions.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Kung hindi standard ang port ng server, idagdag ang -p 2222.

Kung walang ssh-copy-id

Walang utos na ssh-copy-id sa Windows. Maaaring ipadala nang mano-mano ang key gamit ang isang utos:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Karaniwang hinihingi ng mga cloud provider ang public key sa paggawa ng server — mapupunta ito sa authorized_keys sa pamamagitan ng cloud-init.

Hakbang 3. Subukan ang login

ssh deploy@203.0.113.10

Kung hindi na humihingi ng password (o passphrase lamang ng key ang hinihingi), gumagana na ito. Sa unang koneksyon sa bagong server, ipapakita ng SSH ang fingerprint ng host key at magtatanong kung pagkakatiwalaan ito. Pagkatapos ng yes, ise-save ang fingerprint sa ~/.ssh/known_hosts, at magbababala na ang SSH sa susunod kung magbago ang key ng server.

Para makita kung aling key ang sinusubukan ng client at bakit tinatanggihan ng server, kumonekta nang may verbose na output:

ssh -v deploy@203.0.113.10

File na ~/.ssh/config: maiikling pangalan para sa mga server

Kapag maraming server, nakakapagod i-type ang user, IP, port, at path ng key sa bawat pagkakataon. Lahat ng ito ay maaaring ilagay sa ~/.ssh/config:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-internal
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Ngayon, sapat na ang ssh prod, at naiintindihan din ng scp, rsync, at Git ang mga pangalang ito: rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes — gamitin lamang ang tinukoy na key. Kung wala ito, susubukan ng client ang lahat ng key sa agent, at maaaring putulin ng server ang koneksyon dahil sa dami ng subok bago pa maabot ang tamang key.
• ProxyJump — kumonekta sa internal na server sa pamamagitan ng gitnang server (bastion) gamit ang isang utos.
• ServerAliveInterval — magpadala ng "ping" bawat 60 segundo para hindi maputol ang koneksyon kapag walang ginagawa.

Dapat 600 ang permission ng file na ito, kung hindi ay maaaring tumanggi ang SSH na basahin ito: chmod 600 ~/.ssh/config.

Agent forwarding: kailan kailangan at ano ang panganib

Minsan kailangan ng server na kumonekta pa sa iba — halimbawa git pull mula sa private repository. Huwag kopyahin ang private key sa server. Sa halip, gamitin ang ssh -A o ForwardAgent yes: maa-access ng server ang iyong agent habang nakakonekta ka. Pero sinumang may root sa server na iyon ay maaari ring gumamit ng agent habang nakakonekta ka. Kaya i-enable lamang ang forwarding sa mga pinagkakatiwalaang host, at para sa pagdaan sa gitnang server, mas mainam ang ProxyJump dahil hindi nito binubuksan ang agent.

Hakbang 4. I-disable ang login gamit ang password

Habang pinapayagan ang password login, nananatiling target ng pag-guess ng password ang server. Kapag tiyak ka nang gumagana ang login gamit ang key, i-disable ang password. Mahalaga: huwag isara ang kasalukuyang session hangga't hindi mo nasusubukan ang login sa bagong window, dahil baka mawalan ka ng access.

Buksan ang /etc/ssh/sshd_config (o gumawa ng file sa /etc/ssh/sshd_config.d/ kung may Include ang pangunahing config) at itakda:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Ang PermitRootLogin no ay hindi pinapayagan ang login bilang root sa kabuuan: mag-log in ang mga administrator gamit ang sarili nilang account at magtaas ng pribilehiyo gamit ang sudo. Kung hindi maaaring alisin ang root login, gamitin ang PermitRootLogin prohibit-password — key lamang.

Suriin ang syntax at i-reload ang serbisyo:

sudo sshd -t
sudo systemctl reload ssh      # sa Debian/Ubuntu; sa mga sistemang RHEL — sshd

Tahimik ang sshd -t kung tama ang config. Ngayon, sa bagong terminal, tiyakin na gumagana pa rin ang login gamit ang key, at tinatanggihan ng server ang login gamit ang password:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Karagdagang proteksyon

Ang pag-disable ng password ang pangunahing hakbang. Karaniwang kasunod nito ang paglimita ng access sa port 22 gamit ang firewall (ufw allow from 198.51.100.0/24 to any port 22), at ang pag-install ng fail2ban, na nagba-ban ng IP pagkatapos ng sunod-sunod na nabigong pagsubok. Makikita ang estado ng proteksyon sa SSH gamit ang sudo fail2ban-client status sshd.

Maaaring limitahan ang key para sa automation mismo sa authorized_keys gamit ang mga opsyon sa unahan ng key: halimbawa, ang from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup ay papayag lamang ng login mula sa iisang address at walang interactive na shell.

Mga karaniwang error at paano ayusin

Permission denied (publickey)

Ito ang pinakakaraniwang error. Mga dahilan, mula sa pinakakaraniwan hanggang sa pinakabihira:

1. Maling permissions sa server. Hindi papansinin ng sshd ang authorized_keys kung ang direktoryo o file ay maisusulatan ng iba. Ayusin: chmod 700 ~/.ssh at chmod 600 ~/.ssh/authorized_keys, at hindi dapat maisusulat ng grupo o ng iba ang home directory.
2. Maling may-ari. Kung gumawa ka ng file gamit ang sudo, root ang magiging may-ari. Ayusin: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. Nailagay ang key sa maling user. Kinopya mo ang key para sa root pero deploy ang gamit mo sa login, o kabaligtaran.
4. Maling key ang ipinapadala ng client. Tingnan ang ssh -v: ipinapakita ng linyang Offering public key ang mga key na sinusubukan. Tukuyin ang tamang key gamit ang -i o IdentityFile.
5. Nasira ang key habang kinokopya. Dapat nasa iisang linya ang public key. Ang line break mula sa clipboard ay sumisira dito.

Ipinapakita ng log ang dahilan sa panig ng server: sudo journalctl -u ssh -n 30 (sa RHEL, -u sshd). Maaaring makita roon ang mga linyang tulad ng Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

Tumatanggi ang client na gamitin ang private key na nababasa ng ibang user. Ayusin: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

Hindi tugma ang host key ng server sa naka-save sa known_hosts. Nangyayari ito pagkatapos muling i-install ang server o magbago ang IP, pero pareho rin ang itsura nito sa man-in-the-middle attack. Siguraduhing talagang na-reinstall ang server, saka burahin ang lumang entry: ssh-keygen -R 203.0.113.10.

Too many authentication failures

Masyadong maraming key ang ipinadala ng agent sa server, at isinara ng server ang koneksyon ayon sa MaxAuthTries. Solusyon: IdentitiesOnly yes at malinaw na IdentityFile sa ~/.ssh/config.

Buod

Limang minuto lamang ang pag-set up ng SSH key: ssh-keygen -t ed25519, ssh-copy-id, pagsubok ng login, pagkatapos PasswordAuthentication no at pag-reload ng sshd habang bukas pa ang pangalawang session. Pinapaikli ng ~/.ssh/config ang mahahabang utos, at ang permissions na 700/600 ang nag-aayos ng karamihan ng error na "Permission denied". Ang SSH, rsync, at proteksyon ng server gamit ang firewall at fail2ban ay itinuturo nang praktikal sa kursong Linux.