Memberikan Akses SSH ke Mesin Remote dengan Aman

Memberikan akses SSH ke mesin remote adalah kebutuhan yang sangat umum, terutama saat bekerja dalam tim, menangani server produksi, atau berkolaborasi dengan engineer lain di lokasi yang berbeda. Meski terdengar sederhana, praktik yang salah — seperti berbagi password antar anggota tim lewat chat atau dokumen bersama — bisa menimbulkan risiko keamanan yang serius dan sulit dilacak. Artikel ini membahas cara memberikan akses SSH ke mesin remote dengan benar menggunakan SSH key authentication, lengkap dengan langkah konfigurasi dan best practice yang umum dipakai di dunia profesional.

Apa Itu SSH dan Kenapa Harus Menggunakan SSH Key?

SSH (Secure Shell) adalah protokol jaringan terenkripsi yang memungkinkan kamu mengakses dan mengontrol mesin remote melalui terminal secara aman — seluruh komunikasi antara client dan server dienkripsi, sehingga tidak bisa disadap dalam bentuk plain text. Saat ingin memberikan akses ke orang lain, berbagi password bukan solusi yang baik karena tiga alasan: password bisa bocor atau dibagikan ulang tanpa sepengetahuanmu, sulit melacak siapa sebenarnya yang mengakses server kalau semua orang memakai kredensial yang sama, dan sulit mencabut akses satu orang tanpa mengganti password untuk semua orang lain yang juga memakainya.

Solusi yang direkomendasikan adalah SSH key authentication, di mana setiap user memiliki identitas unik berupa pasangan private key dan public key. Dengan pendekatan ini, mencabut akses satu orang cukup dengan menghapus satu baris entry, tanpa memengaruhi akses siapa pun yang lain.

Konsep Dasar SSH Key

SSH key authentication bekerja berdasarkan kriptografi asimetris, yang terdiri dari dua bagian:

• Private key — disimpan di komputer user, tidak boleh dibagikan ke siapa pun
• Public key — disimpan di server, aman untuk dibagikan dan didaftarkan

sequenceDiagram
    participant User as User (Client)
    participant Server as Mesin Remote

    User->>Server: Permintaan koneksi SSH
    Server->>User: Challenge terenkripsi (memakai public key)
    User->>User: Decrypt dengan private key
    User->>Server: Kirim hasil decrypt
    Server->>Server: Verifikasi hasil
    Server-->>User: Akses diberikan jika cocok

Saat user mencoba login, server tidak meminta password — server mengirimkan sebuah challenge terenkripsi memakai public key yang sudah terdaftar. Hanya pemilik private key yang sesuai yang bisa mendekripsi challenge tersebut dan membuktikan identitasnya. Karena private key tidak pernah dikirim melalui jaringan, proses ini jauh lebih aman dibanding autentikasi berbasis password yang rentan terhadap sniffing atau brute-force.

Public key dan private key selalu dibuat sebagai sepasang, dan tidak bisa dipakai secara terpisah dengan key dari pasangan yang berbeda. Server hanya menyimpan public key — kalaupun server tersebut diretas, public key yang bocor tidak bisa dipakai untuk login ke mana pun, karena tanpa private key yang berpasangan, challenge tidak akan pernah berhasil didekripsi.

Ada beberapa algoritma yang umum dipakai untuk membuat SSH key, dan masing-masing punya karakteristik berbeda:

Artikel ini memakai RSA sebagai contoh karena dukungannya paling luas di berbagai sistem, termasuk sistem lama yang mungkin belum mendukung Ed25519. Untuk sistem yang lebih modern, ssh-keygen -t ed25519 bisa jadi pilihan yang lebih cepat dengan tingkat keamanan yang setara atau lebih baik.

Langkah-Langkah Memberikan Akses SSH

Minta Public Key dari User

User yang ingin diberi akses harus membuat SSH key di mesinnya sendiri terlebih dahulu:

ssh-keygen -t rsa

Perintah ini akan menghasilkan dua file:

• ~/.ssh/id_rsa — private key, tetap di mesin user
• ~/.ssh/id_rsa.pub — public key, akan dibagikan ke server

Public key dapat ditampilkan dengan:

cat ~/.ssh/id_rsa.pub

