Akses SSH: Panduan Teknis Lengkap untuk Manajemen Server Jarak Jauh yang Aman

SSH (Secure Shell) adalah protokol jaringan kriptografi yang membangun terowongan terenkripsi antara dua host yang terhubung ke jaringan, memungkinkan eksekusi perintah yang terautentikasi, transfer file, dan penerusan port melalui jaringan yang tidak tepercaya. Protokol ini beroperasi pada port TCP 22 secara default dan menggantikan pendahulunya yang menggunakan teks biasa — Telnet, rsh, dan FTP — dengan protokol yang menyediakan kerahasiaan, integritas, dan autentikasi mutual dalam satu handshake.

Bagi administrator mana pun yang mengelola VPS atau server dedicated, SSH bukan infrastruktur opsional — ini adalah bidang kendali utama. Setiap keputusan konfigurasi yang Anda buat seputar SSH secara langsung memengaruhi permukaan serangan server Anda, keandalan operasional, dan postur kepatuhan.

Cara Kerja SSH: Arsitektur Protokol

Memahami SSH di tingkat protokol adalah yang membedakan administrator yang mengonfigurasinya dengan benar dari mereka yang meninggalkan celah yang dapat dieksploitasi.

Model Tiga Lapisan

SSH didefinisikan oleh RFC 4251–4254 dan beroperasi di tiga sublayer berbeda yang ditumpuk di atas TCP:

• SSH Transport Layer Protocol — menangani autentikasi server, pertukaran kunci, negosiasi enkripsi, dan pengaturan MAC (message authentication code). Di sinilah handshake kriptografi terjadi.
• SSH User Authentication Protocol — berjalan di atas lapisan transport dan menangani autentikasi klien-ke-server menggunakan metode seperti publickey, password, keyboard-interactive, atau gssapi-with-mic.
• SSH Connection Protocol — melakukan multipleks terowongan terenkripsi ke dalam saluran logis, masing-masing membawa sesi shell, subsistem SFTP, port yang diteruskan, atau koneksi agen.

Detail Handshake

Saat Anda menjalankan ssh user@host, urutan berikut dieksekusi sebelum Anda melihat prompt:

1. Koneksi TCP dibuat ke server pada port yang dikonfigurasi.
2. Pertukaran versi — klien dan server bertukar string versi protokol (SSH-2.0-OpenSSH_9.x).
3. Negosiasi algoritma (SSH_MSG_KEXINIT) — kedua pihak mengiklankan algoritma pertukaran kunci yang didukung, jenis kunci host, cipher, MAC, dan metode kompresi. Opsi yang didukung bersama pertama dalam setiap daftar yang menang.
4. Pertukaran kunci (KEX) — biasanya Diffie-Hellman atau Elliptic Curve Diffie-Hellman (ECDH). Kedua pihak menurunkan rahasia bersama tanpa mengirimkannya. Ini menghasilkan kunci sesi.
5. Verifikasi kunci host server — server menandatangani nilai dengan kunci host privatnya. Klien memeriksa tanda tangan ini terhadap file ~/.ssh/known_hosts-nya. Ketidakcocokan memicu peringatan dan memblokir koneksi secara default.
6. Enkripsi diaktifkan — semua lalu lintas berikutnya dienkripsi dan dilindungi integritasnya menggunakan cipher yang dinegosiasikan (misalnya, chacha20-poly1305) dan MAC.
7. Autentikasi pengguna — klien mencoba autentikasi menggunakan metode yang dinegosiasikan. Dengan autentikasi publickey, klien menandatangani tantangan dengan kunci privatnya; server memverifikasi menggunakan kunci publik yang tersimpan.
8. Saluran terbuka — shell, subsistem SFTP, atau saluran exec dibuka dan sesi dimulai.

Seluruh proses ini biasanya selesai dalam waktu kurang dari 100 milidetik di jaringan lokal.

Kriptografi Simetris vs. Asimetris dalam SSH

Kesalahpahaman umum adalah bahwa SSH "menggunakan enkripsi kunci publik" untuk semua lalu lintas. Itu tidak benar. Perannya berbeda:

SSH vs. Protokol Akses Jarak Jauh Lama

Membuat Pasangan Kunci SSH

Pasangan kunci SSH adalah fondasi akses server yang aman dan skalabel. Autentikasi kata sandi rentan terhadap serangan brute-force dan credential stuffing; autentikasi berbasis kunci tidak.

Memilih Algoritma Kunci yang Tepat

Ed25519 adalah praktik terbaik saat ini. Ini menggunakan kriptografi kurva eliptik Curve25519, menghasilkan kunci 256-bit yang ringkas, lebih cepat dari RSA pada tingkat keamanan yang setara, dan didukung oleh OpenSSH 6.5+ (dirilis 2014).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

Gunakan RSA hanya jika Anda memerlukan kompatibilitas dengan sistem lama yang tidak mendukung Ed25519:

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

Jangan gunakan DSA (terbatas pada 1024 bit, sudah rusak) atau ECDSA dengan kurva NIST (kekhawatiran tentang asal parameter kurva NIST). Ed25519 adalah pilihan yang jelas untuk penerapan baru.

Panduan Pembuatan Kunci

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Anda akan diminta untuk:

• Lokasi file — defaultnya adalah ~/.ssh/id_ed25519. Terima default atau tentukan jalur kustom untuk lingkungan multi-kunci.
• Passphrase — selalu tetapkan satu. Passphrase mengenkripsi kunci privat saat tidak aktif menggunakan AES-256-CBC (atau bcrypt dengan OpenSSH yang lebih baru). Jika file kunci privat Anda dicuri, passphrase adalah pertahanan terakhir.

Ini menghasilkan dua file:

~/.ssh/id_ed25519 — kunci privat. Jangan pernah bagikan ini. Izin harus 600.
~/.ssh/id_ed25519.pub — kunci publik. Inilah yang Anda distribusikan ke server.

