Jinsi ya kusimamia SSH keys vizuri

Jinsi SSH keys zinavyofanya kazi

SSH key ni jozi ya faili: private key inayobaki kwenye kifaa chako na public key unayohamishia kwenye kila seva unayotaka kuingia. Unapojiunganisha, seva hutumia public key kutuma changamoto ambayo inaweza kujibiwa na private key inayolingana pekee. Private key haitoki kwenye kifaa chako, hivyo hakuna siri inayopita kwenye mtandao, na seva iliyoingiliwa haina kitu cha wazi cha kuiba. Hii ndiyo sababu keys ni bora kuliko passwords. Kusimamia SSH keys vizuri kunategemea mazoea manne: key moja kwa kila kifaa, ruhusa za faili (file permissions) zinazohitajika na sshd, faili ya ~/.ssh/config ili uache kuandika chaguzi (options), na kujua jinsi ya kuondoa key siku laptop inapopotea.

Mwongozo huu unahusu kila mazoea kwenye Ubuntu 24.04, ingawa karibu kila kitu hapa kinaweza kutumika kwenye seva yoyote ya Linux na OpenSSH yoyote ya hivi karibuni.

Jambo moja la msamiati kabla ya kuanza, kwa sababu linazuia makosa makubwa. Public key si siri. Unaweza kuinakili kwenye ticket, kuituma kwa email, au kuichapisha, na hakuna mtu anayeweza kuingia nayo. Private key ndiyo siri. Mtu yeyote anayenakili faili hiyo, na anayejua passphrase yake ikiwa ipo, anachukuliwa kuwa wewe na seva zako.

Tengeneza funguo: ed25519 ndiyo chaguo bora la msingi

Kwenye kompyuta yako mwenyewe, siyo kwenye seva, run:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 huchagua aina ya funguo. Ed25519 ni chaguo la kisasa la msingi: funguo hizi ni fupi, zina kasi, na zinatambulika na kila toleo la OpenSSH tangu mwaka 2014. Tumia ssh-keygen -t rsa -b 4096 pale tu unapohitaji kuwasiliana na kifaa cha zamani ambacho hakielewi ed25519. -C "laptop" huweka maelezo (comment). Maelezo haya hayafanyi kazi yoyote ya kiusalama, lakini ndivyo utakavyotambua funguo hii kwenye faili ya authorized_keys ya seva baada ya miaka miwili, hivyo weka jina la kifaa ambacho funguo hiyo imehifadhiwa.

ssh-keygen huuliza mahali pa kuhifadhi funguo. Kubali chaguo la msingi, ~/.ssh/id_ed25519. Kisha huuliza neno la siri (passphrase). Weka neno la siri; sehemu ya neno la siri hapa chini inaelezea kwa nini haitakuathiri kila siku. Utapata faili mbili: ~/.ssh/id_ed25519 ni funguo ya siri (private key), na ~/.ssh/id_ed25519.pub ni funguo ya umma (public key). Angalia sehemu ya umma:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Ni mstari mmoja: aina ya funguo, nyenzo ya funguo, na maelezo yako. Mstari huo ndio utakaowekwa kwenye seva zako.

Funguo moja kwa kila kifaa, siyo moja kwa kila seva

Swali la kwanza la kila mtu: je, ninahitaji funguo mpya kwa kila seva? Hapana. Tengeneza funguo moja kwa kila kifaa unachotumia kuandika, na weka funguo hiyo ya umma kwenye kila seva ambayo kifaa hicho kinahitaji kuifikia. Funguo hiyo hutambua kifaa. Faili ya authorized_keys kwenye kila seva ni orodha ya vifaa vinavyoruhusiwa kuingia.

Huu ndio mfumo unaoweza kukua, na mbadala wake hushindwa kwa njia zinazotabirika. Funguo moja kwa kila seva inamaanisha laptop yenye seva ishirini itabeba funguo sambamba ishirini za siri, na utapoteza uwezo wa kutambua kila funguo. Funguo moja inayotumiwa na vifaa vyote ni mbaya zaidi: laptop ikiibwa, huwezi kuiondoa bila pia kumfungia desktop yako, kwa sababu vyote vina funguo sawa ya siri. Hivyo, ni lazima ubadilishe funguo kila mahali na kuisambaza kwenye kila kifaa kwa wakati mmoja.

