Apa itu SSH dan bagaimana ia berfungsi?

Apakah itu SSH?

SSH (secure shell) ialah protokol untuk log masuk ke komputer di lokasi lain dan menjalankan arahan padanya melalui sambungan yang disulitkan. Apa yang anda taip akan dihantar ke mesin jauh, keluarannya akan dihantar semula, dan sesiapa yang memantau rangkaian di antara kedua-duanya tidak dapat membaca maklumat tersebut. Pelayan Linux yang disewa tidak mempunyai skrin atau papan kekunci yang disambungkan kepadanya, jadi SSH merupakan cara utama mesin tersebut digunakan.

Nama ini merangkumi dua perkara. SSH ialah protokol yang diterangkan dalam RFC 4251 hingga RFC 4254. OpenSSH ialah program yang melaksanakannya, dan ia merupakan perisian yang dijalankan oleh hampir setiap pelayan Linux dan hampir setiap komputer riba. Apabila seseorang berkata "SSH ke dalam pelayan", mereka bermaksud program klien ssh pada mesin mereka sedang berkomunikasi dengan program pelayan sshd di hujung sana.

Masalah yang ingin diselesaikan oleh SSH

Log masuk jauh jauh lebih lama daripada SSH. Telnet membuka sambungan TCP biasa ke port 23 dan menghantar setiap bait tepat seperti yang ditaip. Tiada apa-apa yang disulitkan, termasuk kata laluan anda. Sesiapa yang boleh melihat trafik tersebut boleh membacanya: seseorang dalam rangkaian pejabat yang sama, atau pengendali mana-mana router di sepanjang laluan tersebut. Keluarga rlogin mempunyai kelemahan yang sama, dan ia mempercayai mesin klien berdasarkan nama, yang bermaksud mempercayai apa sahaja yang didakwa oleh rangkaian sebagai nama tersebut.

Tatu Ylönen menulis SSH pertama pada tahun 1995 di Helsinki University of Technology, selepas serangan mengintip kata laluan (password sniffing) pada rangkaian universiti. Reka bentuknya mengekalkan bahagian berguna telnet, iaitu aliran bait antara terminal anda dan shell jauh, serta menambah dua perkara yang tidak dapat diselesaikan oleh telnet: penyulitan aliran tersebut, dan bukti bahawa pelayan di hujung sana adalah pelayan yang ingin anda hubungi.

Bahagian kedua itu mudah terlepas pandang, dan ia merupakan separuh daripada fungsi SSH. Penyulitan sahaja tidak akan menyelamatkan anda. Mesin di tengah-tengah boleh menerima sambungan anda, menyulitkannya dengan sempurna, membaca segala yang anda hantar, dan menyampaikannya kepada pelayan sebenar. SSH menyekat perkara itu dengan memberikan setiap pelayan identiti kekal, yang dipanggil host key, dan menyemaknya pada setiap sambungan.

Cara model klien dan pelayan berfungsi

Terdapat dua program. Pada pelayan, sshd berjalan sepanjang masa dan menunggu sambungan. Pada mesin anda, ssh membuat sambungan tersebut. Kedua-duanya adalah program berasingan dengan fail konfigurasi yang berasingan, dan kekeliruan antara keduanya merupakan punca paling lazim mengapa sesuatu suntingan tidak memberikan kesan.

• Pelayan membaca /etc/ssh/sshd_config. Di sinilah log masuk kata laluan dimatikan dan port pendengaran ditetapkan.
• Klien membaca /etc/ssh/ssh_config untuk tetapan lalai sistem, kemudian ~/.ssh/config untuk tetapan hos peribadi anda.

Pada Debian dan Ubuntu, unit servis dipanggil ssh. Pada RHEL, Rocky dan Fedora, ia dipanggil sshd. Keluaran Ubuntu terkini memasangnya dengan pengaktifan soket, jadi systemctl status ssh mungkin melaporkan inactive (dead) walaupun mesin tersebut boleh dicapai sepenuhnya, kerana ssh.socket merupakan unit yang melakukan pendengaran dan ia memulakan servis apabila diminta.

