Cara urus kunci SSH dengan selamat dan betul

Cara kunci SSH berfungsi

Kunci SSH terdiri daripada sepasang fail: kunci peribadi yang kekal pada peranti anda dan kunci awam yang anda salin ke setiap pelayan yang ingin anda log masuk. Apabila anda menyambung, pelayan menggunakan kunci awam untuk menghantar cabaran yang hanya boleh dijawab oleh kunci peribadi yang sepadan. Kunci peribadi tidak pernah meninggalkan peranti anda, jadi tiada rahsia yang dihantar melalui rangkaian, dan pelayan yang terjejas tidak mempunyai apa-apa yang berguna untuk dicuri. Itulah sebabnya kunci lebih baik daripada kata laluan. Pengurusan kunci SSH yang baik bergantung kepada empat tabiat: satu kunci bagi setiap peranti, keizinan fail yang dituntut oleh sshd, fail ~/.ssh/config supaya anda berhenti menaip pilihan, dan mengetahui cara membuang kunci pada hari komputer riba hilang.

Panduan ini merangkumi setiap tabiat pada Ubuntu 24.04, walaupun hampir semua perkara di sini terpakai untuk mana-mana pelayan Linux dan mana-mana OpenSSH terkini.

Satu perkara perbendaharaan kata sebelum kita bermula, kerana ia menghalang kesilapan sebenar. Kunci awam bukanlah rahsia. Anda boleh menampalnya ke dalam tiket, menghantarnya melalui e-mel, atau menerbitkannya, dan tiada sesiapa boleh log masuk dengannya. Kunci peribadi ialah rahsia. Sesiapa yang menyalin fail itu, dan mengetahui frasa laluannya jika ada, adalah anda bagi pihak pelayan anda.

Cipta kunci: ed25519 ialah lalai yang tepat

Pada komputer anda sendiri, bukan pada pelayan, jalankan:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 memilih jenis kunci. Ed25519 ialah lalai moden: kuncinya pendek, pantas dan disokong oleh setiap keluaran OpenSSH sejak tahun 2014. Gunakan ssh-keygen -t rsa -b 4096 hanya apabila anda perlu berhubung dengan peranti lama yang tidak menyokong ed25519. -C "laptop" menetapkan ulasan. Ulasan tersebut tidak mempunyai fungsi kriptografi, tetapi ia adalah cara anda mengecam kunci ini dalam fail authorized_keys pelayan dua tahun dari sekarang, jadi namakan peranti tempat kunci itu disimpan.

ssh-keygen bertanya di mana untuk menyimpan kunci tersebut. Terima lalai, ~/.ssh/id_ed25519. Ia kemudian meminta frasa laluan (passphrase). Tetapkan satu; bahagian frasa laluan di bawah menjelaskan mengapa ia tidak menyusahkan anda dalam penggunaan harian. Anda akan mendapat dua fail: ~/.ssh/id_ed25519 ialah kunci peribadi, dan ~/.ssh/id_ed25519.pub ialah kunci awam. Lihat bahagian awam tersebut:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Ia terdiri daripada satu baris: jenis kunci, kandungan kunci dan ulasan anda. Baris itulah yang akan diletakkan pada pelayan anda.

Satu kunci bagi setiap peranti, bukan satu bagi setiap pelayan

Soalan yang sering ditanya oleh semua orang: adakah saya perlukan kunci baharu bagi setiap pelayan? Tidak. Cipta satu kunci bagi setiap peranti yang anda gunakan, dan letakkan kunci awam tersebut pada setiap pelayan yang perlu dicapai oleh peranti itu. Kunci tersebut mengenal pasti peranti berkenaan. Fail authorized_keys pada setiap pelayan ialah senarai peranti yang dibenarkan masuk.

Ini ialah model yang boleh diskalakan, manakala alternatif lain akan gagal dengan cara yang boleh dijangka. Satu kunci bagi setiap pelayan bermakna sebuah komputer riba dengan dua puluh pelayan membawa dua puluh kunci peribadi, dan anda akan hilang punca untuk membezakannya. Satu kunci yang dikongsi oleh semua peranti anda adalah lebih buruk: apabila komputer riba dicuri, anda tidak boleh membatalkan akses komputer riba tersebut tanpa turut menyekat akses komputer meja anda, kerana kedua-duanya memegang kunci peribadi yang sama. Oleh itu, anda perlu menggantikan kunci tersebut di mana-mana dan mengedarkannya semula ke setiap peranti serentak.

