SSH bez paroles: autentifikācija ar šifrētām atslēgām
SSH pieslēgšanās ar paroli ir vienkārša, bet tā nav optimāla ne drošībai, ne ērtībai. Paroles var uzminēt ar bruteforce, tās mēdz noplūst, un tās ir neērti regulāri mainīt. Autentifikācija ar šifrētu atslēgu pāri (public/private key) ļauj pieslēgties bez paroles ievades, vienlaikus būtiski paceļot drošības līmeni: serveris pieņem tikai klientus, kuri spēj pierādīt, ka viņiem ir privātā atslēga, un privātā atslēga nekad netiek nosūtīta pa tīklu.
Šī pieeja ir īpaši noderīga, ja jums ir vairāki serveri, automātiskas izvietošanas (deploy) skripti, rezerves kopijas vai vienkārši vēlme izvairīties no paroļu “kopēšanas” starp komandas biedriem. Praktiski visi modernie SSH klienti (Linux/macOS OpenSSH, Windows OpenSSH, PuTTY u.c.) atbalsta atslēgu autentifikāciju. Ja jūsu projekts darbojas uz virtuālā servera, atslēgu izmantošana ir viena no pirmajām lietām, ko ieteicams iestatīt. Lielākām slodzēm un atsevišķai aparatūrai tas pats princips attiecas uz serveru īri, bet vienkāršākiem web projektiem var pietikt arī ar hostingu, kur SSH piekļuve un atslēgas bieži tiek izmantotas administrēšanai.
1) Kā strādā SSH atslēgas (īsumā, bet saprotami)
Atslēgu pāris sastāv no privātās atslēgas (glabājas tikai pie jums) un publiskās atslēgas (to var droši ievietot serverī). Kad pieslēdzaties, serveris “izaicina” klientu parakstīt datus ar privāto atslēgu. Ja paraksts atbilst publiskajai atslēgai, kas atrodas serverī, autentifikācija tiek uzskatīta par derīgu. Rezultātā parole nav jāievada, un uzbrucējam nav ko “uzminēt”, ja vien viņš nav ieguvis privāto atslēgu.
Privāto atslēgu vienmēr aizsargājiet ar paroli (passphrase). Tas izklausās kā pretruna “bez paroles”, bet ideja ir cita: jūs ievadāt paroli vienreiz, lai atbloķētu atslēgu lokāli, un pēc tam SSH var izmantot atslēgu, piemēram, ar ssh-agent. Ja kāds nozog jūsu failu ar privāto atslēgu, bez passphrase to ir daudz grūtāk izmantot.
2) Izveidojiet atslēgu pāri (Linux/macOS/Windows OpenSSH)
Visbiežāk izmanto ed25519 atslēgas — tās ir modernas, īsas un drošas. Ja jums ir ļoti vecas sistēmas, var nākties izmantot RSA, bet mūsdienās ed25519 parasti ir labākā izvēle. Atslēgu pāri ģenerē lokālajā datorā, nevis serverī.
ssh-keygen -t ed25519 -a 64 -C "jusu.vards@uznemums"
Komanda izveidos divus failus: privāto atslēgu (piem., ~/.ssh/id_ed25519) un publisko atslēgu (piem., ~/.ssh/id_ed25519.pub). Parametrs -a palielina atslēgas atvasināšanas sarežģītību (tas palīdz pret bruteforce, ja atslēga tiek nozagta). Pēc ģenerēšanas pārbaudiet, ka ~/.ssh direktorijas un privātās atslēgas atļaujas ir drošas (700 direktorijai, 600 atslēgai).
3) Iekopējiet publisko atslēgu serverī
Vienkāršākais variants ir ssh-copy-id, ja tas ir pieejams. Tas automātiski pievieno publisko atslēgu servera lietotāja failam ~/.ssh/authorized_keys un sakārto atļaujas.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@servera-ip
Ja ssh-copy-id nav pieejams, varat darīt manuāli: izveidojiet ~/.ssh direktoriju serverī, ielīmējiet publisko atslēgu authorized_keys failā un iestatiet pareizas atļaujas. Būtiski: authorized_keys satur publiskās atslēgas vienā rindā katrai atslēgai; nepievienojiet tur privāto atslēgu.
mkdir -p ~/.ssh chmod 700 ~/.ssh nano ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys
Pēc tam pārbaudiet pieslēgšanos:
ssh -i ~/.ssh/id_ed25519 user@servera-ip
Ja viss ir pareizi, serveris vairs neprasīs konta paroli (vai prasīs tikai privātās atslēgas passphrase lokāli).
4) Sakārtojiet ssh-agent ērtākai ikdienai
Lai nav jāievada passphrase katru reizi, izmantojiet ssh-agent. Linux/macOS bieži tas jau ir pieejams; Windows var izmantot OpenSSH Authentication Agent. Ideja: jūs vienreiz ielādējat atslēgu aģentā, un nākamie SSH savienojumi to izmanto automātiski.
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
Komandas rezultātā atslēga tiek ielādēta aģentā. Ja izmantojat grafisko vidi, iespējams, aģents strādā jau “zem pārsega”. Drošībai: neaizmirstiet bloķēt datoru, jo atbloķēta atslēga aģentā nozīmē, ka lietotājs pie šīs sesijas var izveidot SSH savienojumus.
5) Nostipriniet serveri: atslēgas obligātas, parole izslēgta
Kad pārliecinājāties, ka pieslēgšanās ar atslēgu strādā, jūs varat ievērojami samazināt uzbrukumu virsmu, atslēdzot paroļu autentifikāciju. Tas ir īpaši svarīgi serveriem ar publisku SSH portu, jo bruteforce skenēšana notiek nepārtraukti. Pirms izslēdzat paroli, pārliecinieties, ka jums ir vismaz viena strādājoša atslēga un rezerves piekļuve (piem., konsoles pieeja pie hostinga).
Atveriet /etc/ssh/sshd_config un iestatiet (vērtības var atšķirties pēc distribūcijas):
PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no
Pēc izmaiņām pārstartējiet sshd:
sudo systemctl restart sshd
Drošības bonuss: apsveriet arī PermitRootLogin aizliegšanu un pieslēgšanos kā parastam lietotājam ar sudo. Tāpat ieteicams izmantot ugunsmūri un, ja nepieciešams, ierobežot SSH piekļuvi pēc IP (piem., tikai jūsu biroja vai VPN).
6) Biežākās problēmas un to risinājumi
Ja serveris joprojām prasa paroli, biežākie iemesli ir: publiskā atslēga nav pareizi pievienota, failu atļaujas nav pareizas, vai arī jūs pieslēdzaties ar citu lietotāju. Pārbaudiet, ka serverī ~/.ssh ir 700, authorized_keys ir 600 un ka faila īpašnieks ir pareizais lietotājs. Vēl bieža problēma ir tas, ka jūs ģenerējāt atslēgu citā kontā vai mēģināt izmantot nepareizo -i failu.
Ja redzat kļūdu “Permission denied (publickey)”, ieslēdziet detalizētu klienta izvadi:
ssh -vvv user@servera-ip
Žurnālos (serverī) noder /var/log/auth.log vai journald ieraksti. Tur bieži ir tiešā norāde, piemēram, “bad ownership or modes”.
Ja izmantojat vairākas atslēgas un serverus, izveidojiet ~/.ssh/config failu, lai izvairītos no kļūdām un paātrinātu darbu. Tajā var norādīt Host alias, User, IdentityFile un Port. Tas ir īpaši ērti, ja jums ir atšķirīgi lietotāji vai nestandarta ports.
Ja strādājat no Windows un izmantojat PuTTY, jums bieži vajadzēs pārvērst OpenSSH formāta atslēgu uz PuTTY formātu (PPK) vai arī izmantot Windows iebūvēto OpenSSH, kas jaunākās Windows versijās jau ir pēc noklusējuma. Praktiska rekomendācija: vienā komandā izmantojiet OpenSSH visur, kur iespējams, jo tas atvieglo atslēgu pārvaldību un dokumentāciju.
Atslēgu algoritmu izvēlē: ed25519 ir labs noklusējums, bet dažās korporatīvās vidēs var prasīt RSA ar noteiktu garumu (piem., 3072 vai 4096). Ja izmantojat RSA, izvairieties no vecajiem SHA-1 parakstiem un pārliecinieties, ka serveris atbalsta modernākus algoritmus. Ja neesat pārliecināts, drošākais ir sākt ar ed25519 un saglabāt vienu rezerves RSA atslēgu tikai savietojamībai.
Komanddarbā noder pieeja “viena persona — viena atslēga — viens mērķis”. Piemēram, atsevišķa atslēga ikdienas administrācijai un atsevišķa atslēga automatizētam deploy procesam. Tas ļauj ierobežot atslēgas tiesības un ātrāk atrast problēmas, ja kāds process sāk uzvesties dīvaini.
Ja vēlaties vēl lielāku kontroli, authorized_keys rindai var pievienot ierobežojumus: no kurām IP adresēm atslēga drīkst darboties (from="...") vai kādu komandu atļauts izpildīt (command="..."). Tas ir ļoti noderīgi automatizācijai, piemēram, kad rezerves kopiju serverim atļaujat tikai rsync komandu, nevis pilnu shell. Šādi ierobežojumi samazina risku pat tad, ja atslēga tiek kompromitēta.
Neaizmirstiet par atslēgu rotāciju un inventarizāciju. Reizi noteiktā periodā pārskatiet authorized_keys, izdzēsiet vairs neizmantotās atslēgas un atjaunojiet tās, kurām ir aizdomas par kompromitāciju. Praktiski: pie atslēgas komentāra (tas, ko pievienojat ar -C) ielieciet cilvēka vārdu, ierīci un datumu, lai pēc pusgada būtu skaidrs, kas ir kas.
Ja jums ir vairākas komandas vai klientu projekti, izmantojiet atslēgu nosaukšanas standartu un atsevišķus SSH config ierakstus, lai nejauši nepieslēgtos nepareizajam serverim. Tas ir biežāks risks nekā šķiet: vienkārša kļūda var izraisīt komandu izpildi nepareizā vidē.
Papildus drošībai varat ieslēgt divu faktoru autentifikāciju pašam serverim caur PAM risinājumiem, taču bieži pietiek ar atslēgām + IP ierobežojumu + regulāriem atjauninājumiem. Galvenais ir nepārvērst drošību par tik sarežģītu, ka komanda sāk meklēt apvedceļus.
Praktisks kontrolsaraksts un labākā prakse
Pirms paroles autentifikācijas atslēgšanas izpildiet šo kontrolsarakstu: (1) pārbaudiet pieslēgšanos ar atslēgu no vismaz divām ierīcēm (piem., darba dators un rezerves laptops), (2) pārliecinieties, ka privātajai atslēgai ir passphrase, (3) ielādējiet atslēgu ssh-agent, (4) izveidojiet atsevišķu administratīvu lietotāju un atslēdziet root login, (5) ierobežojiet piekļuvi ar ugunsmūri vai VPN, (6) saglabājiet dokumentāciju par to, kuras atslēgas pieder kuriem cilvēkiem.
Komandām un komanddarba piekļuvei: neizmantojiet vienu kopīgu atslēgu visiem. Katram administratoram jābūt savai atslēgai, un aiziešanas gadījumā jūs vienkārši izņemiet konkrēto publisko atslēgu no authorized_keys. Ja jums ir daudz serveru, apsveriet centralizētu atslēgu pārvaldību vai konfigurācijas pārvaldības rīkus. Un vienmēr atcerieties: drošība ir process, nevis vienreizējs uzdevums.