Klien tidak semestinya OpenSSH. PuTTY pada Windows, Termius pada telefon, dan sokongan jauh yang terbina dalam editor semuanya menggunakan protokol yang sama untuk berhubung dengan sshd yang sama. Windows 10 dan 11 juga menyertakan klien OpenSSH, jadi ssh you@server berfungsi dalam PowerShell tanpa perlu memasang apa-apa.

Mengapa SSH menggunakan port 22?

Port ialah nombor yang memberitahu kernel program mendengar (listening) yang mana satu perlu menerima sambungan masuk, dan port pada Linux berfungsi dengan cara yang sama untuk setiap servis. SSH menggunakan 22 kerana IANA menetapkannya pada tahun 1995. Ylönen meminta nombor percuma yang terletak bersebelahan dengan protokol yang ingin digantikan oleh SSH: 21 ialah FTP, 23 ialah telnet, dan 22 tidak digunakan.

Oleh kerana 22 ialah tetapan lalai, segala-galanya menganggap ia adalah port tersebut. Git remote anda, skrip sandaran anda dan panel kawalan pembekal anda semuanya mencuba port 22 terlebih dahulu. Begitu juga dengan setiap pengimbas automatik di internet. Pelayan baharu dengan log masuk kata laluan yang diaktifkan akan mula mengumpul baris seperti ini dalam /var/log/auth.log dalam masa beberapa minit selepas but:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Trafik tersebut adalah malar, dan ia tidak disasarkan kepada anda secara peribadi. Mengalihkan sshd ke port 2222 akan membuang kebanyakan baris tersebut, kerana pengimbas sedang menyapu seluruh internet pada port 22 dan bukannya mengkaji pelayan anda. Ia tidak menjadikan mesin tersebut lebih sukar untuk diceroboh bagi sesiapa yang benar-benar melihatnya. Anggap perubahan port sebagai pengurangan gangguan (noise reduction) dan tiada yang lain.

Anda boleh melihat pelayan menjawab sebelum anda log masuk sama sekali:

nc 203.0.113.10 22

Pada Ubuntu 24.04, ia mencetak sesuatu yang hampir dengan SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. Sepanduk (banner) dihantar dalam teks jelas (cleartext), sebelum sebarang penyulitan wujud, kerana kedua-dua pihak memerlukannya untuk bersetuju dengan versi protokol. Tekan Ctrl+C untuk menutup sambungan.

Apa yang berlaku pada rangkaian apabila anda menyambung

Urutan di bawah adalah perkara yang dilakukan oleh ssh you@server sebelum anda melihat prompt.

1. Klien menyelesaikan hostname kepada alamat IP, kemudian membuka sambungan TCP ke port 22.
2. Kedua-dua pihak menghantar banner versi mereka dalam teks jelas (cleartext).
3. Kedua-dua pihak menghantar senarai algoritma yang disokong: pertukaran kunci, cipher, pengesahan mesej, dan pemampatan. Masih dalam teks jelas. Pilihan paling kuat yang diketahui oleh kedua-dua pihak akan dipilih.
4. Pertukaran kunci dijalankan. OpenSSH semasa lebih mengutamakan curve25519-sha256. Kedua-dua hujung akan memegang rahsia kongsi yang sama tanpa rahsia tersebut merentasi rangkaian, jadi sesiapa yang merakam keseluruhan perbualan tidak dapat menentukannya kemudian.
5. Pelayan menandatangani hasil pertukaran tersebut dengan kunci peribadi hosnya. Klien anda menyemak tandatangan tersebut terhadap kunci awam hos yang disimpan dalam fail. Ini adalah langkah yang menghalang mesin di tengah daripada menyamar sebagai pelayan anda.
6. Penyulitan bermula. chacha20-poly1305@openssh.com ialah cipher lalai dalam OpenSSH semasa.
7. Hanya selepas ini klien mengesahkan identiti anda, sama ada dengan kata laluan atau kunci. Nama pengguna dan kata laluan anda bergerak di dalam saluran yang disulitkan.
8. Klien membuka saluran dan meminta shell.