Kwa kutumia funguo moja kwa kila kifaa, laptop iliyopotea inakugharimu mstari mmoja tu kwa kila seva: futa mstari wa laptop hiyo kwenye authorized_keys, na kila kifaa kingine kitaendelea kufanya kazi. Maelezo (comment) uliyoweka kwa kutumia -C ndiyo inayofanya mstari huo upatikane kwa urahisi.

Kanuni inayozingatia mfumo huu: funguo ya siri hutengenezwa kwenye kifaa na huisha pamoja na kifaa hicho. Usinakili kamwe funguo ya siri kwenda kwenye mashine ya pili, na usipakia (upload) funguo yoyote kwenye seva. Kifaa kipya kinapohitaji ufikiaji, tengeneza funguo mpya kwenye kifaa hicho.

Weka funguo ya umma (public key) kwenye seva

Njia rahisi ni kutumia ssh-copy-id, ambayo huja pamoja na OpenSSH:

ssh-copy-id matt@10.0.0.10

Inaingia kwa kutumia njia inayofanya kazi, kwa kawaida ni nywila, inaongeza funguo yako ya umma kwenye ~/.ssh/authorized_keys kwenye seva, na inatengeneza dirisha na faili kwa ruhusa sahihi ikiwa hazipo. Ijaribu kwa kufungua kikao kipya cha SSH: seva inapaswa kukuingiza bila kuuliza nywila ya akaunti. Ikiwa funguo yako ina passphrase, mashine yako inaweza kuiomba hiyo badala yake; ombi hilo ni la ndani na si nywila ya seva.

Wakati login ya nywila imeshazimwa, ssh-copy-id haiwezi kuingia, hivyo unapaswa kuongeza mstari huo kwa mkono. Ingia kupitia kikao kinachofanya kazi, au console ya wavuti ya mtoa huduma wako, na uendeshe amri hii kwenye seva:

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

Bandika funguo yako halisi ya umma ndani ya alama za nukuu, mstari mmoja kamili kutoka id_ed25519.pub. authorized_keys ni funguo moja ya umma kwa kila mstari, na hiyo ndiyo kanzidata nzima ya ufikiaji: kuongeza kifaa ni kuongeza mstari, na kufuta ufikiaji wa kifaa ni kufuta mstari. Kwenye seva mpya, hatua hii inapaswa kufanyika dakika 10 za kwanza kwenye VPS mpya, kabla ya kuzima login ya nywila.

Ruhusa zinazozuia kuingia kwa key

Hii ndiyo njia ya kawaida inayofanya kuingia kwa key kushindwa, na kushindwa huku hutokea bila taarifa upande wa client. sshd hukimbia na StrictModes yes kwa kuanzia kwenye Ubuntu 24.04, kumaanisha inakataa kutumia faili ya authorized_keys ambayo watumiaji wengine wanaweza kuifanyia marekebisho. Ikiwa faili, dirigentia ya ~/.ssh, au dirigentia yako ya home inaweza kuandikwa na mtu yeyote isipokuwa wewe, sshd itapuuza key yako na kuomba nywila, bila kutoa maelezo kwenye client. (OpenSSH ya Ubuntu inakubali hali moja tu: faili inayoweza kuandikwa na kikundi chako cha siri ambacho hakuna mtu mwingine aliye ndani yake. Usitegemee hali hiyo; tumia njia hizi hapa chini.) Sababu hii inaonekana tu kwenye log ya server:

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

Kwenye picha ya minimal isiyo na rsyslog hakuna auth.log; mstari huo huo upo kwenye journal: sudo journalctl -u ssh | grep 'Authentication refused'.

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

Suluhisho ni mabadiliko mawili ya ruhusa na ukaguzi wa umiliki, yanayotekelezwa kwenye server kama mtumiaji anayehusika:

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

Kanuni ya kukumbuka: 700 kwenye dirigentia ya .ssh, na 600 kwenye kila kitu kilichomo ndani yake. Namba zilezile zinatumika kwenye kompyuta yako mwenyewe, kwa sababu client pia hukagua. Private key inayoweza kusomwa na watumiaji wengine hufanya ssh kukataa key hiyo moja kwa moja, na safari hii kosa linaonekana wazi:

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

chmod 600 ~/.ssh/id_ed25519 inatatua tatizo hilo.

~/.ssh/config: acha kuandika chaguzi kila mara

Faili ya ~/.ssh/config kwenye kompyuta yako inatoa jina fupi kwa kila seva na hukumbuka chaguzi unazozichapa kila mara. Itengeneze kwa ruhusa za 600 na uongeze block ya Host kwa kila seva:

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

