Cara Membuat SSH Keys dengan OpenSSH di macOS atau Linux

Autentikasi berbasis kunci SSH adalah metode standar industri untuk mengamankan akses server jarak jauh. Alih-alih mengirimkan kata sandi melalui jaringan, klien Anda membuktikan identitasnya dengan memecahkan tantangan kriptografi yang hanya dapat dijawab oleh pemegang kunci privat — server tidak pernah melihat kunci privat itu sendiri.

Sebuah pasangan kunci SSH terdiri dari dua file yang terhubung secara matematis: sebuah kunci privat (disimpan secara eksklusif di mesin lokal Anda, tidak pernah dibagikan) dan sebuah kunci publik (diterapkan ke setiap server yang perlu Anda akses). Ketika Anda memulai koneksi, OpenSSH menggunakan handshake tantangan-respons untuk memverifikasi bahwa kunci privat Anda sesuai dengan kunci publik di server, memberikan akses tanpa prompt kata sandi.

Mengapa Kunci SSH Jauh Lebih Unggul dari Autentikasi Kata Sandi

Kata sandi rentan terhadap serangan brute-force, credential stuffing, phishing, dan intersepsi pada jaringan yang dikonfigurasi dengan buruk. Kunci SSH menghilangkan semua vektor serangan tersebut secara bersamaan.

• Kekuatan kriptografi: Kunci RSA 4096-bit atau kunci Ed25519 secara komputasi tidak mungkin di-brute-force dengan perangkat keras saat ini.
• Tidak ada rahasia yang dikirimkan melalui jaringan: Kunci privat tidak pernah meninggalkan mesin Anda. Protokol autentikasi membuktikan kepemilikan tanpa pengungkapan.
• Siap untuk otomatisasi: Pipeline CI/CD, playbook Ansible, pekerjaan rsync, dan backup berbasis cron semuanya memerlukan autentikasi non-interaktif. Kunci SSH memungkinkan hal ini tanpa menyematkan kata sandi teks biasa dalam skrip.
• Kemampuan audit: Setiap pasangan kunci dapat diidentifikasi secara unik melalui fingerprintnya, sehingga mudah untuk mencabut satu kunci yang dikompromikan tanpa merotasi kredensial di mana-mana.
• Kompatibilitas dengan ACL authorized_keys: Anda dapat membatasi kunci publik tertentu untuk hanya menjalankan satu perintah, mengikatnya ke IP sumber, atau mencegah port forwarding — kontrol yang tidak dapat direplikasi oleh autentikasi kata sandi.

Jika Anda mengelola VPS atau dedicated server, menonaktifkan autentikasi kata sandi sepenuhnya dan menerapkan login hanya dengan kunci adalah salah satu langkah penguatan keamanan yang paling berdampak yang dapat Anda lakukan.

Memilih Algoritma Kunci yang Tepat

Dokumentasi OpenSSH asli dan sebagian besar tutorial lama menggunakan RSA sebagai default. Bidang ini telah berkembang. Berikut adalah perbandingan tepat dari setiap algoritma yang didukung ssh-keygen saat ini:

Ed25519 adalah default yang tepat di tahun 2024. Menghasilkan kunci yang lebih pendek, menandatangani lebih cepat, dan ukuran kuncinya yang tetap menghilangkan risiko secara tidak sengaja menghasilkan kunci yang terlalu kecil. RSA pada 4096 bit tetap dapat diterima untuk lingkungan yang harus berinteroperasi dengan sistem lama yang mendahului dukungan Ed25519 (OpenSSH < 6.5, dirilis 2014).

Prasyarat

• Workstation macOS atau Linux dengan OpenSSH terinstal. Kedua sistem operasi dilengkapi OpenSSH secara default. Verifikasi dengan:

ssh -V

• Akses jaringan ke server jarak jauh tempat Anda memiliki akun (root atau non-privileged).
• Keakraban dasar dengan terminal.