Urutan dalam senarai tersebut adalah perbezaan keseluruhan berbanding telnet. Pengesahan berlaku selepas saluran disulitkan dan selepas pelayan membuktikan identitinya, jadi tiada saat di mana kata laluan anda berada di atas talian secara terbuka.

Seseorang yang memerhati rangkaian masih boleh mengetahui sesuatu. Mereka melihat alamat IP anda, alamat IP pelayan, port 22, kedua-dua banner versi teks jelas, serta masa dan anggaran saiz setiap paket. Mereka tidak melihat nama pengguna, kata laluan, arahan, atau output anda. Carian hostname dalam langkah 1 bukan sebahagian daripada SSH dan biasanya tidak peribadi, jadi query DNS yang menyelesaikan nama pelayan anda boleh mendedahkan mesin mana yang anda akan hubungi walaupun sesi itu sendiri kekal tertutup.

Host key dan gesaan cap jari sambungan pertama

Apabila openssh-server dipasang, ia menjana pasangan host key untuk mesin tersebut dan menulisnya ke /etc/ssh/, contohnya ssh_host_ed25519_key dan ssh_host_ed25519_key.pub. Bahagian kunci persendirian tidak akan keluar dari pelayan. Bahagian kunci awam ialah identiti pelayan, dan ia merupakan perkara yang disemak terhadap tandatangan dalam langkah 5.

Kali pertama anda menyambung ke pelayan baharu, klien anda tidak mempunyai apa-apa untuk dibuat perbandingan, jadi ia bertanya kepada anda:

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

Cap jari tersebut ialah hash SHA256 bagi kunci awam host, dicetak dalam base64, supaya ia cukup pendek untuk dibandingkan dengan mata. Menaip yes akan menulis kunci tersebut ke dalam ~/.ssh/known_hosts pada mesin anda sendiri. Setiap sambungan seterusnya ke alamat yang sama akan membandingkan kunci yang ditawarkan oleh pelayan dengan kunci yang disimpan. Apabila ia sepadan, tiada apa-apa yang dicetak dan anda terus pergi ke prompt anda.

Model ini dipanggil trust on first use, dan adalah wajar untuk bersikap jujur tentang kosnya. Sambungan pertama ialah satu-satunya saat anda tidak dilindungi, kerana anda menerima kunci yang tidak pernah anda lihat sebelum ini. Untuk menutup jurang tersebut, dapatkan cap jari melalui laluan lain dan buat perbandingan. Kebanyakan penyedia mencetaknya dalam output but yang ditunjukkan dalam konsol web mereka, dan anda juga boleh mencetaknya pada pelayan itu sendiri:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Perintah itu mencetak rentetan SHA256: yang sama seperti yang ditunjukkan oleh gesaan tersebut. Pilihan [fingerprint] dalam gesaan wujud tepat untuk tujuan ini: tampal cap jari yang anda jangkakan, dan klien hanya akan meneruskan jika ia sepadan dengan apa yang dibentangkan oleh pelayan.

Pada Debian dan Ubuntu, known_hosts di-hash secara lalai, jadi fail tersebut mengandungi baris yang bermula dengan |1| dan bukannya nama host yang boleh dibaca. Jalankan ssh-keygen -F 203.0.113.10 untuk mencari entri bagi satu host.

Mengapa SSH menyatakan kunci hos telah berubah?

Lambat-laun anda akan berhadapan dengan blok teks ini:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Ia berakhir dengan Host key verification failed. dan klien enggan membuat sambungan. Ia juga memaparkan Password authentication is disabled to avoid man-in-the-middle attacks., kerana menaip kata laluan anda ke dalam mesin yang tidak dikenali adalah bahaya sebenar yang cuba dicegah oleh pemeriksaan ini.