Mengelola Beberapa Kunci dengan ~/.ssh/config
Saat mengelola beberapa server atau akun, gunakan file konfigurasi SSH untuk menghindari penentuan flag pada setiap koneksi:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
Dengan ini, ssh prod-web secara otomatis diperluas ke parameter koneksi lengkap.
Menerapkan Kunci Publik Anda ke Server
Metode 1: ssh-copy-id (Direkomendasikan untuk Pengaturan Awal)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Ini menambahkan kunci publik ke ~/.ssh/authorized_keys pada host jarak jauh dan mengatur izin yang benar secara otomatis.
Metode 2: Penerapan Manual (Saat ssh-copy-id Tidak Tersedia)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Metode 3: Konsol atau API Penyedia Cloud
Sebagian besar penyedia cloud dan panel kontrol hosting memungkinkan Anda menyuntikkan kunci publik selama provisi instans. Ini adalah pendekatan yang benar untuk infrastruktur otomatis — kunci sudah ada sebelum instans boot, menghilangkan masalah ayam-dan-telur dari kebutuhan SSH untuk menerapkan kunci SSH.
Format File authorized_keys
Setiap baris dalam ~/.ssh/authorized_keys adalah satu kunci publik, secara opsional diawali dengan opsi:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
Opsi restrict menonaktifkan penerusan port, penerusan agen, dan alokasi PTY untuk kunci tersebut — berguna untuk kunci penerapan atau akun otomasi pencadangan yang seharusnya tidak memiliki akses shell interaktif.
Penguatan Server SSH: /etc/ssh/sshd_config
Instalasi OpenSSH default berfungsi tetapi tidak diperkuat. Konfigurasi berikut mewakili baseline tingkat produksi. Terapkan perubahan ke /etc/ssh/sshd_config, lalu validasi dan muat ulang:
sshd -t && systemctl reload sshd
Selalu jalankan sshd -t sebelum memuat ulang — kesalahan sintaks dalam sshd_config tidak akan merusak daemon yang berjalan tetapi akan mencegahnya memulai ulang setelah reboot, mengunci Anda keluar.
Blok Penguatan sshd_config yang Direkomendasikan
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Keputusan Penguatan Kritis yang Dijelaskan
PermitRootLogin no — Login root melalui SSH adalah target bernilai tinggi. Gunakan pengguna biasa dan eskalasi dengan sudo. Jika Anda benar-benar memerlukan akses setara root melalui kunci tertentu (misalnya, untuk otomasi), gunakan PermitRootLogin prohibit-password untuk mengizinkan login root hanya dengan kunci sambil memblokir percobaan kata sandi.
AllowTcpForwarding no — Jika server Anda bukan bastion atau jump host, nonaktifkan penerusan TCP. Penyerang dengan sesi SSH yang valid dapat menggunakan server Anda sebagai proxy untuk menjangkau sumber daya jaringan internal.
TCPKeepAlive no dengan ClientAliveInterval — TCPKeepAlive beroperasi di lapisan TCP dan terlihat oleh perantara jaringan. ClientAliveInterval mengirim pesan keepalive melalui saluran SSH terenkripsi, yang lebih andal dan lebih privat.
LoginGraceTime 30 — Mengurangi jendela di mana koneksi yang tidak terautentikasi menempati slot server. Default 120 detik terlalu lama.
AllowUsers — Daftar putih hanya akun yang benar-benar memerlukan akses SSH. Ini adalah gerbang keras yang beroperasi sebelum upaya autentikasi apa pun.
Mengubah Port SSH Default
Memindahkan SSH dari port 22 tidak meningkatkan keamanan terhadap penyerang yang ditargetkan — pemindaian port apa pun akan menemukannya. Yang dilakukannya adalah menghilangkan volume besar bot brute-force otomatis dan oportunistik yang secara eksklusif menyerang port 22. Ini secara berarti mengurangi kebisingan log dan beban server.
# In /etc/ssh/sshd_config
Port 2222
Sebelum memuat ulang, buka port baru di firewall Anda:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Jika server Anda menjalankan SELinux, Anda juga harus memperbarui konteks port SELinux:
semanage port -a -t ssh_port_t -p tcp 2222
Menghubungkan ke Server
Koneksi Dasar
ssh user@your_server_ip
Menghubungkan ke Port Non-Default
ssh -p 2222 user@your_server_ip
Menghubungkan dengan Kunci Tertentu
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Mode Verbose untuk Debugging
ssh -vvv user@your_server_ip
Flag -vvv mencetak setiap langkah handshake, percobaan autentikasi, dan negosiasi saluran. Ini adalah alat pertama yang digunakan saat koneksi gagal secara tak terduga.
Transfer File Aman Melalui SSH
SCP (Secure Copy Protocol)
SCP adalah alat penyalinan file sederhana dan non-interaktif. Ini cepat dan tersedia secara luas tetapi tidak memiliki kemampuan resume dan penanganan kesalahan yang terbatas.
Salin file lokal ke server jarak jauh:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Salin file jarak jauh ke lokal:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Penyalinan direktori rekursif:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Catatan: Proyek OpenSSH menghentikan protokol SCP lama di OpenSSH 9.0. scp modern sekarang menggunakan protokol SFTP di balik layar secara default. Antarmuka perintah tetap sama, tetapi transport yang mendasarinya lebih kuat.
SFTP (SSH File Transfer Protocol)
SFTP adalah subsistem transfer file berfitur lengkap dengan daftar direktori, manajemen izin, dan dukungan resume. Ini adalah pilihan yang tepat untuk manajemen file interaktif.
sftp -P 2222 user@your_server_ip
Perintah SFTP umum dalam sesi interaktif:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync melalui SSH (Rekomendasi Produksi)
Untuk menyinkronkan direktori, pencadangan inkremental, atau kumpulan data besar, rsync melalui SSH jauh lebih efisien daripada SCP atau SFTP. Ini hanya mentransfer blok yang berubah, bukan seluruh file.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
Flag -z mengaktifkan kompresi saat transit. Untuk data yang sudah terkompresi (arsip, gambar), hilangkan — kompresi data yang sudah terkompresi membuang CPU tanpa mengurangi ukuran transfer.
Penerusan Port SSH dan Tunneling
Penerusan port adalah salah satu kemampuan SSH yang paling kuat dan kurang dimanfaatkan. Ini memungkinkan Anda mengakses layanan yang tidak langsung terekspos ke internet secara aman.
Penerusan Port Lokal
Teruskan port lokal ke layanan jarak jauh. Contoh: akses instans MySQL jarak jauh (port 3306) yang terikat ke localhost di server:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Sekarang mysql -h 127.0.0.1 -P 3307 di mesin lokal Anda terhubung melalui terowongan terenkripsi ke MySQL jarak jauh.
Penerusan Port Jarak Jauh
Ekspos layanan lokal ke server jarak jauh. Berguna untuk menguji webhook atau berbagi server pengembangan lokal:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Penerusan Port Dinamis (Proxy SOCKS)
Ubah koneksi SSH menjadi proxy SOCKS5, merutekan lalu lintas TCP arbitrer melalui server:
ssh -D 1080 user@your_server_ip -N
Konfigurasikan browser atau aplikasi Anda untuk menggunakan SOCKS5 127.0.0.1:1080.
Agen SSH dan Penerusan Agen
ssh-agent menyimpan kunci privat yang didekripsi di memori sehingga Anda tidak perlu memasukkan kembali passphrase pada setiap koneksi.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Penerusan agen (ssh -A) memungkinkan server jarak jauh menggunakan agen lokal Anda untuk mengautentikasi ke server ketiga. Ini berguna untuk arsitektur bastion host tetapi membawa risiko: pengguna root pada server perantara dapat menggunakan soket agen yang diteruskan. Lebih baik gunakan ProxyJump:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump merutekan koneksi TCP melalui bastion tanpa mengekspos agen Anda ke sana.
Pemecahan Masalah SSH Umum
Koneksi Ditolak (ssh: connect to host ... port 22: Connection refused)
Diagnosis sistematis:

Verifikasi daemon SSH sedang berjalan: systemctl status sshd

• Konfirmasi port yang mendengarkan: ss -tlnp | grep sshd
• Periksa aturan firewall: ufw status atau iptables -L -n | grep 22
• Verifikasi server dapat dijangkau di tingkat jaringan: ping your_server_ip
• Jika menggunakan penyedia cloud, periksa aturan grup keamanan atau ACL jaringan di konsol penyedia.

Izin Ditolak (publickey)

Ini adalah kesalahan SSH yang paling umum. Kerjakan daftar periksa ini:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Penyebab umum di luar izin:

• File authorized_keys berisi kunci yang salah (misalnya, Anda menyalin kunci privat alih-alih file .pub).

StrictModes yes dalam sshd_config (default) menolak koneksi jika izin direktori home terlalu terbuka — chmod 755 ~ adalah maksimum yang diizinkan.
AllowUsers atau AllowGroups dalam sshd_config mengecualikan pengguna yang terhubung.
SELinux memblokir akses ke ~/.ssh/ — periksa ausearch -m avc -ts recent.

Timeout Koneksi SSH
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval mengirim paket null melalui saluran terenkripsi setiap 60 detik. Setelah ClientAliveCountMax respons yang terlewat berturut-turut, server mengakhiri koneksi. Ini mencegah akumulasi sesi zombie.
Verifikasi Kunci Host Gagal
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Peringatan ini berarti kunci host server tidak lagi cocok dengan yang tersimpan di ~/.ssh/known_hosts. Penyebab yang sah termasuk penginstalan ulang server atau penugasan ulang alamat IP. Penyebab berbahaya termasuk serangan man-in-the-middle. Selidiki sebelum melanjutkan.
Jika Anda telah mengonfirmasi server diinstal ulang secara sah:
ssh-keygen -R your_server_ip
Kemudian hubungkan kembali dan verifikasi sidik jari kunci host baru terhadap konsol server atau dasbor penyedia sebelum menerimanya.
Autentikasi Multi-Faktor untuk SSH
Autentikasi berbasis kunci kuat, tetapi menambahkan faktor kedua TOTP (Time-based One-Time Password) menciptakan pertahanan berlapis. Bahkan jika kunci privat dan passphrase-nya dikompromikan, penyerang tidak dapat mengautentikasi tanpa token TOTP.
Instal dan konfigurasikan libpam-google-authenticator di server:
apt install libpam-google-authenticator
google-authenticator
Kemudian konfigurasikan PAM dan sshd_config:
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Dengan AuthenticationMethods publickey,keyboard-interactive, pengguna harus menyediakan kunci yang valid DAN kode TOTP. Ini adalah konfigurasi produksi yang benar untuk server bernilai tinggi.
Certificate Authority SSH: Penskalaan Manajemen Kunci
Di lingkungan dengan puluhan server dan beberapa administrator, mengelola entri authorized_keys individual menjadi tidak berkelanjutan secara operasional. Sertifikat SSH memecahkan masalah ini.
Certificate Authority (CA) SSH menandatangani kunci pengguna dan host. Server mempercayai kunci publik CA daripada kunci pengguna individual. Menambahkan administrator baru hanya memerlukan penandatanganan kunci publik mereka — tidak ada perubahan pada file authorized_keys server mana pun.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
Di setiap server, konfigurasikan kepercayaan untuk CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
Inilah cara infrastruktur skala besar (termasuk penyedia cloud dan perusahaan) mengelola akses SSH tanpa manajemen kunci per-server.
Matriks Keputusan Praktis: Konfigurasi SSH berdasarkan Kasus Penggunaan



