SSH asoslari

Tarmoq diagnostikasi maqolasida server mavjudligini qanday tasdiqlash ko'rib chiqildi, lekin serverga yetib borish uni boshqarish degani emas. Masofaviy mashinada buyruq ishga tushirish, fayl o'qish yoki xizmatni qayta ishga tushirish uchun tarmoq orqali haqiqiy login sessiyasi kerak — production’da esa administrator deyarli hech qachon fizik mashina oldiga o'tirmaydi. Hammasi masofadan, tarmoq orqali, SSH (Secure Shell) va uning eng keng tarqalgan implementatsiyasi — OpenSSH yordamida bajariladi. Bu maqola SSH aslida nima qilishini, ssh klientidan qanday foydalanishni va birinchi ulanishda u chiqaradigan xabarlarni qanday o'qishni ko'rib chiqadi.

SSH qaysi muammoni hal qiladi

SSH standartga aylanishidan oldin xuddi shu vazifani Telnet bajarardi: u login, parol va butun sessiyani tarmoq orqali ochiq matnda yuborardi. O'sha tarmoq segmentida trafikni ushlagan har qanday odam — masalan, tcpdump bilan — parolni to'g'ridan-to'g'ri tarmoqdan o'qiy olardi. 1995-yilda paydo bo'lgan SSH aynan shu teshikni yopish uchun mavjud: ulanish o'rnatilishi bilan trafik shifrlanadi, shuning uchun tarmoqda na parol, na undan keyingi biror buyruq ko'rinmaydi.

Bugun SSH faqat interaktiv login uchun emas, bundan ko'proq narsa uchun asosiy qatlam:

• xavfsiz fayl uzatish (scp, sftp, rsync — scp va rsync maqolasida ko'rib chiqiladi);
• masofaviy serverda avtomatlashtirilgan skriptlarni ishga tushirish, masalan, CI/CD pipeline’dagi deploy qadami;
• port forwarding orqali ichki xizmatlarga yetib borish (SSH tunneling);
• Git repozitoriylariga xavfsiz kirish — [email protected]:... URL’i aslida SSH ulanishi.

Amalda "Linux serverni boshqarish" deyarli har doim o'sha serverga SSH terminal sessiyasini anglatadi.

Klient va server

SSH klient-server modeliga amal qiladi:

• SSH server — masofaviy mashinada ishlaydigan xizmat, odatda sshd (OpenSSH server daemon’i). U kiruvchi ulanishlarni tinglaydi va foydalanuvchi autentifikatsiyadan o'tgach, unga shell beradi yoki buyruq ishga tushirishga ruxsat beradi;
• SSH klient — ulanishni boshlaydigan tomon, odatda ssh buyrug'i (OpenSSH klienti) yoki Windows’dagi PuTTY kabi grafik vosita.

Ko'p zamonaviy distributivlarda ikkala tomonni ham OpenSSH loyihasi taqdim etadi — bu protokolning eng keng tarqalgan open-source implementatsiyasi. Ubuntu/Debian’da klient odatda oldindan o'rnatilgan bo'ladi, server esa alohida paket:

sudo apt update
sudo apt install openssh-server

Xizmat holatini tekshirish:

systemctl status ssh

SSH sukut bo'yicha TCP 22-portni tinglaydi — bu kursda avvalroq ko'rilgan portlar va socket’lar tushunchalarining to'g'ridan-to'g'ri davomi. Server tinglayotganini tasdiqlash:

sudo ss -tlnp | grep :22

LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=812,fd=3))

0.0.0.0:22 xizmat har bir tarmoq interfeysida ulanishlarni qabul qilishini bildiradi.

Shifrlash haqida qisqacha

SSH ulanishi ikkita mustaqil himoyani ustma-ust qo'yadi:

1. transport qatlami — klient va server handshake deb ataladigan jarayonda asimmetrik kriptografiya yordamida umumiy sessiya kalitini kelishib oladi; shundan keyin barcha trafik shu kalit bo'yicha simmetrik shifrlash bilan himoyalanadi;
2. autentifikatsiya qatlami — foydalanuvchi o'z shaxsini parol yoki — tavsiya etilgan usul — SSH kalit juftligi bilan isbotlaydi; bu SSH kalit autentifikatsiyasi maqolasida chuqur ko'rib chiqiladi.