Mesej tersebut kelihatan seperti kecemasan, namun selalunya ia bukan. Punca-punca biasa adalah:

• Anda membina semula atau memasang semula pelayan, jadi sshd menjana kunci hos baharu semasa but pertama. Ini merupakan sebab yang paling kerap berlaku.
• Anda memadamkan satu VPS dan mencipta yang lain, dan pembekal memberikan alamat IP lama kepada mesin baharu tersebut.
• Anda menyambung melalui forward atau load balancer yang kini mencapai mesin backend yang berbeza.
• Sesuatu benar-benar memintas sambungan tersebut.

Tentukan punca sebenar sebelum anda memadamkan apa-apa. Jika anda memasang semula mesin sepuluh minit yang lalu, puncanya sudah jelas. Jika tiada apa-apa yang berubah di pihak anda, berhenti dan lakukan siasatan, kerana amaran ini adalah fungsi pemeriksaan tersebut yang sedang berjalan. Setelah anda pasti, buang entri lama dan sambung semula:

ssh-keygen -R 203.0.113.10

Sambungan seterusnya akan memaparkan gesaan cap jari (fingerprint) sekali lagi, yang memberi anda peluang baharu untuk membandingkannya dengan konsol pembekal.

Log masuk kata laluan berbanding log masuk kunci

Pengesahan kata laluan menghantar kata laluan anda di dalam saluran yang telah disulitkan, dan sshd menyemaknya terhadap pangkalan data akaun, biasanya melalui PAM (pluggable authentication modules). Ia tidak memerlukan penyediaan, itulah sebabnya penyedia boleh memberikan anda pelayan baharu yang hanya mempunyai kata laluan root.

Kelemahannya bukan pada penyulitan. Kelemahannya ialah kata laluan merupakan rahsia yang pendek, anda menghantarnya ke pelayan pada setiap log masuk, dan port 22 diteka sepanjang masa oleh mesin yang tidak pernah berasa bosan.

Pengesahan kunci awam berfungsi secara berbeza. Anda mencipta pasangan kunci pada mesin anda sendiri. Separuh awam diletakkan ke dalam ~/.ssh/authorized_keys di dalam akaun anda pada pelayan. Separuh peribadi kekal pada komputer riba anda dan tidak pernah dihantar. Untuk log masuk, klien menandatangani sekeping data yang merangkumi pengecam sesi daripada pertukaran kunci, dan pelayan mengesahkan tandatangan tersebut menggunakan kunci awam yang sudah dimilikinya. Oleh kerana data yang ditandatangani terikat pada sesi ini sahaja, tandatangan yang ditangkap tidak berguna terhadap perkara lain.

Perhatikan arahnya, kerana menyongsangkannya adalah perkara biasa dan ia berbahaya: kunci awam diletakkan pada pelayan, kunci peribadi kekal bersama anda. Kunci peribadi yang disalin ke pelayan ialah kunci peribadi yang tidak lagi boleh anda percayai.

Log masuk kunci mempunyai mod kegagalannya sendiri. sshd mengabaikan kunci apabila keizinan fail terlalu longgar, dan ia menyatakan perkara tersebut dalam log pelayan:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Klien hanya memberitahu anda Permission denied (publickey), yang merupakan mesej yang sama untuk sedozen punca yang berbeza, jadi membaca ralat publickey dengan betul adalah berbaloi untuk dipelajari sebelum anda terkunci keluar. Kerja praktikal mencipta kunci, melindunginya dengan frasa laluan dan memuatkannya ke dalam ejen tergolong dalam pengurusan kunci SSH, dan mematikan log masuk kata laluan tanpa membiarkan diri anda terkandas tergolong dalam memperkukuh SSH pada VPS.

SFTP, scp dan port forwarding menggunakan sambungan yang sama