Kasus Penggunaan
Jenis Kunci
Port
Auth Kata Sandi
Login Root
Penerusan
MFA








—
—
—
—
—
—
—








VPS pribadi
Ed25519
2222+
Dinonaktifkan
Dilarang
Dinonaktifkan
Opsional








Server web produksi
Ed25519
Non-default
Dinonaktifkan
Tidak
Dinonaktifkan
Diperlukan








Bastion / jump host
Ed25519
22 atau kustom
Dinonaktifkan
Tidak
Terkontrol
Diperlukan








Otomasi CI/CD
Ed25519 (kunci deploy)
Non-default
Dinonaktifkan
Tidak
Dinonaktifkan
Tidak (hanya kunci)








Server database
Ed25519
Non-default
Dinonaktifkan
Tidak
Hanya lokal
Diperlukan








Server pengembangan
Ed25519
Default atau kustom
Opsional
Tidak
Opsional
Opsional





Menyiapkan SSH di Infrastruktur AlexHost
Saat Anda menyediakan VPS atau server dedicated melalui AlexHost, akses SSH dikonfigurasi secara default. Kata sandi root awal dikirimkan melalui email provisi, dan tindakan pertama yang direkomendasikan adalah:

Login sebagai root, buat pengguna administratif non-root, dan tambahkan kunci publik Anda ke ~/.ssh/authorized_keys pengguna tersebut.
Terapkan baseline penguatan sshd_config yang didokumentasikan di atas.
Nonaktifkan autentikasi kata sandi dan login root.
Konfigurasikan firewall Anda untuk membatasi akses SSH ke rentang IP yang diketahui di mana hal ini layak secara operasional.

Jika Anda lebih suka lapisan manajemen grafis bersama SSH, opsi VPS dengan cPanel dan Panel Kontrol VPS AlexHost menyediakan antarmuka web untuk tugas umum sambil tetap membiarkan SSH tersedia untuk kontrol administratif penuh.
Untuk lingkungan di mana Anda perlu mengamankan aplikasi web yang berjalan di server yang sama, memadukan penguatan SSH dengan sertifikat SSL yang dikonfigurasi dengan benar mencakup lapisan transport administratif dan aplikasi.
Daftar Periksa Poin Kunci Teknis
Sebelum menganggap konfigurasi SSH Anda siap produksi, verifikasi masing-masing hal berikut:
Manajemen Kunci

