Funguo za SSH: jinsi ya kuweka kuingia kwenye seva bila nywila

Funguo ya SSH ni jozi ya faili: funguo binafsi inabaki kwenye kompyuta yako, na funguo ya umma inawekwa kwenye seva. Unapounganishwa, seva inakagua kwamba unashika funguo binafsi inayolingana na mojawapo ya funguo za umma zinazoruhusiwa, kisha inakupa ufikiaji bila nywila. Njia hii ni rahisi zaidi na salama zaidi kuliko nywila: kukisia funguo kwa kujaribu kila mchanganyiko karibu haiwezekani. Hapa chini ni usanidi wa funguo za SSH kuanzia kuzitengeneza hadi kuzima kuingia kwa nywila, pamoja na makosa yanayotokea mara nyingi.

Jinsi uthibitisho kwa funguo unavyofanya kazi

Funguo ni za asymmetric. Funguo ya umma (id_ed25519.pub) inaweza kuonyeshwa kwa mtu yeyote — kutoka kwake haiwezekani kurudisha funguo binafsi. Funguo binafsi (id_ed25519) haitoki kamwe kwenye kompyuta yako wala haitumwi kwenye mtandao.

Wakati wa kuingia, mteja anaiambia seva ni funguo ipi anataka kutumia. Seva inatafuta funguo hiyo ya umma kwenye ~/.ssh/authorized_keys ya mtumiaji, na ikiipata, inaomba mteja asaini data ya kikao kwa funguo binafsi. Sahihi hukaguliwa kwa funguo ya umma, na kuingia kunaruhusiwa. Nywila haitumwi kabisa.

Hatua ya 1. Kutengeneza funguo: ssh-keygen

Kwenye kompyuta yako (Linux, macOS, au Windows 10/11 yenye OpenSSH iliyojengwa ndani), endesha:

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

Chaguo -t huchagua algorithm, -C ni maoni yanayowekwa mwishoni mwa funguo ya umma ili iwe rahisi kujua ni ya nani. Ed25519 ndiyo algorithm ya kisasa inayopendekezwa: funguo ni fupi, za haraka, na imara. Ikiwa seva ni ya zamani sana na haiungi mkono Ed25519, tumia RSA ya urefu wa angalau biti 3072: 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

Je, passphrase inahitajika

Passphrase inasimba funguo binafsi kwenye diski. Laptop ikiibiwa au faili likivuja, bila passphrase funguo haina maana kwa mshambuliaji. Kwa funguo ya kibinafsi ni vyema kuweka passphrase, na ili usiiingize kila mara unapounganishwa, tumia ssh-agent: inaweka funguo iliyofunguliwa kwenye kumbukumbu hadi kikao kiishe.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # orodha ya funguo zilizopakiwa

Funguo bila passphrase zina haki kwa otomatiki — kwa mfano CI au skripti ya nakala rudufu. Funguo kama hiyo ni vyema iwekewe vikwazo upande wa seva (imeelezwa hapa chini).

Hatua ya 2. Kunakili funguo ya umma kwenye seva: ssh-copy-id

Njia rahisi zaidi ni ssh-copy-id. Itaunganishwa mara moja zaidi kwa nywila, kuongeza funguo yako ya umma kwenye ~/.ssh/authorized_keys kwenye seva, na kuweka ruhusa sahihi.

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.

Ikiwa seva inasikiliza port isiyo ya kawaida, ongeza -p 2222.

Ikiwa ssh-copy-id haipatikani

Kwenye Windows hakuna zana ya ssh-copy-id. Funguo inaweza kupelekwa kwa mkono kwa amri moja:

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"

Watoa huduma wa wingu kwa kawaida huomba funguo ya umma wakati seva inapoundwa — inaingia kwenye authorized_keys kupitia cloud-init.

Hatua ya 3. Kukagua kuingia

ssh deploy@203.0.113.10

Ikiwa nywila haiulizwi tena (au inaulizwa passphrase ya funguo tu), kila kitu kinafanya kazi. Unapounganishwa kwa mara ya kwanza kwenye seva mpya, SSH inaonyesha fingerprint ya funguo ya mwenyeji na kuuliza kama unaiamini. Ukijibu yes, fingerprint inahifadhiwa kwenye ~/.ssh/known_hosts, na baadaye SSH itaonya ikiwa funguo ya seva itabadilika.

Ili kuona funguo zipi mteja anajaribu na kwa nini seva inakataa, endesha muunganisho kwa maelezo kamili:

ssh -v deploy@203.0.113.10

Faili ~/.ssh/config: majina mafupi ya seva

Ikiwa una seva kadhaa, kuandika mtumiaji, IP, port, na njia ya funguo kila mara ni kero. Yote hayo yanaweza kuelezwa kwenye ~/.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

Sasa unahitaji tu ssh prod, na scp, rsync pamoja na Git pia zinaelewa majina haya: rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes — tumia funguo iliyotajwa tu. Bila mstari huu, mteja anajaribu funguo zote za agent, na seva inaweza kukukatia muunganisho kwa sababu ya idadi ya majaribio kabla ya kufika kwenye funguo sahihi.
• ProxyJump — unganisha kwenye seva ya ndani kupitia seva ya kati (bastion) kwa amri moja.
• ServerAliveInterval — tuma "ping" kila sekunde 60 ili muunganisho usikatike ukiwa kimya.

Ruhusa ya faili lazima iwe 600, vinginevyo SSH inaweza kukataa kulisoma: chmod 600 ~/.ssh/config.

