cara urus kunci SSH dengan betul

Cara kunci SSH berfungsi

Kunci SSH ialah 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 dihantar melalui rangkaian, dan pelayan yang diceroboh tidak mempunyai maklumat 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, kebenaran fail yang diperlukan oleh sshd, fail ~/.ssh/config supaya anda tidak perlu menaip pilihan (options), dan tahu 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 versi terkini.

Satu nota istilah sebelum kita bermula, kerana ia dapat mengelakkan 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 adalah rahsia. Sesiapa yang menyalin fail tersebut, dan mengetahui kata laluannya jika ada, akan dianggap sebagai anda oleh pelayan anda.

Cipta kunci: ed25519 adalah pilihan lalai yang tepat

Pada komputer anda sendiri, bukan pada pelayan, jalankan:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 memilih jenis kunci. Ed25519 adalah lalai moden: kunci ini pendek, pantas, dan disokong oleh setiap versi OpenSSH sejak 2014. Gunakan ssh-keygen -t rsa -b 4096 hanya jika anda perlu berhubung dengan peranti lama yang tidak menyokong ed25519. -C "laptop" menetapkan komen. Komen tidak mempunyai fungsi kriptografi, tetapi ia digunakan untuk mengecam kunci ini dalam fail authorized_keys pelayan anda dua tahun akan datang, jadi namakan peranti tempat kunci itu disimpan.

ssh-keygen meminta lokasi simpanan kunci. Terima nilai lalai, ~/.ssh/id_ed25519. Ia kemudian meminta kata laluan (passphrase). Tetapkan satu; bahagian kata laluan di bawah menjelaskan mengapa ia tidak membebankan anda setiap hari. Anda akan mendapat dua fail: ~/.ssh/id_ed25519 adalah kunci peribadi, dan ~/.ssh/id_ed25519.pub adalah kunci awam. Lihat bahagian awam:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Ia adalah satu baris: jenis kunci, kandungan kunci, dan komen anda. Baris itulah yang akan disimpan pada pelayan anda.

Satu kunci bagi setiap peranti, bukan satu bagi setiap pelayan

Soalan utama yang sering ditanya: adakah saya memerlukan kunci baharu untuk setiap pelayan? Tidak. Cipta satu kunci bagi setiap peranti yang anda gunakan, dan masukkan kunci awam tersebut ke dalam setiap pelayan yang perlu dicapai oleh peranti itu. Kunci tersebut mengenal pasti peranti tersebut. Fail authorized_keys pada setiap pelayan adalah senarai peranti yang dibenarkan masuk.

Ini adalah model yang boleh diskalakan, manakala alternatif lain akan gagal dengan cara yang boleh dijangka. Satu kunci bagi setiap pelayan bermaksud sebuah komputer riba dengan dua puluh pelayan akan menyimpan dua puluh kunci peribadi, dan anda akan keliru kunci yang mana satu. Menggunakan satu kunci yang dikongsi oleh semua peranti adalah lebih buruk: apabila komputer riba dicuri, anda tidak boleh membatalkan akses komputer riba tersebut tanpa menyekat akses desktop anda juga, kerana kedua-duanya memegang kunci peribadi yang sama, jadi anda mesti menggantikan kunci tersebut di semua tempat dan mengedarkannya semula ke setiap peranti secara serentak.

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

Peraturan di sebalik model ini: kunci peribadi dicipta pada peranti dan tamat bersama peranti tersebut. Jangan sesekali menyalin kunci peribadi ke mesin kedua, dan jangan sesekali memuat naik kunci 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 dalam ~/.ssh/authorized_keys pada pelayan, dan mencipta direktori serta fail dengan keizinan yang betul jika ia belum wujud. Uji dengan membuka sesi SSH baharu: pelayan sepatutnya membenarkan anda masuk tanpa meminta kata laluan akaun. Jika kunci anda mempunyai passphrase, mesin anda mungkin meminta passphrase tersebut; permintaan itu adalah bersifat lokal dan bukan kata laluan pelayan.