Dengan satu kunci bagi setiap peranti, kehilangan komputer riba hanya menelan kos satu baris bagi setiap pelayan: padamkan baris peranti tersebut daripada authorized_keys, dan setiap peranti lain akan terus berfungsi. Komen yang anda tetapkan dengan -C adalah perkara yang memudahkan baris tersebut dicari.

Peraturan di sebalik model ini: kunci peribadi dicipta pada satu peranti dan tamat bersama peranti tersebut. Jangan sekali-kali menyalin kunci peribadi ke mesin kedua, dan jangan sekali-kali memuat naiknya ke pelayan. Apabila peranti baharu memerlukan akses, jana kunci baharu pada peranti tersebut.

Letakkan kunci awam pada pelayan

Cara yang mudah ialah ssh-copy-id, yang disertakan bersama OpenSSH:

ssh-copy-id matt@10.0.0.10

Ia akan log masuk menggunakan kaedah yang masih berfungsi, biasanya kata laluan, menambah kunci awam anda ke ~/.ssh/authorized_keys pada pelayan, serta mencipta direktori dan fail tersebut dengan keizinan yang betul jika ia tiada. Uji dengan membuka sesi SSH baharu: pelayan sepatutnya membenarkan anda masuk tanpa meminta kata laluan akaun. Jika kunci anda mempunyai frasa laluan, mesin anda sendiri mungkin memintanya; gesaan tersebut adalah tempatan dan bukannya kata laluan pelayan.

Apabila log masuk kata laluan telah dilumpuhkan, ssh-copy-id tidak boleh masuk, jadi anda perlu menambah baris tersebut secara manual. Log masuk melalui sesi yang masih berfungsi, atau konsol web pembekal anda, dan jalankan arahan ini pada pelayan:

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

Tampal kunci awam sebenar anda di dalam tanda petikan, iaitu baris tunggal penuh daripada id_ed25519.pub. authorized_keys mengandungi satu kunci awam bagi setiap baris, dan itulah keseluruhan pangkalan data akses: menambah peranti bermaksud menambah satu baris, manakala membatalkan akses peranti bermaksud memadamkan satu baris. Pada pelayan baharu, langkah ini perlu dilakukan dalam 10 minit pertama pada VPS baharu, tepat sebelum anda mematikan log masuk kata laluan.

Kebenaran akses yang menyebabkan kegagalan log masuk kunci

Ini merupakan punca paling lazim mengapa log masuk kunci gagal, dan ia gagal secara senyap dari sisi klien. StrictModes yes dijalankan secara lalai pada Ubuntu 24.04, yang bermaksud ia enggan menggunakan fail authorized_keys yang boleh disunting oleh pengguna lain. Jika fail tersebut, direktori ~/.ssh, atau direktori utama (home directory) anda boleh ditulis oleh sesiapa selain anda, chmod 600 ~/.ssh/id_ed25519 akan mengabaikan kunci anda dan kembali meminta kata laluan, tanpa sebarang penjelasan pada klien. (OpenSSH pada Ubuntu hanya membenarkan satu kes terhad: fail yang boleh ditulis oleh kumpulan peribadi anda sendiri, yang tidak dianggotai oleh orang lain. Jangan bergantung pada perkara ini; kekalkan mod seperti di bawah.) Sebab kegagalan hanya muncul dalam log pelayan:

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

Pada imej minimal tanpa rsyslog, tiada auth.log; baris yang sama wujud dalam jurnal: sudo journalctl -u ssh | grep 'Authentication refused'.

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

Penyelesaiannya adalah dua perubahan kebenaran akses dan satu semakan pemilikan, yang dijalankan pada pelayan sebagai pengguna yang terjejas:

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

Peraturan yang perlu diingat: 700 pada direktori .ssh, 600 pada semua kandungan di dalamnya. Nombor yang sama terpakai pada komputer anda sendiri, kerana klien juga melakukan semakan. Kunci peribadi yang boleh dibaca oleh pengguna lain menyebabkan ssh menolak kunci tersebut secara terus, dan kali ini ralatnya jelas:

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

chmod 600 ~/.ssh/id_ed25519 akan membetulkannya.

~/.ssh/config: berhenti menaip pilihan

Fail ~/.ssh/config pada komputer anda memberikan setiap pelayan nama ringkas dan mengingati pilihan yang sering anda taip. Cipta fail tersebut dengan keizinan 600 dan tambah blok Host bagi setiap pelayan:

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