Bu maqola shifrlash algoritmlarining matematikasiga kirmaydi. Administrator uchun muhimi — SSH sessiyasi boshidan oxirigacha shifrlangani va oradagi tarmoq uskunalari uning mazmunini o'qiy olmasligi.

ssh bilan ulanish

Eng oddiy shakl:

ssh user@server_address

Masalan:

ssh [email protected]

Agar lokal mashinadagi foydalanuvchi nomi masofaviy serverdagisi bilan bir xil bo'lsa, user@ qismini tushirib qoldirish mumkin:

ssh 192.168.1.50

Bunday holatda SSH avtomatik ravishda joriy lokal foydalanuvchi nomidan foydalanadi.

Birinchi ulanish: host key so'rovi

Muayyan serverga birinchi marta ulanganingizda shunga o'xshash xabar chiqadi:

The authenticity of host '192.168.1.50 (192.168.1.50)' can't be established.
ED25519 key fingerprint is SHA256:k3f9...Qz8.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Bu server o'zining host key'ini — uni identifikatsiya qiladigan kriptografik kalitni taqdim etayotgani. Klient bu kalitni ilgari hech qachon ko'rmagani uchun bu haqiqiy server ekanini qayerdan bilishi kerakligini so'raydi. yes deb javob berish kalitni ~/.ssh/known_hosts ga saqlaydi va u keyingi har bir ulanishda avtomatik solishtiriladi. Bu mexanizm man-in-the-middle hujumlariga qarshi birinchi himoya qatlami bo'lib, SSH-agent va host tekshiruvi maqolasida batafsil ko'rib chiqiladi.

Shundan keyin parol so'rovi chiqadi (kalit autentifikatsiyasi hali sozlanmagan deb faraz qilsak):

[email protected]'s password:

To'g'ri parol kiritilgach, masofaviy serverning shell prompt’i paydo bo'ladi — shu paytdan boshlab har bir buyruq lokal mashinada emas, o'sha serverda ishlaydi. Sessiyani yopish uchun:

exit

yoki Ctrl+D.

Foydali flag'lar

Masalan, 2222-portda ishlayotgan serverga ulanish:

ssh -p 2222 [email protected]

Ulanish muvaffaqiyatsiz bo'lganda birinchi diagnostika qadami deyarli har doim -v (batafsilroq uchun -vvv) bo'ladi:

ssh -v [email protected]

Bu muammo aynan qaysi bosqichda — xom TCP ulanishida, host key tekshiruvida yoki autentifikatsiyada — yuz berayotganini ko'rsatadi.

Interaktiv shell’siz bitta buyruqni ishga tushirish

ssh to'liq interaktiv sessiya ochishi shart emas. Buyruqni oxirgi argument sifatida berish serverda faqat shu bitta buyruqni ishga tushiradi va darhol qaytib, uning chiqishini lokal ekranga chiqaradi:

ssh [email protected] "uptime"

 10:42:05 up 3 days,  4:17,  2 users,  load average: 0.08, 0.03, 0.01

Deploy qadamlari, health-check va monitoring skriptlari ortida aynan shu shakl turadi — bu maqola boshidagi "masofaviy serverda avtomatlashtirilgan skriptlarni ishga tushirish" holati. Buyruqni lokal shell avval talqin qilib yubormasligi uchun uni qo'shtirnoqqa oling: qo'shtirnoqsiz ssh host echo $HOSTNAME $HOSTNAME ni masofaviy emas, lokal mashinada ochadi — bu klassik chalkashlik manbai. Bu moduldagi keyingi maqolalar shu shaklga doim tayanadi (ssh prod-web "uptime", ssh alice@server "sudo -l").

Amaliy vaziyat: "Connection refused" ni aniqlash

Muammo: yangi deploy qilingan serverga ssh [email protected] bilan ulanishga urinish quyidagini beradi:

ssh: connect to host 10.20.0.15 port 22: Connection refused