Mintalah isi public key ini dari user — bukan filenya, cukup teksnya, misalnya dikirim lewat chat internal atau ticketing system. Isi public key berupa satu baris string yang dimulai dengan ssh-rsa (atau ssh-ed25519 kalau memakai algoritma Ed25519), diikuti karakter base64, dan biasanya diakhiri komentar seperti email user.

Login ke Server Remote

Sebagai administrator, masuk ke server menggunakan akun yang sudah punya akses:

ssh user@remote-ip

Ganti user dan remote-ip sesuai dengan konfigurasi server yang sebenarnya. Pada tahap ini kamu sendiri tetap login memakai cara yang sudah ada — baik itu password atau SSH key milikmu sendiri — karena tujuannya adalah menambahkan akses untuk user baru, bukan mengubah cara loginmu sendiri.

Tambahkan Public Key ke Server

Setelah berhasil masuk ke server, buka file authorized_keys di direktori .ssh milik akun yang akan diberi akses:

nano ~/.ssh/authorized_keys

Jika direktori .ssh belum ada (misalnya untuk user yang baru dibuat), buat terlebih dahulu:

mkdir -p ~/.ssh

Paste public key user ke baris baru di file tersebut — setiap baris di authorized_keys merepresentasikan satu key yang diizinkan, sehingga kamu bisa menambahkan beberapa public key sekaligus untuk beberapa user yang berbeda dalam satu file yang sama. Sebagai alternatif yang lebih cepat tanpa membuka editor, gunakan:

echo "PASTE_PUBLIC_KEY_DISINI" >> ~/.ssh/authorized_keys

Operator >> menambahkan baris baru di akhir file tanpa menghapus isi yang sudah ada sebelumnya — penting untuk diperhatikan, karena memakai > (satu tanda) alih-alih >> akan menimpa seluruh isi file dan menghapus akses user lain yang sudah terdaftar sebelumnya.

Pastikan Permission File Benar

Permission yang salah adalah penyebab paling umum SSH gagal login meski public key sudah benar terdaftar. SSH memang sengaja menolak koneksi kalau permission direktori atau file terlalu terbuka, sebagai mekanisme perlindungan terhadap user lain di mesin yang sama yang berpotensi mengubah isi authorized_keys. Gunakan permission berikut:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

chmod 700 membuat direktori .ssh hanya bisa diakses (dibaca, ditulis, dieksekusi) oleh pemiliknya sendiri. chmod 600 membuat file authorized_keys hanya bisa dibaca dan ditulis oleh pemiliknya, tanpa akses apa pun untuk grup atau user lain. Tanpa permission yang tepat ini, SSH daemon (sshd) akan menolak permintaan login meski key yang dipakai sebenarnya valid.

Uji Akses SSH

Setelah seluruh langkah di atas selesai, user dapat mencoba login:

ssh user@remote-ip

Jika konfigurasi benar, user akan bisa login tanpa memasukkan password — SSH client di mesin user akan otomatis mencoba private key yang ada di ~/.ssh/, dan begitu menemukan pasangan yang cocok dengan public key di server, autentikasi berhasil tanpa interaksi manual lebih lanjut.

Kalau login masih meminta password setelah public key ditambahkan, periksa kembali permission ~/.ssh dan authorized_keys di server, serta pastikan konfigurasi sshd_config di server mengizinkan PubkeyAuthentication yes. Log error biasanya bisa dilihat lebih detail dengan menjalankan ssh -v user@remote-ip di sisi client untuk melihat tahap mana yang gagal.

Kenapa Cara Ini Lebih Aman?

Dibandingkan berbagi password, SSH key authentication memberikan beberapa keuntungan konkret:

Setiap user memiliki identitas unik karena setiap orang punya private key sendiri yang tidak dibagikan ke siapa pun, sehingga aktivitas di server bisa lebih mudah dikaitkan dengan individu tertentu kalau dikombinasikan dengan logging yang baik. Akses juga bisa dicabut dengan cepat hanya dengan menghapus satu baris public key dari authorized_keys, tanpa memengaruhi user lain. SSH key juga jauh lebih tahan terhadap brute-force attack dibanding password, karena ruang kemungkinan kombinasi key jauh lebih besar dan praktis tidak bisa ditebak dengan cara coba-coba. Pendekatan ini adalah standar industri untuk mengelola akses server, baik untuk tim kecil maupun infrastruktur production berskala besar.