Agent forwarding: lini inahitajika na kwa nini ni hatari

Wakati mwingine kutoka kwenye seva unahitaji kuunganisha zaidi — kwa mfano kufanya git pull kutoka hazina binafsi. Funguo binafsi haipaswi kunakiliwa huko. Badala yake hutumika ssh -A au ForwardAgent yes: seva inapata ufikiaji wa agent yako wakati wa kikao. Lakini yeyote mwenye root kwenye seva hiyo pia anaweza kutumia agent yako ukiwa umeunganishwa. Kwa hiyo washa forwarding kwa wapangishi unaowaamini tu, na kwa kupitia seva ya kati tumia ProxyJump — haifungui agent.

Hatua ya 4. Kuzima kuingia kwa nywila

Mradi kuingia kwa nywila kunaruhusiwa, seva bado ni shabaha ya kujaribu kila nywila. Ukishahakikisha kuingia kwa funguo kunafanya kazi, zima nywila. Muhimu: usifunge kikao cha sasa kabla ya kukagua kuingia kwenye dirisha jipya, vinginevyo unaweza kupoteza ufikiaji.

Fungua /etc/ssh/sshd_config (au tengeneza faili kwenye /etc/ssh/sshd_config.d/ ikiwa usanidi mkuu unaijumuisha kwa Include), kisha weka:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no inakataza kuingia kama root kabisa: wasimamizi wanaingia kwa majina yao wenyewe na kupandisha haki kwa sudo. Ikiwa kuingia kwa root ni lazima, tumia PermitRootLogin prohibit-password — kwa funguo pekee.

Kagua sintaksia kisha pakia upya huduma:

sudo sshd -t
sudo systemctl reload ssh      # kwenye Debian/Ubuntu; kwenye familia ya RHEL — sshd

Amri ya sshd -t haitoi chochote ikiwa usanidi ni sahihi. Sasa kwenye terminal mpya, hakikisha kuingia kwa funguo kunafanya kazi, na kuingia kwa nywila kunakataliwa na seva:

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

Ulinzi wa ziada

Kuzima nywila ndicho kipimo kikuu. Baada ya hapo mara nyingi ufikiaji wa port 22 hudhibitiwa na firewall (ufw allow from 198.51.100.0/24 to any port 22), na fail2ban husakinishwa ili kuzuia IP baada ya majaribio kadhaa yaliyoshindwa. Hali ya ulinzi wa SSH inaonyeshwa na sudo fail2ban-client status sshd.

Funguo ya otomatiki inaweza kuwekewa vikwazo moja kwa moja kwenye authorized_keys kwa chaguo zilizo mbele ya funguo: kwa mfano from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup inaruhusu kuingia kutoka anwani moja tu na bila shell shirikishi.

Makosa ya kawaida na jinsi ya kuyarekebisha

Permission denied (publickey)

Hiki ndicho kosa la kawaida zaidi. Sababu, kutoka za kawaida hadi nadra:

1. Ruhusa mbaya kwenye seva. sshd inapuuza authorized_keys ikiwa saraka au faili linaweza kuandikwa na wengine. Marekebisho: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, na saraka ya nyumbani isiweze kuandikwa na kundi wala wengine.
2. Umiliki mbaya. Ikiwa faili ziliundwa kwa sudo, zinamilikiwa na root. Marekebisho: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. Funguo imewekwa kwa mtumiaji mwingine. Umenakili funguo kwa root, lakini unaingia kama deploy, au kinyume chake.
4. Mteja anatoa funguo isiyo sahihi. Angalia ssh -v: mistari ya Offering public key inaonyesha funguo zinazojaribiwa. Taja funguo sahihi kwa -i au IdentityFile.
5. Funguo imeharibika wakati wa kunakili. Funguo ya umma lazima iwe mstari mmoja. Mstari uliovunjika kutoka clipboard utaiharibu.

Sababu ya kukataliwa upande wa seva inaonekana kwenye kumbukumbu: sudo journalctl -u ssh -n 30 (kwenye RHEL — -u sshd). Mara nyingi utaona mistari kama Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

Mteja anakataa kutumia funguo binafsi inayosomwa na watumiaji wengine. Marekebisho: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

Funguo ya mwenyeji hailingani na ile iliyohifadhiwa kwenye known_hosts. Hii hutokea baada ya seva kusakinishwa upya au IP kubadilika, lakini picha hii hiyo pia inatokea kwenye shambulio la "man-in-the-middle". Hakikisha kweli seva hiyo ilitengenezwa upya, kisha ufute ingizo la zamani: ssh-keygen -R 203.0.113.10.

Too many authentication failures

Agent imetoa funguo nyingi sana kwa seva, na seva imefunga muunganisho kwa sababu ya MaxAuthTries. Suluhisho ni IdentitiesOnly yes pamoja na IdentityFile iliyotajwa wazi kwenye ~/.ssh/config.

Muhtasari

Usanidi wa funguo za SSH unachukua dakika tano: ssh-keygen -t ed25519, ssh-copy-id, kukagua kuingia, kisha PasswordAuthentication no na kupakia upya sshd huku kikao cha pili kikiwa wazi. Faili la ~/.ssh/config linaondoa amri ndefu, na ruhusa 700/600 zinatatua sehemu kubwa ya makosa ya "Permission denied". SSH, rsync, na ulinzi wa seva kwa firewall na fail2ban vinafundishwa kwa vitendo katika kozi ya Linux.