Tutorial Ubuntu 26.04 / Mengatur OpenSSH dan menguji autentikasi kunci publik

Siapkan autentikasi kunci SSH dengan memeriksa listener server, mendaftarkan hanya kunci publik klien, lalu menguji koneksi baru. Batasi login dengan kata sandi setelah login kunci dan akses administrasi terbukti bekerja, sambil mempertahankan sesi lama serta akses konsol.

Periksa layanan, soket, dan alamat server

sudo apt update
sudo apt install openssh-server
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
ip -br address

SSH (Secure Shell) menyediakan koneksi terenkripsi untuk administrasi jarak jauh. Jalankan blok ini di server dan periksa listener TCP yang benar-benar aktif, alamat tempat layanan mendengarkan, serta keadaan ssh.socket dan ssh.service. Pada instalasi yang menggunakan aktivasi SSH melalui soket systemd, layanan dapat belum aktif sebelum koneksi pertama datang. Satu unit yang tidak aktif saja belum membuktikan bahwa SSH rusak.

Latihan ini mempertahankan port SSH yang sudah digunakan. Dalam konfigurasi NAT dan host-only dari latihan pembuatan VM, server memakai 192.168.56.20 dan klien Linux 192.168.56.10. Siapkan alamat sesuai latihan IP statis dan DNS bila belum tersedia. Perintah pembuatan serta pengiriman kunci di bagian berikut dijalankan pada klien .10.

Di klien Linux, periksa command -v ssh dan command -v ssh-copy-id. Jika belum tersedia, siapkan paket dengan sudo apt update && sudo apt install openssh-client. Ganti nama pengguna contoh dengan akun biasa yang benar-benar dibuat saat instalasi. Pastikan ada jalur login awal yang diizinkan atau akses konsol untuk mendaftarkan kunci publik; jangan melonggarkan kebijakan server produksi hanya demi latihan.

Jika koneksi tidak sampai ke listener, periksa alamat tujuan, rute, dan aturan firewall yang berlaku. Izinkan hanya akses yang memang diperlukan dari jaringan latihan sesuai kebijakan setempat. Jangan menonaktifkan seluruh firewall untuk mengatasi kegagalan autentikasi. Panduan OpenSSH Ubuntu menjelaskan pemasangan, konfigurasi, dan pemeriksaan dasarnya.

Verifikasi identitas server dan buat kunci pada klien

Pada konsol server, periksa sidik jari kunci host dengan sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Bandingkan melalui jalur tepercaya dengan sidik jari yang ditampilkan saat koneksi pertama. Bandingkan jenis kunci yang sama; jika klien menampilkan jenis lain, periksa kunci host publik yang sesuai di konsol. Jangan menerima identitas yang tidak cocok tanpa menyelidikinya.

Setelah identitas server dipastikan, jalankan dua perintah berikut pada terminal klien Linux:

ssh-keygen -t ed25519 -f "$HOME/.ssh/ubuntu-lab-ed25519"
ssh-copy-id -i "$HOME/.ssh/ubuntu-lab-ed25519.pub" labuser@192.168.56.20

Ganti labuser dan alamat dengan akun serta server sebenarnya. Periksa apakah file dengan nama tersebut sudah ada; jangan menyetujui penimpaan kunci lama. Pilih nama baru bila perlu dan sesuaikan semua perintah selanjutnya. Saat pembuatan kunci, atur frasa sandi yang kuat dan simpan dengan aman.

File tanpa akhiran .pub adalah kunci privat yang tetap disimpan pada klien. File .pub adalah kunci publik; hanya file inilah yang dikirim untuk ditambahkan ke ~/.ssh/authorized_keys akun tujuan. Jangan menimpa kunci pengguna lain atau menyalin kunci privat ke server. ssh-copy-id memerlukan metode autentikasi awal yang memang diizinkan. Contoh pengiriman ini mengasumsikan klien Linux; perangkat SSH bawaan Windows mungkin tidak menyediakan ssh-copy-id.

Contoh memakai port SSH standar. Jika server telah memakai port lain, gunakan nilai aktual melalui opsi -p pada perintah koneksi dan pengiriman kunci; latihan ini tidak mengubah port server.

Uji koneksi baru dengan autentikasi kunci saja

ssh -i "$HOME/.ssh/ubuntu-lab-ed25519" -o ControlMaster=no -o ControlPath=none -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no labuser@192.168.56.20

Opsi -i memilih identitas latihan, IdentitiesOnly=yes membatasi identitas yang ditawarkan sesuai konfigurasi identitas, dan PreferredAuthentications=publickey meminta autentikasi kunci publik. PasswordAuthentication=no mencegah metode kata sandi pada percobaan klien ini. Semua ini adalah opsi klien; opsi tersebut belum mengubah kebijakan autentikasi server.

ControlMaster=no bersama ControlPath=none menonaktifkan pemakaian ulang koneksi bersama untuk pengujian. Tanpanya, konfigurasi multiplexing klien dapat memakai koneksi yang sudah diautentikasi dan memberikan kesan keliru bahwa kunci baru berhasil. Arti opsi dijelaskan dalam manual konfigurasi klien OpenSSH.