Kunci privat menggunakan Ed25519 atau minimum RSA-4096
Semua kunci privat dilindungi dengan passphrase yang kuat
Direktori ~/.ssh/ memiliki izin 700; authorized_keys memiliki 600

• Kunci deploy menggunakan opsi restrict dan command= jika berlaku
• Jadwal rotasi kunci didokumentasikan dan diterapkan

Konfigurasi Server

PasswordAuthentication no ditetapkan dan aktif
PermitRootLogin no atau prohibit-password diterapkan
SSH berjalan pada port non-default dengan aturan firewall yang diperbarui
AllowUsers atau AllowGroups membatasi akses ke akun yang disebutkan
LoginGraceTime diatur ke 30 detik atau kurang
sshd -t lulus tanpa kesalahan setelah setiap perubahan konfigurasi

Penguatan Kriptografi

KexAlgorithms mengecualikan diffie-hellman-group1-sha1 dan diffie-hellman-group14-sha1

• Ciphers mengecualikan 3des-cbc, arcfour, dan blowfish-cbc
• MACs hanya menggunakan varian -etm (encrypt-then-MAC)

Keamanan Operasional

• Log autentikasi SSH dipantau (/var/log/auth.log atau journalctl -u sshd)
• fail2ban atau yang setara dikonfigurasi untuk memblokir kegagalan autentikasi berulang
• Sidik jari kunci host dicatat dan disimpan di luar jalur untuk verifikasi
• MFA diaktifkan untuk semua sesi pengguna interaktif pada sistem produksi
• SSH CA digunakan untuk lingkungan dengan lebih dari lima server atau tiga administrator

FAQ

Apa perbedaan antara kunci SSH dan sertifikat SSH?

Kunci SSH mengharuskan setiap server menyimpan kunci publik pengguna di authorized_keys. Sertifikat SSH ditandatangani oleh Certificate Authority; server mempercayai CA daripada kunci individual. Sertifikat berskala ke armada besar tanpa manajemen kunci per-server dan mendukung waktu kedaluwarsa, membuat pencabutan menjadi mudah.

Mengapa Permission denied (publickey) muncul bahkan ketika kunci sudah benar?

Penyebab paling umum adalah izin file yang salah pada ~/.ssh/ (harus 700) atau authorized_keys (harus 600), direktori home yang dapat ditulis oleh semua orang (diblokir oleh StrictModes), atau direktif AllowUsers dalam sshd_config yang mengecualikan akun yang terhubung. Periksa journalctl -u sshd di server untuk alasan penolakan spesifik.

Apakah mengubah port SSH dari 22 merupakan langkah keamanan yang nyata?

Ini menghilangkan serangan oportunistik otomatis yang menargetkan port 22, yang secara berarti mengurangi kebisingan log dan percobaan autentikasi yang gagal. Ini tidak melindungi terhadap penyerang yang ditargetkan yang melakukan pemindaian port. Ini harus dikombinasikan dengan fail2ban, autentikasi hanya kunci, dan daftar izin IP firewall untuk peningkatan keamanan yang berarti.

Bisakah saya menggunakan SSH tanpa alamat IP statis di sisi klien?

Ya. Autentikasi berbasis kunci tidak memerlukan IP klien tetap. Jika Anda ingin membatasi berdasarkan IP, gunakan opsi from= dalam authorized_keys atau aturan firewall. Untuk IP dinamis, pertimbangkan VPN untuk membangun identitas jaringan yang stabil sebelum terhubung, daripada membuka SSH ke seluruh internet.

Apa cara paling aman untuk memulihkan akses SSH jika saya terkunci?

Akses server melalui konsol out-of-band penyedia hosting Anda (VNC, IPMI, atau KVM over IP). Dari sana, mount filesystem, perbaiki masalah sshd_config atau authorized_keys, dan mulai ulang daemon SSH. Pada paket VPS dan server dedicated AlexHost, konsol penyedia tersedia melalui portal klien dan tidak bergantung pada SSH yang berfungsi.