Pada distribusi Linux yang dilengkapi instalasi minimal (Alpine, beberapa netinstall Debian), instal alat klien dengan:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Langkah 1: Buka Terminal

macOS: Tekan Cmd + Space, ketik Terminal, dan tekan Enter. Atau, navigasikan ke Applications > Utilities > Terminal. Pengguna tingkat lanjut dapat menggunakan iTerm2 atau terminal bawaan di VS Code.

Linux: Tekan Ctrl + Alt + T pada sebagian besar lingkungan desktop, atau luncurkan emulator terminal distribusi Anda dari menu aplikasi.

Langkah 2: Buat Pasangan Kunci SSH

Membuat Kunci Ed25519 (Direkomendasikan)

ssh-keygen -t ed25519 -C "your_email@example.com"

Flag -C menambahkan komentar yang dapat dibaca manusia ke kunci publik. Gunakan alamat email Anda, nama host, atau label deskriptif seperti "deploy-key-prod" — tidak memiliki fungsi kriptografi tetapi sangat berharga saat mengaudit file authorized_keys yang mengumpulkan puluhan entri.

Membuat Kunci RSA (Kompatibilitas Lama)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Gunakan -b 4096 secara eksplisit. Default historis 2048 bit masih dapat diterima secara teknis tetapi memberikan margin yang lebih kecil terhadap kemajuan masa depan dalam algoritma faktorisasi. Jangan pernah menggunakan -b 1024 atau -b 2048 untuk kunci baru jika 4096 tersedia.

Membuat Kunci Bernama untuk Host Tertentu

Saat mengelola beberapa server atau peran, gunakan file kunci yang berbeda daripada menggunakan satu kunci di mana-mana. Kunci yang dikompromikan kemudian hanya memengaruhi sistem tempat kunci tersebut diterapkan:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Langkah 3: Pilih Lokasi Penyimpanan

Setelah menjalankan ssh-keygen, Anda akan melihat:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Tekan Enter untuk menerima default (~/.ssh/id_ed25519 untuk Ed25519, ~/.ssh/id_rsa untuk RSA), atau ketik jalur kustom. Lokasi default cocok untuk satu kunci tujuan umum. Untuk kunci khusus peran, selalu tentukan nama file deskriptif seperti yang ditunjukkan pada langkah sebelumnya.

Catatan penting tentang izin file: Direktori ~/.ssh/ harus dalam mode 700 dan file kunci privat harus dalam mode 600. OpenSSH akan menolak menggunakan kunci dengan izin yang terlalu permisif dan akan mencetak peringatan. Jika Anda pernah menyalin kunci antar mesin, segera verifikasi izin:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Langkah 4: Tetapkan Passphrase

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Passphrase mengenkripsi file kunci privat di disk menggunakan AES-256-CBC (di OpenSSH modern). Jika penyerang mendapatkan file kunci privat Anda — melalui laptop yang dicuri, backup yang dikompromikan, atau snapshot cloud yang salah dikonfigurasi — passphrase yang kuat adalah pertahanan terakhir yang mencegah mereka menggunakannya.

Kapan melewati passphrase: Akun layanan otomatis (pipeline deployment, agen backup) yang berjalan tanpa pengawasan secara sah memerlukan kunci tanpa passphrase. Dalam hal itu, batasi izin kunci di sisi server menggunakan opsi authorized_keys (lihat bagian lanjutan di bawah) dan simpan kunci privat di manajer rahasia daripada di filesystem bersama.

Setelah mengonfirmasi passphrase, OpenSSH menampilkan fingerprint kunci dan gambar randomart:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Catat fingerprint tersebut. Anda akan menggunakannya untuk memverifikasi identitas kunci saat mengaudit server.

Langkah 5: Salin Kunci Publik ke Server Jarak Jauh

Metode 1: ssh-copy-id (Tercepat)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