Sasa ssh web1 inachukua nafasi ya ssh -p 22 matt@10.0.0.10, na jina fupi hilo hilo hufanya kazi kwenye scp, rsync, na git, kwa sababu zote husoma faili hii. HostName ndiyo anwani halisi, User inakuokoa usichape jina la akaunti, na IdentityFile huainisha ni funguo gani itatolewa.

IdentitiesOnly yes inastahili maelezo, kwa sababu inatatua hitilafu inayochanganya. Wakati agent yako ina funguo kadhaa, client hutuma funguo hizo moja baada ya nyingine, na seva huhesabu kila jaribio kama jaribio lililoshindwa. Ukiwa na funguo nyingi zilizopakia, utapata Received disconnect: Too many authentication failures kabla ya funguo sahihi kujaribiwa. IdentitiesOnly yes hufanya client itoe funguo iliyoteuliwa kwenye IdentityFile pekee, hivyo hitilafu hiyo haiwezi kutokea.

Passphrases na ssh-agent

Passphrase hufunga faili ya funguo ya siri (private key) kwenye diski. Bila passphrase, mtu yeyote anayenakili faili hiyo anaweza kuitumia mara moja; kwa kutumia passphrase, faili iliyoibiwa haitafanya kazi hadi passphrase itakapokombwa. Kwa funguo kwenye laptop, huu ndio ulinzi unaohitajika, kwa sababu laptop huibiwa na nakala za ziada (backups) hupotea.

Sababu inayofanya passphrase isiwe na gharama katika vitendo ni ssh-agent. Agent huhifadhi funguo yako iliyofunguliwa kwenye kumbukumbu (memory), hivyo unaandika passphrase mara moja tu kwa kila kikao cha kuingia na kila muunganisho unaofuata ni wa papo hapo. Usanifu mwingi wa Linux na macOS tayari unatumia agent kwa ajili yako. Pakia funguo yako ndani yake kwa kutumia:

ssh-add ~/.ssh/id_ed25519

ssh-add -l huorodhesha funguo ambazo agent anazishikilia sasa hivi. Angalizo moja: agent forwarding (ssh -A) huruhusu seva ya mbali kutumia agent yako ili kuthibitisha utambulisho unapoendelea kuunganishwa, hivyo wasilisha uwezo huu kwenye seva unazoziamini kikamilifu, na uache ikiwa imezimwa kwa kawaida.

Kugeuza na kufuta: mazoezi ya laptop iliyopotea

Kufuta SSH key ya kawaida ni kuondoa tu mstari wake kwenye authorized_keys kwenye kila server yenye key hiyo. Hakuna mamlaka ya vyeti (certificate authority) ya kuarifu na hakuna tarehe ya mwisho ya kusubiri. Baada ya mstari huo kuondolewa, login mpya kwa kutumia key hiyo itafeli.

Fanya mazoezi haya sasa, wakati si dharura. Chagua server, fungua ~/.ssh/authorized_keys, na utafute key kwa kutumia maelezo yake (comment). Futa mstari huo kwa kutumia editor, au utenganishe kwa kutumia comment:

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

Kisha thibitisha kutoka kwenye kifaa ulichofuta kuwa login sasa inafeli, na kutoka kifaa kingine kuwa login bado inafanya kazi. Zingatia jambo moja: kuondoa key hakufungi session ambazo tayari ziko wazi, kwa sababu key hukaguliwa wakati wa login tu. Ikiwa unafuta kifaa kilichopotea, kagua pia who kwenye server na ufunge session yoyote usiyoijua.

Kugeuza (rotation) ni operesheni ile ile lakini kwa mpangilio tofauti: tengeneza key mpya kwenye kifaa, iweke kwa kutumia ssh-copy-id, thibitisha kuwa key mpya inaruhusu login, kisha futa mstari wa zamani. Fanya hivi kifaa kinapobadilishwa mmiliki, key inapoweza kuwa imevuja, au mtu anapoondoka kwenye timu. Kufanya hivi kwa mkono kwenye server mbili ni sawa; lakini kwenye server ishirini, unahitaji automation, na kusimamia Linux servers nyingi kunaonyesha jinsi ya kusukuma hali ile ile ya authorized_keys kwenye fleet nzima.

Mambo ya kuepuka

• Usitumie private key moja kwenye vifaa vyote. Hii itafanya iwe vigumu kufuta kifaa kilichoibiwa bila kubadilisha key hiyo kila mahali.