Ini adalah konsep yang menjadikan dunia SSH lebih mudah difahami. Pengesahan membuka sambungan yang disulitkan, dan sambungan tersebut boleh membawa beberapa saluran bebas pada masa yang sama. Shell hanyalah salah satu jenis saluran daripada beberapa saluran yang ada.

• Shell jauh. ssh you@server membuka saluran sesi dan meminta shell interaktif.
• Perintah tunggal. ssh you@server uptime membuka saluran, menjalankan satu perintah, mencetak output dan keluar.
• SFTP. Pelanggan meminta sshd untuk memulakan subsistem sftp miliknya, dan pemindahan fail berjalan di dalam sambungan yang sama. SFTP ialah protokol pemindahan fail yang menggunakan SSH, dan ia tidak mempunyai kaitan reka bentuk dengan FTP. Protokol yang merupakan FTP dengan tambahan penyulitan dipanggil FTPS, dan ia tidak berkaitan.
• scp. Menyalin fail menggunakan log masuk yang sama. Sejak OpenSSH 9.0, yang dikeluarkan pada tahun 2022, scp menggunakan protokol SFTP di bahagian bawah secara lalai.
• Port forwarding. ssh -L 8080:localhost:80 you@server menukarkan port 8080 pada komputer riba anda menjadi pintu masuk ke port 80 pada pelayan, yang dibawa di dalam sambungan yang disulitkan. -R memajukan trafik ke arah yang bertentangan, dan -D 1080 menukarkan sesi tersebut menjadi proksi SOCKS.
• Git. Remote seperti git@github.com:user/repo.git ialah log masuk SSH yang bahagian jauhnya menjalankan pengendali perintah dan bukannya shell.
• rsync dan Ansible juga merupakan pelanggan SSH. Mereka membuka saluran, menjalankan sesuatu, dan membaca semula outputnya.

Setiap item dalam senarai tersebut menggunakan port yang sama, semakan kunci hos yang sama dan kelayakan yang sama. Itulah sebabnya menyediakan pengesahan kunci sekali sahaja akan memberikan manfaat serta-merta: setiap alat tersebut mewarisinya. Itulah juga sebabnya fail ~/.ssh/config yang sama yang memendekkan log masuk anda adalah fail yang sama yang berskala apabila anda menguruskan beberapa pelayan Linux daripada satu komputer riba.

Perkara yang tidak dilakukan oleh SSH

• Ia tidak menjadikan pelayan anda selamat. SSH melindungi laluan ke pintu. Pintu tersebut masih wujud, dan orang ramai akan terus mencuba tombolnya. Menyekat percubaan log masuk berulang dengan fail2ban menguruskan jumlah percubaan tersebut, dan pengesahan berasaskan kunci sahaja akan menghapuskan perkara yang mereka cuba teka.
• Ia tidak melindungi anda daripada mesin anda sendiri. Sesiapa yang mempunyai akses kepada komputer riba anda memiliki kunci peribadi dan ejen anda yang sedang dimuatkan.
• Ia tidak menyembunyikan fakta bahawa anda sedang menggunakan SSH. Nombor port dan banner versi teks jelas (cleartext) mengumumkannya.
• Ia tidak melindungi apa yang berlaku sebelum sambungan wujud. Carian nama, dan keputusan anda tentang alamat mana yang ingin dipercayai, kedua-duanya berlaku terlebih dahulu.

Langkah seterusnya

Jika anda sedang membuka pelayan baharu dalam konsol penyedia sekarang, urutan langkah yang berguna adalah tetap. Masuk ke dalam sistem, cipta pengguna biasa, pasang kunci anda, kemudian tutup laluan akses mudah di belakang anda. Sepuluh minit pertama pada VPS baharu membimbing anda melalui urutan tersebut dari awal hingga akhir, dan apa itu VPS sebenarnya menerangkan mesin di sebalik sistem tersebut jika istilah yang digunakan masih baharu bagi anda. Selepas itu, kunci dan pengukuhan keselamatan (hardening) adalah dua artikel yang perlu dibaca, mengikut urutan tersebut.