Flag -i secara eksplisit menentukan kunci publik mana yang akan disalin, mencegah ssh-copy-id mengunggah setiap kunci di agen Anda. Anda akan diminta kata sandi server sekali. Alat ini menangani pembuatan direktori, penambahan file, dan pengaturan izin secara otomatis.

Metode 2: Deployment Manual (Ketika ssh-copy-id Tidak Tersedia)

Ini adalah pendekatan yang tepat ketika sistem jarak jauh adalah Windows, perangkat jaringan, atau container tanpa ssh-copy-id di path.

Pertama, tampilkan kunci publik Anda:

cat ~/.ssh/id_ed25519.pub

Salin seluruh output — ini adalah satu baris yang dimulai dengan ssh-ed25519 (atau ssh-rsa). Kemudian masuk ke server dan tambahkan:

ssh user@your-server.com

Setelah terhubung:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Kesalahan umum: Menggunakan > alih-alih >> menimpa seluruh file authorized_keys, mengunci setiap kunci lainnya. Selalu gunakan >> untuk menambahkan.

Metode 3: Pipe Melalui SSH dalam Satu Perintah

Jika Anda sudah memiliki akses kata sandi dan ingin melakukan deployment tanpa masuk secara interaktif:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Langkah 6: Uji Koneksi

ssh -i ~/.ssh/id_ed25519 user@your-server.com

Koneksi yang berhasil tanpa prompt kata sandi (atau hanya dengan prompt passphrase untuk kunci lokal Anda) mengonfirmasi bahwa pengaturan sudah benar. Jika koneksi gagal, jalankan dengan output verbose untuk mendiagnosis:

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

Flag -vvv mencetak log negosiasi lengkap, menunjukkan dengan tepat kunci mana yang ditawarkan, apakah server menerimanya, dan di mana handshake gagal.

Langkah 7: Konfigurasi ~/.ssh/config untuk Profil Host Persisten

Mengetik ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 lengkap setiap kali rentan terhadap kesalahan dan lambat. File konfigurasi klien SSH menghilangkan hal ini:

nano ~/.ssh/config

Tambahkan blok host:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Sekarang hubungkan hanya dengan:

ssh prod-web

Pola ini dapat diskalakan dengan bersih ke puluhan server dan sangat penting bagi setiap engineer yang mengelola infrastruktur dalam skala besar. Direktif ServerAliveInterval 60 mengirimkan paket keepalive setiap 60 detik, mencegah koneksi idle diputus oleh firewall — frustrasi umum pada penyedia cloud.

Mengelola Beberapa Kunci dengan SSH Agent

SSH agent menyimpan kunci privat yang telah didekripsi di memori selama sesi Anda, sehingga Anda memasukkan passphrase sekali daripada pada setiap koneksi.

Mulai agent dan tambahkan kunci:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Di macOS, Anda dapat mempertahankan kunci di seluruh reboot dengan menambahkan yang berikut ke ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Direktif UseKeychain yes terintegrasi dengan macOS Keychain, menyimpan passphrase dengan aman sehingga bertahan setelah restart sistem.

Daftarkan semua kunci yang saat ini dimuat di agent:

ssh-add -l

Hapus kunci tertentu dari agent:

ssh-add -d ~/.ssh/id_ed25519

Lanjutan: Membatasi Kunci di authorized_keys

File authorized_keys mendukung opsi per-kunci yang secara dramatis mengurangi dampak dari kunci yang dikompromikan. Opsi-opsi ini ditempatkan sebelum tipe kunci pada baris yang sama:

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Opsi-opsi ini sangat berharga untuk kunci deployment pada dedicated server di mana satu kunci CI/CD yang dikompromikan tidak boleh memberikan akses shell penuh.

Penguatan Daemon SSH Setelah Deployment Kunci

Setelah autentikasi berbasis kunci berfungsi, nonaktifkan autentikasi kata sandi sepenuhnya di server. Edit /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Tetapkan direktif berikut:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Muat ulang daemon tanpa memutus sesi Anda saat ini:

sudo systemctl reload sshd

Jangan tutup sesi SSH Anda yang ada sebelum menguji koneksi baru di terminal terpisah. Kesalahan konfigurasi yang mengunci Anda dapat dipulihkan dari konsol, tetapi hal itu mengganggu dan dapat dihindari.

Untuk server yang menjalankan lingkungan cPanel VPS, perlu diketahui bahwa beberapa versi cPanel mengelola konfigurasi SSH mereka sendiri. Verifikasi bahwa perubahan sshd_config tetap ada setelah pembaruan cPanel dengan memeriksa /etc/ssh/sshd_config.d/ untuk file override.

Merotasi dan Mencabut Kunci SSH

Rotasi kunci adalah praktik kebersihan keamanan yang membatasi jendela paparan jika kunci dikompromikan secara diam-diam. Jadwal rotasi yang praktis adalah setiap 12 bulan untuk kunci pribadi dan setiap 90 hari untuk kunci akun layanan.

Untuk mencabut kunci: Hapus barisnya dari ~/.ssh/authorized_keys di setiap server tempat kunci tersebut diterapkan. Tidak ada mekanisme pencabutan terpusat di OpenSSH standar — inilah mengapa mempertahankan inventaris di mana setiap fingerprint kunci diterapkan sangat penting.

Untuk merotasi kunci:

1. Buat pasangan kunci baru.
2. Terapkan kunci publik baru ke semua server target.
3. Uji konektivitas dengan kunci baru.
4. Hapus kunci publik lama dari semua file authorized_keys.
5. Hapus atau arsipkan kunci privat lama secara lokal.

Untuk lingkungan dengan VPS hosting di beberapa wilayah, alat manajemen konfigurasi seperti Ansible adalah solusi praktis untuk menyebarkan rotasi kunci dalam skala besar.

Mentransfer Kunci Antar Mesin

Ketika Anda menyiapkan workstation baru, Anda perlu memigrasikan kunci privat yang ada daripada membuat yang baru (yang akan memerlukan penerapan ulang kunci publik di mana-mana).

Salin kunci privat dengan aman menggunakan scp atau rsync melalui SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Atau, gunakan drive USB terenkripsi atau manajer kata sandi yang mendukung penyimpanan kunci SSH (1Password, Bitwarden, dan HashiCorp Vault semuanya mendukung ini). Jangan pernah mengirim kunci privat melalui email atau menyimpannya di penyimpanan cloud yang tidak terenkripsi.

Setelah transfer, segera verifikasi izin di mesin baru:

chmod 600 ~/.ssh/id_ed25519

Memverifikasi Fingerprint Kunci Host Server

Pertama kali Anda terhubung ke server, OpenSSH menampilkan fingerprint kunci host server dan meminta Anda untuk mengonfirmasinya:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Jangan pernah mengetik yes secara membabi buta. Dapatkan fingerprint yang diharapkan melalui saluran out-of-band — panel kontrol penyedia hosting Anda, rekan yang menyediakan server, atau output konsol server. Langkah ini mencegah serangan man-in-the-middle. Untuk lingkungan shared hosting, fingerprint yang diharapkan biasanya tercantum di panel kontrol di bawah pengaturan akses SSH.

Setelah diterima, fingerprint disimpan di ~/.ssh/known_hosts. Jika fingerprint berubah secara tidak terduga pada koneksi berikutnya, OpenSSH akan menolak untuk terhubung dan menampilkan peringatan — perlakukan ini sebagai peristiwa keamanan serius yang memerlukan investigasi sebelum melanjutkan.

Matriks Keputusan dan Daftar Periksa Teknis

Gunakan daftar periksa ini sebelum menganggap pengaturan kunci SSH Anda siap produksi:

• [ ] Algoritma kunci adalah Ed25519 (atau RSA 4096 untuk kompatibilitas lama) — DSA dan ECDSA 256 tidak dapat diterima untuk deployment baru
• [ ] Izin file kunci privat adalah 600; izin direktori ~/.ssh/ adalah 700
• [ ] Passphrase yang kuat ditetapkan pada semua kunci pengguna interaktif
• [ ] Kunci akun layanan tanpa passphrase dibatasi melalui opsi authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no ditetapkan di /etc/ssh/sshd_config pada semua server
• [ ] PermitRootLogin prohibit-password atau PermitRootLogin no diterapkan
• [ ] Fingerprint kunci host server telah diverifikasi secara out-of-band
• [ ] Inventaris kunci ada yang memetakan setiap fingerprint ke server tempat kunci tersebut diterapkan
• [ ] Jadwal rotasi kunci telah ditentukan dan dijadwalkan
• [ ] Blok host ~/.ssh/config dikonfigurasi untuk menghindari penggunaan flag -i secara manual
• [ ] SSH agent digunakan untuk menghindari entri passphrase berulang selama sesi kerja
• [ ] Entri known_hosts ditinjau secara berkala untuk entri yang sudah usang atau tidak terduga

FAQ

Apa perbedaan antara kunci SSH Ed25519 dan RSA?

Ed25519 menggunakan kriptografi kurva eliptik dengan kunci tetap 256-bit yang memberikan sekitar 128 bit keamanan, menandatangani operasi lebih cepat dari RSA, dan menghasilkan string kunci yang lebih pendek. RSA pada 4096 bit memberikan keamanan yang sebanding tetapi lebih lambat dan menghasilkan materi kunci yang lebih besar. Gunakan Ed25519 untuk semua kunci baru kecuali Anda harus terhubung ke sistem yang menjalankan OpenSSH lebih lama dari versi 6.5.

Bisakah saya menggunakan pasangan kunci SSH yang sama untuk beberapa server?

Ya, secara teknis. Namun, praktik terbaik adalah menggunakan pasangan kunci yang berbeda per peran atau lingkungan (akses workstation pribadi, deployment CI/CD, pemeliharaan database). Ini membatasi dampak dari satu kunci yang dikompromikan dan membuat pencabutan mudah tanpa mengganggu sistem yang tidak terkait.

Apa yang terjadi jika saya kehilangan kunci privat saya?

Anda kehilangan kemampuan untuk mengautentikasi menggunakan pasangan kunci tersebut. Kunci publik di server menjadi tidak berguna. Anda harus mengakses server melalui metode alternatif — akses konsol, kunci sekunder, atau akses darurat penyedia hosting Anda — kemudian hapus kunci publik yang terbengkalai dari authorized_keys dan terapkan pasangan kunci baru.

Mengapa SSH masih meminta kata sandi setelah saya menyalin kunci publik saya?

Penyebab paling umum adalah: izin yang salah pada ~/.ssh/ (harus 700) atau ~/.ssh/authorized_keys (harus 600) di server; direktori home itu sendiri dapat ditulis oleh semua orang; SELinux atau AppArmor memblokir akses ke direktori .ssh; atau PubkeyAuthentication no ditetapkan di /etc/ssh/sshd_config. Jalankan ssh -vvv untuk mengidentifikasi dengan tepat metode autentikasi mana yang sedang dicoba dan ditolak.

Bagaimana cara menghapus kunci SSH dari server yang tidak lagi dapat saya akses?

Jika Anda tidak memiliki metode autentikasi lain, hubungi tim dukungan penyedia hosting Anda atau gunakan akses konsol out-of-band (tersedia untuk pelanggan VPS dan dedicated server) untuk masuk dan mengedit ~/.ssh/authorized_keys secara langsung. Inilah mengapa mempertahankan kredensial akses konsol secara terpisah dari kunci SSH adalah persyaratan operasional yang tidak dapat dinegosiasikan.