Membatasi Akses per Key

Selain sekadar mengizinkan atau menolak login, file authorized_keys juga mendukung opsi tambahan yang membatasi apa yang bisa dilakukan oleh key tertentu. Ini berguna kalau kamu ingin memberi akses terbatas — misalnya hanya untuk menjalankan satu perintah spesifik, tanpa membuka akses shell penuh ke server.

command="rsync --server -vlogDtprz --partial . /var/backup/",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAA...rest_of_public_key... user@client

Opsi command="..." di awal baris memaksa key tersebut hanya bisa menjalankan perintah yang ditentukan, terlepas dari perintah apa yang sebenarnya dikirim user saat login — cocok untuk skenario seperti backup otomatis lewat rsync atau scp, di mana user (atau service account) tidak pernah perlu mendapat akses shell interaktif. Opsi no-port-forwarding dan no-X11-forwarding menutup fitur tunneling yang tidak relevan untuk skenario tersebut, sementara no-pty mencegah key ini membuka sesi terminal interaktif sama sekali.

Pendekatan ini sering dipakai untuk service account — akun yang dipakai oleh sistem otomatis (CI/CD pipeline, cron job, backup script) bukan oleh manusia. Dengan membatasi key service account hanya bisa menjalankan satu perintah tertentu, dampak kalau key tersebut bocor jadi jauh lebih kecil dibanding key yang punya akses shell penuh — penyerang yang mendapatkan key tersebut tetap terkunci pada satu perintah spesifik yang sudah didefinisikan, bukan mendapat akses bebas ke seluruh sistem file dan proses di server.

Tips dan Best Practice

• Jangan pernah membagikan private key ke siapa pun, termasuk rekan tim yang dipercaya
• Gunakan passphrase pada private key sebagai lapisan keamanan tambahan kalau file private key sampai bocor
• Hapus public key dari authorized_keys segera setelah akses tidak diperlukan lagi — misalnya saat seseorang keluar dari tim atau project selesai
• Batasi akses menggunakan user terpisah untuk setiap orang, jangan selalu memakai akun root untuk operasional harian

Passphrase pada private key bekerja sebagai lapisan kedua: walaupun file private key berhasil dicuri, penyerang masih harus memecahkan passphrase tersebut sebelum key itu bisa dipakai. Sementara menghindari penggunaan root untuk operasional sehari-hari membantu membatasi dampak kalau salah satu akun user disusupi — akun biasa dengan privilege terbatas jauh lebih aman dibanding akun yang punya akses penuh ke seluruh sistem.

Sebagai checklist tambahan sebelum menganggap setup selesai, pastikan beberapa hal berikut juga sudah diperhatikan:

□ Password authentication dinonaktifkan di sshd_config (PasswordAuthentication no)
□ Root login lewat SSH dinonaktifkan (PermitRootLogin no)
□ Setiap user/service account punya key masing-masing, tidak berbagi satu key
□ authorized_keys di-review secara berkala, key yang tidak terpakai dihapus
□ Service account memakai opsi command= untuk membatasi apa yang bisa dijalankan

Menonaktifkan PasswordAuthentication di sshd_config sebenarnya adalah langkah lanjutan yang melengkapi setup SSH key — setelah semua user beralih ke SSH key, opsi login dengan password bisa benar-benar dimatikan di level server, sehingga brute-force terhadap password tidak lagi jadi vektor serangan yang relevan sama sekali.

Ringkasan

• SSH key authentication menggantikan password dengan pasangan private key (di client) dan public key (di server) yang lebih aman dan lebih mudah diaudit.
• Public key ditambahkan ke file ~/.ssh/authorized_keys di server — setiap baris merepresentasikan satu key yang diizinkan.
• Permission yang benar wajib — chmod 700 ~/.ssh dan chmod 600 ~/.ssh/authorized_keys, atau SSH akan menolak koneksi meski key valid.
• Mencabut akses satu user cukup dengan menghapus satu baris di authorized_keys, tanpa memengaruhi user lain.
• Jangan pernah membagikan private key; gunakan passphrase sebagai lapisan keamanan tambahan.
• Hindari penggunaan akun root untuk operasional harian — gunakan user terpisah dengan privilege terbatas.
• Pendekatan ini adalah standar industri dan berlaku untuk semua environment — development, staging, maupun production.