FAQ

Apakah maksud SSH?

SSH bermaksud secure shell. Ia merupakan protokol untuk log masuk ke komputer jauh dan menjalankan arahan ke atasnya melalui sambungan yang disulitkan, seperti yang ditakrifkan dalam RFC 4251 hingga RFC 4254. OpenSSH ialah implementasi yang digunakan oleh hampir semua orang: klien ssh pada mesin anda, dan pelayan sshd pada mesin jauh. Ia menggantikan telnet, yang menghantar segala-galanya termasuk kata laluan merentasi rangkaian dalam teks biasa.

Mengapa SSH menggunakan port 22?

IANA menetapkan port 22 kepada SSH pada tahun 1995, bersebelahan dengan FTP pada 21 dan telnet pada 23, iaitu protokol yang ia dicipta untuk menggantikannya. Tiada apa yang memaksa penggunaan nombor tersebut: Port dalam /etc/ssh/sshd_config menukarnya pada pelayan, dan ssh -p memilih port yang berbeza pada klien. Kerana 22 ialah tetapan lalai, pengimbas automatik mengetuk port tersebut secara berterusan, itulah sebabnya /var/log/auth.log pada pelayan baharu dipenuhi dengan baris Failed password for invalid user. Menukar port hanya mengurangkan gangguan tersebut dan tidak memberikan perlindungan sebenar.

Apakah yang perlu saya lakukan apabila SSH memberi amaran bahawa host key telah berubah?

Cari puncanya sebelum anda memadamkan apa-apa. Sebab yang biasa berlaku adalah tidak berbahaya: pelayan telah dibina semula, jadi sshd menjana host key baharu, atau mesin baharu diberikan alamat IP lama. Jika anda tahu mesin tersebut telah dibina semula, jalankan ssh-keygen -R <host> untuk membuang kunci yang disimpan, sambung semula, dan bandingkan fingerprint yang dipaparkan dengan yang dilaporkan oleh konsol pembekal anda. Jika tiada apa-apa yang berubah pada pihak anda, jangan sambungkan dan jangan taip kata laluan anda. OpenSSH sudah pun menolak pengesahan kata laluan dalam keadaan ini atas sebab tersebut.

Adakah SFTP dan scp berbeza daripada SSH?

Ia berjalan di atas SSH. Sebaik sahaja anda disahkan, sambungan SSH boleh membawa beberapa saluran, dan shell hanyalah salah satu daripadanya. SFTP ialah protokol pemindahan fail yang menggunakan subsistem sftp daripada sshd melalui sambungan yang sama, dan scp telah menggunakan protokol SFTP di bawahnya sejak OpenSSH 9.0. Port forwarding dan Git melalui SSH juga merupakan saluran pada sambungan yang sama. Kesemuanya menggunakan port yang sama, semakan host key yang sama, dan log masuk yang sama. Perlu diingat bahawa SFTP bukanlah FTP yang ditambah penyulitan; protokol itu dipanggil FTPS dan ia merupakan protokol yang berasingan.

Adakah pengesahan kunci benar-benar lebih baik daripada kata laluan?

Ya, untuk mana-mana pelayan yang boleh dicapai dari internet. Kata laluan ialah rahsia pendek yang anda berikan kepada pelayan pada setiap log masuk, dan port 22 diteka secara berterusan oleh klien automatik. Dengan pasangan kunci, bahagian kunci peribadi tidak pernah meninggalkan mesin anda: klien menandatangani data yang terikat dengan sesi semasa, dan pelayan menyemak tandatangan tersebut terhadap kunci awam dalam ~/.ssh/authorized_keys. Tandatangan yang direkodkan tidak boleh dimainkan semula terhadap pelayan lain. Lindungi kunci peribadi dengan passphrase, kerana fail kunci tanpa passphrase merupakan log masuk yang boleh digunakan oleh sesiapa sahaja yang menyalinnya.