• Usiweke private key kwenye git repository, hata kama ni ya siri. Scanners za kiotomatiki huchunguza public repositories na kujaribu keys zilizovuja ndani ya dakika chache baada ya ku-push, na repository inayofanywa kuwa ya umma baadaye hufichua historia yake yote.

• Usipandishe private key ya laptop yako kwenye server ili server hiyo iweze kuwasiliana na server nyingine. Tengeneza key tofauti kwenye hiyo server yenyewe, na iidhinishe key hiyo mahali tu inapohitajika.

• Usibandike private key kwenye chat, barua pepe, au ticket. Public key, faili ya .pub, ndiyo sehemu pekee inayopaswa kushirikiwa.

Baada ya key yako kukuingiza kwa usalama, chukua hatua inayofuata na uzime password authentication, ili juhudi za kila mara za kukisia password kwenye server yako zisifanikiwe. Mipangilio ya kufanya hivyo imewekwa kwenye SSH hardening on a VPS.

FAQ

Je, funguo za SSH hufanya kazi bila kutuma nywila?

Seva huhifadhi funguo yako ya umma (public key) kwenye ~/.ssh/authorized_keys. Unapojiingiza, seva hutuma changamoto, mteja wako husaini changamoto hiyo kwa kutumia funguo ya siri (private key), na seva huhakiki sahihi hiyo kwa kutumia funguo ya umma. Funguo ya siri haitoki kwenye kifaa chako, hivyo hakuna kitu cha kukamatwa wakati wa usafirishaji na hakuna kitu kinachoweza kuibiwa kwenye seva. Seva iliyovamiwa hutoa funguo za umma pekee, ambazo haziwezi kutumika kuingia mahali popote.

Je, nianze kutumia funguo moja ya SSH kwa seva zangu zote?

Kutumia funguo moja kwenye seva nyingi ni sahihi, mradi tu funguo hiyo ibaki kwenye kifaa kimoja. Kanuni ni funguo moja kwa kila kifaa, siyo funguo moja kwa kila seva: funguo ya umma ya laptop yako huwekwa kwenye kila seva inayohitajika na laptop hiyo, na desktop yako inakuwa na funguo yake binafsi. Hii hufanya uondoaji wa funguo kuwa rahisi, kwa sababu kupoteza kifaa kunamaanisha kuondoa mstari mmoja kwenye kila seva, na vifaa vingine vinaendelea kufanya kazi.

Je, directory ya .ssh na authorized_keys zinapaswa kuwa na ruhusa (permissions) zipi?

Weka 700 kwenye ~/.ssh na 600 kwenye authorized_keys na kwenye kila funguo ya siri, ikiwa imemilikiwa na akaunti inayozitumia. sshd hukimbia na StrictModes yes kwa kima kawaida, hivyo faili au directory ya nyumbani ambayo mtu yeyote anayeweza kuandika hufanya mfumo upuuze funguo yako kimya kimya, na alama pekee ni Authentication refused: bad ownership or modes kwenye logi ya auth ya seva au journal.

Je, niondoshaje funguo ya SSH kwenye seva?

Futa mstari wa funguo hiyo kwenye ~/.ssh/authorized_keys kwenye akaunti iliyoidhinishwa. Tafuta mstari sahihi kwa kutumia maelezo yake (comment), ambayo ni lebo iliyo baada ya nyenzo ya funguo. Ingizo mpya kwa funguo hiyo itafeli mara moja, lakini vikao (sessions) vilivyo wazi tayari vitaendelea kuwa wazi, hivyo maliza kikao chochote kilicho hai kwa kifaa hicho ikiwa kiliibiwa. Rudia kitendo hiki kwenye kila seva ambayo funguo hiyo ilinakiliwa.

Je, ninahitaji nywila (passphrase) kwenye funguo yangu ya SSH?

Kwa funguo iliyo kwenye laptop au desktop, ndiyo. Passphrase hufunga faili ya funguo, hivyo nakala iliyoibiwa au iliyovuja haina matumizi peke yake, na ssh-agent inamaanisha utaandika mara moja kwa kila kikao badala ya kila wakati unapojiunganisha. Funguo zinazotumiwa na mifumo ya kiotomatiki (automation) kwenye seva kwa kawaida hazina passphrase, kwa sababu hakuna binadamu aliye hapo kuandika; ziweke salama kwa kuzuia kile ambacho akaunti hiyo inaweza kufanya.