Apabila log masuk kata laluan telah dinyahaktifkan, ssh-copy-id tidak dapat 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 lengkap daripada id_ed25519.pub. authorized_keys menggunakan satu kunci awam bagi setiap baris, dan itulah keseluruhan pangkalan data akses: menambah peranti bermaksud menambah baris, manakala membatalkan akses peranti bermaksud memadam satu baris. Pada pelayan baharu, langkah ini perlu dilakukan dalam 10 minit pertama pada VPS baharu, sejurus sebelum anda menutup log masuk kata laluan.

Kebenaran (permissions) yang merosakkan log masuk kunci

Ini adalah cara paling biasa log masuk kunci gagal, dan ia gagal secara senyap dari bahagian klien. sshd berjalan dengan StrictModes yes secara lalai pada Ubuntu 24.04, yang bermaksud ia enggan menggunakan fail authorized_keys yang boleh diedit oleh pengguna lain. Jika fail, direktori ~/.ssh, atau direktori home anda boleh ditulis oleh sesiapa sahaja selain anda, sshd akan mengabaikan kunci anda dan beralih kepada meminta kata laluan, tanpa sebarang penjelasan pada klien. (OpenSSH Ubuntu hanya bertoleransi dalam satu kes khusus: fail yang boleh ditulis oleh kumpulan peribadi anda sendiri, di mana tiada orang lain berada di dalamnya. Jangan bergantung pada perkara ini; kekalkan mod di bawah.) Sebab kegagalan ini hanya muncul dalam log pelayan:

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

Pada imej minimal tanpa rsyslog, tiada auth.log; baris yang sama terdapat dalam journal: 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 dan satu semakan pemilikan, dijalankan pada pelayan sebagai pengguna yang terjejas:

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

Peraturan untuk diingat: 700 pada direktori .ssh, 600 pada semua fail 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 sepenuhnya, dan kali ini ralat akan dipaparkan dengan jelas:

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

chmod 600 ~/.ssh/id_ed25519 menyelesaikannya.

~/.ssh/config: berhenti menaip pilihan

Fail ~/.ssh/config pada komputer anda memberikan nama ringkas kepada setiap pelayan dan menyimpan pilihan yang sering anda taip. Cipta fail ini dengan keizinan 600 dan tambahkan 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 semuanya membaca fail ini. HostName adalah alamat sebenar, User menjimatkan masa anda daripada menaip nama akaun, dan IdentityFile menetapkan kunci mana yang perlu digunakan.

IdentitiesOnly yes perlu dijelaskan kerana ia membaiki kegagalan yang mengelirukan. Apabila agent anda memegang beberapa kunci, klien akan menawarkan kunci tersebut satu demi satu, dan pelayan mengira setiap tawaran sebagai percubaan yang gagal. Jika terlalu banyak kunci dimuatkan, anda akan mendapat Received disconnect: Too many authentication failures sebelum kunci yang betul dicuba. IdentitiesOnly yes memastikan klien hanya menawarkan kunci yang dinamakan dalam IdentityFile, supaya kegagalan tersebut tidak berlaku.

Passphrase dan ssh-agent

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

Sebab mengapa passphrase tidak membebankan dalam praktis adalah ssh-agent. Agent menyimpan kunci yang telah dinyahsulit dalam memori, jadi anda hanya perlu menaip passphrase sekali bagi setiap sesi log masuk dan setiap sambungan seterusnya adalah pantas. Kebanyakan edisi Linux desktop dan macOS sudah menjalankan agent untuk anda. Muat kunci anda ke dalamnya dengan:

ssh-add ~/.ssh/id_ed25519

ssh-add -l menyenaraikan kunci yang sedang dipegang oleh agent. Satu amaran: pemanjangan agent (ssh -A) membolehkan pelayan jauh menggunakan agent anda untuk pengesahan seterusnya semasa anda disambungkan, jadi hanya aktifkan ia pada pelayan yang anda percayai sepenuhnya, dan biarkan ia tidak aktif secara lalai.

Putaran dan pembatalan: latihan komputer riba hilang

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

Jalankan latihan ini sekarang, sementara ia bukan kecemasan. Pilih satu pelayan, buka ~/.ssh/authorized_keys, dan cari kunci tersebut melalui komennya. Padam baris tersebut menggunakan editor, atau tapis baris tersebut melalui 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 sahaja dibatalkan bahawa log masuk kini gagal, dan daripada peranti lain bahawa log masuk masih berfungsi. Perhatikan satu butiran: membuang kunci tidak menutup sesi yang sedang dibuka, kerana kunci hanya disemak semasa log masuk. Jika anda membatalkan peranti yang dicuri, semak juga who pada pelayan dan tamatkan mana-mana sesi yang anda tidak kenali.