Permintaan frasa sandi kunci privat berbeda dari permintaan kata sandi akun server. Setelah berhasil masuk, jalankan whoami dan uji operasi sudo yang memang diperlukan serta diizinkan. Jika gagal, periksa akun tujuan, kunci publik terdaftar, pemilik dan izin direktori home, .ssh, serta authorized_keys, lalu lihat log server, misalnya sudo journalctl -u ssh.service --since today --no-pager. Jangan mengatasi penolakan dengan izin 777.

Periksa kebijakan autentikasi yang akan diterapkan

Kebijakan berikut hanya untuk server latihan baru yang sengaja memakai autentikasi satu kunci publik. Kebijakan global ini juga melarang login SSH langsung sebagai root. Sebelum mengedit, cadangkan /etc/ssh/sshd_config dan file yang relevan dalam /etc/ssh/sshd_config.d/, catat lokasi cadangan serta keadaan awalnya, dan pastikan pemulihan melalui konsol tersedia.

Setelah koneksi kunci dan sudo dari akun biasa teruji, periksa file terpisah seperti /etc/ssh/sshd_config.d/00-lab-auth.conf dengan sudoedit. Jika sudah ada, baca dan gabungkan perubahan tanpa menimpanya. Jangan menerapkan contoh ini begitu saja pada server yang memiliki MFA (Multi-Factor Authentication), autentikasi organisasi, atau kebutuhan pengguna lain.

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
PermitRootLogin no

PubkeyAuthentication yes mengaktifkan metode kunci publik. AuthenticationMethods publickey mensyaratkan metode itu untuk login; ini menghindari anggapan bahwa menonaktifkan PasswordAuthentication saja menutup semua metode berbasis kata sandi, termasuk keyboard-interactive. PermitRootLogin no melarang login langsung sebagai root, sehingga akses sudo akun biasa harus sudah dipastikan. Arti dan syarat setiap opsi tersedia dalam manual sshd_config untuk Ubuntu 26.04.

Untuk banyak opsi, OpenSSH memakai nilai pertama yang diperoleh. Pada konfigurasi bawaan Ubuntu, berkas sshd_config.d/*.conf disertakan pada awal file utama dan diproses menurut urutan nama. Nama 00-lab-auth.conf saja bukan jaminan nilai akhir, terutama jika urutan Include atau aturan Match telah diubah. Periksa sintaks dan konfigurasi efektif:

sudo sshd -t
sudo sshd -T | grep -E '^(pubkeyauthentication|authenticationmethods|passwordauthentication|permitrootlogin) '

Jika sshd -t melaporkan kesalahan atau keluar dengan status bukan nol, hentikan penerapan dan perbaiki sumbernya. Keberhasilan biasanya tidak menghasilkan keluaran. Pada hasil -T, periksa apakah empat nilai sesuai kebijakan di atas. Hasil ini belum membuktikan bahwa layanan berjalan telah membaca perubahan.

Jika ada aturan Match, gunakan juga sshd -T -C dengan parameter koneksi sebenarnya. Contoh parameter untuk akun dan topologi latihan adalah sudo sshd -T -C user=labuser,addr=192.168.56.10,laddr=192.168.56.20,lport=22; ganti akun, alamat, dan port sebelum menjalankannya. Sertakan nama host klien yang sesuai jika kondisi Match Host digunakan. Manual sshd menjelaskan parameter pemeriksaan tersebut.

Terapkan, uji setelah reboot, dan siapkan pemulihan

Setelah sintaks lolos dan layanan SSH benar-benar berjalan, muat ulang kebijakan dengan sudo systemctl reload ssh.service. Jika layanan tidak aktif, jangan menganggap reload berhasil; periksa aktivasi soket serta listener dan gunakan konsol untuk menelusurinya. Perubahan Port atau ListenAddress pada instalasi dengan aktivasi soket memerlukan peninjauan terpisah terhadap konfigurasi generator soket dan daemon-reload. Latihan autentikasi ini mempertahankan port yang ada.

Sebelum menutup sesi lama, ulangi koneksi kunci baru dengan pembagian koneksi tetap dinonaktifkan, periksa sudo, dan pastikan metode yang dilarang ditolak. Untuk pengujian penolakan pada akun latihan yang diizinkan, pilih metode password saja dan nonaktifkan PubkeyAuthentication pada klien; gunakan juga ControlPath=none. Hasil yang diharapkan adalah autentikasi ditolak. Jangan menguji dengan menebak kata sandi berulang kali atau mengubah aturan layanan agar percobaan berhasil.

Setelah reboot terencana, uji koneksi baru lagi. Jika gagal, gunakan konsol untuk mengembalikan hanya file yang diubah ke keadaan cadangan. Bila file dibuat khusus untuk latihan ini, batalkan hanya perubahan tersebut setelah memastikan tidak ada pengaturan lain yang perlu dipertahankan. Ulangi pemeriksaan sintaks, muat ulang layanan bila aktif, lalu uji akses yang semula berfungsi. Peringatan perubahan kunci host harus ditelusuri penyebabnya; jangan menghapus catatan kepercayaan secara membabi buta.