1-qadam — xato turini aniqlash: Connection refused paket TCP darajasida hostga yetib borganini, lekin 22-portni hech narsa tinglamayotganini bildiradi. Bu Connection timed out (tarmoq yoki firewall to'sig'i) yoki Could not resolve hostname (DNS muammosi) dan farq qiladi — har biri boshqa sababga ishora qiladi.

2-qadam — serverning o'zida xizmat holatini tekshirish (agar boshqa kirish yo'li bo'lsa):

systemctl status ssh

Agar xizmat inactive yoki failed ni ko'rsatsa, sabab shu.

3-qadam — xizmatni ishga tushirish va qayta tekshirish:

sudo systemctl start ssh
sudo systemctl enable ssh
sudo ss -tlnp | grep :22

4-qadam — klientdan qayta ulanish:

ssh -v [email protected]

5-qadam — natija: agar -v chiqishi endi ulanish o'rnatilayotganini va undan keyin autentifikatsiya so'rovini ko'rsatsa, muammo hal bo'lgan. Agar baribir refused bo'lsa, keyingi ehtimoliy sabab — firewall (sudo ufw status) yoki noto'g'ri port.

6-qadam — hujjatlashtirish: xizmat nega ishlamaganini (masalan, paket o'rnatilgandan keyin avtomatik ishga tushadigan qilib yoqilmagan) qayd qiling va keyingi qayta yuklashdan omon qolishi uchun enable qo'llanganini tasdiqlang.

Keng tarqalgan xatolar

Har qanday ulanish xatosini "server ishlamayapti" deb hisoblash

Connection refused, Connection timed out va Could not resolve hostname hammasi "ulanmadi" degandek tuyuladi, lekin ularning sabablari butunlay boshqa: mos ravishda ishlamayotgan xizmat, tarmoq/firewall to'sig'i va nomni resolve qilishdagi nosozlik. Har doim aniq xato matnini o'qing.

Host key ogohlantirishlarini odat bo'yicha avtomatik qabul qilish

Agar har bir yangi host key so'roviga yes deb yozish o'ylamasdan bajariladigan refleksga aylansa, xuddi shu refleks haqiqiy man-in-the-middle hujumi paytida ham ishlab ketadi. Agar fingerprint qayerdan kelishi kerakligini bilmasangiz, uni o'sha serverni boshqaradigan odam bilan alohida kanal orqali tasdiqlang.

Parol autentifikatsiyasiga cheksiz tayanish

Parol bilan kirish ishlaydi, lekin production serverlar uchun tavsiya etilmaydi — u brute-force urinishlariga ochiq va har bir ulanishda parol yozishni talab qiladi. Keyingi maqolada ko'riladigan kalitga asoslangan autentifikatsiya ham xavfsizroq, ham qulayroq.

Mashqlar

1. Laboratoriya VM’ingizga ssh -v user@server_ip bilan ulaning va batafsil chiqishdagi asosiy bosqichlarni (TCP ulanish, host key tekshiruvi, autentifikatsiya) aniqlang.
2. sudo ss -tlnp | grep :22 chiqishidan 22-portni qaysi jarayon (nomi va PID i) tinglayotganini toping.
3. SSH xizmatini ataylab to'xtating (sudo systemctl stop ssh), boshqa terminaldan ulanishga urining, aniq xatoni kuzating, so'ng xizmatni tiklang.
4. ~/.ssh/known_hosts ni oching va undagi bitta qatorning tuzilishini (host, kalit turi, kalitning o'zi) tushuntiring.

Mashqni bajardim deyish uchun: 3-mashqda xizmat to'xtatilgan paytdagi ulanish urinishi timeout yoki DNS xatosini emas, Connection refused ni ko'rsatishi kerak — agar boshqa narsa ko'rsatsa, aslida qaysi xizmatni to'xtatganingizni qayta tekshiring.

Manbalar

• OpenSSH — rasmiy sayt
• man7.org: ssh(1)
• man7.org: sshd(8)
• Ubuntu Server — OpenSSH hujjatlari
• RFC 4251 — The Secure Shell (SSH) Protocol Architecture