Putaran adalah operasi yang sama tetapi dalam urutan berbeza: jana kunci baharu pada peranti, pasang ia dengan ssh-copy-id, sahkan kunci baharu boleh log masuk, kemudian padam baris lama. Lakukan apabila peranti bertukar tangan, apabila kunci mungkin telah terdedah, atau apabila seseorang meninggalkan pasukan. Melakukan ini secara manual pada dua pelayan adalah memadai; untuk dua puluh pelayan, ia memerlukan automasi, dan mengurus pelayan Linux berbilang menunjukkan cara untuk menghantar keadaan authorized_keys yang sama kepada seluruh armada.

Perkara yang tidak boleh dilakukan

• Jangan gunakan satu kunci peribadi untuk semua peranti anda. Ini menyebabkan proses membatalkan akses peranti yang dicuri menjadi mustahkil tanpa perlu menggantikan kunci di semua tempat.

• Jangan simpan kunci peribadi di dalam repositori git, walaupun repositori itu bersifat peribadi. Pengimbas automatik memantau repositori awam dan akan mencuba kunci yang bocor dalam masa beberapa minit selepas proses push, manakala repositori yang ditukar kepada awam kemudiannya akan membocorkan keseluruhan sejarahnya.

• Jangan muat naik kunci peribadi komputer riba anda ke pelayan supaya pelayan tersebut boleh menghubungi pelayan lain. Jana kunci berasingan pada pelayan itu sendiri, dan berikan kebenaran kepada kunci tersebut hanya di tempat yang diperlukan.

• Jangan tampal kunci peribadi ke dalam sembang, e-mel, atau tiket sokongan. Kunci awam, iaitu fail .pub, adalah satu-satunya bahagian yang boleh dikongsi.

Setelah kunci anda membolehkan log masuk dengan stabil, ambil langkah seterusnya dengan menutup pengesahan kata laluan. Ini bagi memastikan cubaan tekaan kata laluan terhadap pelayan anda tidak akan berjaya. Konfigurasi untuk tujuan tersebut terdapat dalam Pengukuhan SSH pada VPS.

FAQ

Bagaimanakah kunci SSH berfungsi tanpa menghantar kata laluan?

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

Patutkah saya menggunakan kunci SSH yang sama untuk semua pelayan saya?

Menggunakan satu kunci untuk banyak pelayan adalah betul, asalkan 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 diperlukan oleh komputer riba tersebut, dan komputer desktop anda mempunyai kunci sendiri. Ini memudahkan proses pembatalan, kerana kehilangan peranti hanya memerlukan pemadaman satu baris pengenalan daripada setiap pelayan, manakala peranti lain tetap berfungsi.

Apakah keizinan (permissions) yang harus ada pada 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 jika fail atau direktori home boleh ditulis oleh sesiapa sahaja selain anda, ia akan mengabaikan kunci anda secara senyap, dan satu-satunya kesan adalah Authentication refused: bad ownership or modes dalam log auth atau jurnal pelayan.

Bagaimanakah cara untuk membuang kunci SSH daripada pelayan?

Padam baris kunci tersebut daripada ~/.ssh/authorized_keys dalam akaun yang telah diberi 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 sedang dibuka akan kekal terbuka, jadi tamatkan sebarang sesi aktif untuk peranti tersebut jika ia telah dicuri. Ulangi langkah ini pada setiap pelayan yang telah disalin dengan kunci tersebut.

Adakah saya perlu menggunakan passphrase pada kunci SSH saya?

Untuk kunci pada komputer riba atau desktop, ya. Passphrase menyulitkan fail kunci, jadi salinan yang dicuri atau bocor tidak berguna secara bersendirian, dan ssh-agent bermaksud anda hanya perlu menaipnya sekali bagi setiap sesi berbanding pada setiap sambungan. Kunci yang digunakan oleh automasi tanpa pemantauan pada pelayan biasanya tidak mempunyai passphrase, kerana tiada manusia yang hadir untuk menaipnya; lindungi kunci tersebut dengan mengehadkan keupayaan akaun sasaran.