Kini ssh web1 menggantikan ssh -p 22 matt@10.0.0.10, dan nama ringkas yang sama berfungsi dalam scp, rsync, dan git, kerana kesemuanya membaca fail ini. HostName ialah alamat sebenar, User menjimatkan masa anda daripada menaip nama akaun, dan IdentityFile menetapkan kunci mana yang perlu ditawarkan.

IdentitiesOnly yes perlu diberikan perhatian khusus, kerana ia menyelesaikan kegagalan yang mengelirukan. Apabila ejen anda menyimpan beberapa kunci, klien akan menawarkannya satu demi satu, dan pelayan mengira setiap tawaran sebagai percubaan yang gagal. Dengan kunci yang mencukupi dimuatkan, anda akan mendapat Received disconnect: Too many authentication failures sebelum kunci yang betul sempat dicuba. IdentitiesOnly yes memastikan klien hanya menawarkan kunci yang dinamakan dalam IdentityFile, supaya kegagalan tersebut tidak berlaku.

Frasa laluan dan ssh-agent

Frasa laluan menyulitkan fail kunci peribadi pada cakera. Tanpa frasa laluan, sesiapa yang menyalin fail tersebut boleh menggunakannya serta-merta; dengan frasa laluan, fail yang dicuri tidak berguna sehingga frasa laluan tersebut diteka. Bagi kunci pada komputer riba, itulah perlindungan yang anda perlukan, kerana komputer riba sering dicuri dan sandaran komputer riba boleh bocor.

Sebab frasa laluan tidak menyusahkan dalam amalan adalah ssh-agent. Ejen menyimpan kunci anda yang telah dinyahsulit dalam memori, jadi anda hanya perlu menaip frasa laluan sekali bagi setiap sesi log masuk dan setiap sambungan seterusnya berlaku serta-merta. Kebanyakan pengedaran Linux desktop dan macOS sudah menjalankan ejen untuk anda. Muatkan kunci anda ke dalamnya dengan:

ssh-add ~/.ssh/id_ed25519

ssh-add -l menyenaraikan kunci yang sedang disimpan oleh ejen. Satu peringatan: pemajuan ejen (ssh -A) membolehkan pelayan jauh menggunakan ejen anda untuk mengesahkan sambungan seterusnya semasa anda sedang bersambung, jadi aktifkan ia hanya kepada pelayan yang anda percayai sepenuhnya, dan biarkan ia dimatikan secara lalai.

Putaran dan pembatalan: latihan komputer riba hilang

Membatalkan kunci SSH biasa hanyalah dengan memadamkan barisnya daripada authorized_keys pada setiap pelayan yang menyimpannya. Tiada pihak berkuasa sijil untuk dimaklumkan dan tiada tarikh luput untuk ditunggu. Sebaik sahaja baris tersebut dipadamkan, log masuk baharu menggunakan kunci itu akan gagal.

Jalankan latihan ini sekarang, sementara ia bukan satu kecemasan. Pilih satu pelayan, buka ~/.ssh/authorized_keys, dan cari kunci tersebut melalui komennya. Padamkan baris tersebut menggunakan editor, atau tapis keluar berdasarkan komen:

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

Kemudian, sahkan daripada peranti yang baru anda batalkan bahawa log masuk kini gagal, dan daripada peranti lain bahawa log masuk masih berfungsi. Perhatikan satu perincian: memadamkan kunci tidak menutup sesi yang sedang dibuka, kerana kunci hanya disemak semasa log masuk. Jika anda membatalkan akses peranti yang dicuri, semak juga who pada pelayan dan tamatkan sebarang sesi yang tidak anda kenali.

Putaran adalah operasi yang sama dalam urutan yang berbeza: jana kunci baharu pada peranti, pasang kunci tersebut dengan ssh-copy-id, sahkan kunci baharu boleh digunakan untuk log masuk, kemudian padamkan baris kunci lama. Lakukan ini apabila peranti bertukar tangan, apabila kunci mungkin telah terdedah, atau apabila seseorang meninggalkan pasukan. Melakukan ini secara manual merentasi dua pelayan adalah memadai; merentasi dua puluh pelayan, ia merupakan tugas untuk automasi, dan menguruskan berbilang pelayan Linux menunjukkan cara untuk menolak status authorized_keys yang sama ke seluruh kumpulan pelayan.

Perkara yang tidak boleh dilakukan

• Jangan kongsi satu private key merentasi semua peranti anda. Ini menyebabkan pembatalan satu peranti yang dicuri menjadi mustahil tanpa menggantikan kunci tersebut di mana-mana.

• Jangan komit private key ke dalam repositori git, walaupun repositori peribadi. Pengimbas automatik memantau repositori awam dan mencuba kunci yang bocor dalam masa beberapa minit selepas push, dan repositori yang ditukar kepada awam kemudiannya akan mendedahkan keseluruhan sejarahnya.

• Jangan muat naik private key komputer riba anda ke pelayan supaya pelayan tersebut boleh mencapai pelayan lain. Jana kunci berasingan pada pelayan itu sendiri, dan benarkan kunci tersebut hanya di tempat yang diperlukan.

• Jangan tampal private key ke dalam sembang, e-mel, atau tiket. Public key, iaitu fail .pub, adalah satu-satunya bahagian yang boleh dikongsi.

Setelah kunci anda membolehkan anda log masuk dengan stabil, ambil langkah seterusnya dan matikan pengesahan kata laluan, supaya percubaan meneka kata laluan secara berterusan terhadap pelayan anda tidak akan berjaya sama sekali. Konfigurasi untuk tujuan tersebut terdapat dalam Pengukuhan SSH pada VPS.

FAQ

Bagaimanakah kunci SSH berfungsi tanpa menghantar kata laluan?

Pelayan menyimpan kunci awam anda di dalam ~/.ssh/authorized_keys. Semasa log masuk, pelayan menghantar cabaran, klien anda menandatangani cabaran tersebut dengan kunci peribadi, dan pelayan mengesahkan tandatangan tersebut dengan kunci awam. Kunci peribadi tidak pernah meninggalkan peranti anda, jadi tiada apa-apa yang boleh dipintas semasa transit dan tiada apa-apa yang boleh digunakan semula untuk dicuri daripada pelayan. Pelayan yang terjejas hanya membocorkan kunci awam, yang tidak boleh digunakan untuk log masuk ke mana-mana.

Adakah saya perlu menggunakan kunci SSH yang sama untuk semua pelayan saya?

Menggunakan satu kunci merentasi banyak pelayan adalah betul, selagi kunci tersebut kekal pada satu peranti sahaja. Peraturannya ialah satu kunci bagi setiap peranti, bukan satu bagi setiap pelayan: kunci awam komputer riba anda diletakkan pada setiap pelayan yang perlu diakses oleh komputer riba tersebut, dan komputer meja anda mempunyai kuncinya sendiri. Ini memudahkan pembatalan, kerana kehilangan satu peranti bermakna membuang satu baris yang boleh dikenal pasti daripada setiap pelayan, manakala peranti lain terus berfungsi.

Apakah kebenaran yang perlu dimiliki oleh direktori .ssh dan authorized_keys?

Tetapkan 700 pada ~/.ssh dan 600 pada authorized_keys serta pada setiap kunci peribadi, yang dimiliki oleh akaun yang menggunakannya. sshd berjalan dengan StrictModes yes secara lalai, jadi fail atau direktori utama yang boleh ditulis oleh sesiapa selain anda akan menyebabkan sshd mengabaikan kunci anda secara senyap, dan satu-satunya kesan yang tertinggal ialah Authentication refused: bad ownership or modes dalam log pengesahan atau jurnal pelayan.

Bagaimanakah cara saya membuang kunci SSH daripada pelayan?

Padamkan baris kunci tersebut daripada ~/.ssh/authorized_keys dalam akaun yang telah diberikan kebenaran. Cari baris yang betul melalui komennya, iaitu label selepas data kunci. Log masuk baharu dengan kunci tersebut akan gagal serta-merta, tetapi sesi yang sudah dibuka akan kekal terbuka, jadi tamatkan sebarang sesi aktif untuk peranti tersebut jika ia telah dicuri. Ulangi langkah ini pada setiap pelayan yang kunci tersebut telah disalin.

Adakah saya memerlukan frasa laluan pada kunci SSH saya?

Untuk kunci pada komputer riba atau komputer meja, ya. Frasa laluan menyulitkan fail kunci, jadi salinan yang dicuri atau bocor tidak berguna secara sendirinya, dan ssh-agent bermakna anda hanya perlu menaipnya sekali bagi setiap sesi dan bukannya pada setiap sambungan. Kunci yang digunakan oleh automasi tanpa pengawasan pada pelayan biasanya tidak mempunyai frasa laluan, kerana tiada manusia yang hadir untuk menaipnya; lindungi kunci tersebut dengan mengehadkan perkara yang boleh dilakukan oleh akaun sasaran.