SSH merupakan salah satu pintu utama untuk mengelola server Linux. Hampir semua aktivitas administrasi server, mulai dari instalasi aplikasi, konfigurasi jaringan, pengelolaan database, hingga maintenance sistem, dapat dilakukan melalui SSH.

Masalahnya, keamanan SSH tidak cukup hanya mengandalkan username dan password.

Jika password administrator bocor akibat phishing, credential stuffing, password reuse, malware, atau kebocoran database dari layanan lain, penyerang berpotensi langsung mendapatkan akses ke server. Di sinilah Two-Factor Authentication atau 2FA menjadi lapisan pertahanan tambahan yang sangat berguna.

Salah satu metode yang relatif mudah diterapkan pada server Linux adalah TOTP menggunakan Google Authenticator dan modul PAM pam_google_authenticator.

Dengan konfigurasi ini, proses login SSH dapat meminta faktor autentikasi tambahan berupa kode OTP yang berubah secara berkala. Modul PAM memverifikasi kode tersebut menggunakan secret key yang tersimpan pada server dan aplikasi authenticator pada perangkat pengguna. (Ubuntu Manpages)

Artikel ini membahas konsepnya sekaligus memberikan tutorial praktis untuk menerapkan 2FA pada SSH menggunakan Ubuntu Server dan OpenSSH.

Apa Itu 2FA untuk SSH?

Two-Factor Authentication atau 2FA adalah mekanisme autentikasi yang membutuhkan dua faktor berbeda sebelum pengguna diperbolehkan masuk.

Secara sederhana:

Password saja:

Username + Password
        ↓
     SSH Server
        ↓
      Login

Dengan 2FA:

Username
   +
Password
   +
OTP / TOTP
   ↓
SSH Server
   ↓
Login

Jadi, meskipun password berhasil diketahui penyerang, akses belum tentu berhasil karena penyerang masih membutuhkan faktor kedua.

Dalam skenario artikel ini, faktor kedua berupa kode TOTP yang dihasilkan oleh aplikasi authenticator.

TOTP merupakan singkatan dari Time-Based One-Time Password. Kode dibuat berdasarkan secret key dan waktu sehingga kode akan berubah secara berkala.

Google Authenticator PAM module mendukung mekanisme TOTP maupun HOTP. (Ubuntu Manpages)

Mengapa 2FA untuk SSH Penting?

Bayangkan server memiliki alamat IP publik:

203.0.113.10

Port SSH terbuka di internet:

TCP/22

Bot internet dapat menemukan layanan tersebut dan mencoba berbagai kombinasi username dan password.

Jika autentikasi hanya menggunakan password:

Attacker
   ↓
SSH
   ↓
Username + Password
   ↓
Berhasil

Dengan 2FA:

Attacker
   ↓
SSH
   ↓
Username + Password
   ↓
Meminta OTP
   ↓
Tidak memiliki OTP
   ↓
Gagal

2FA tidak membuat SSH kebal terhadap serangan, tetapi menambahkan lapisan keamanan penting.

Penting juga dipahami bahwa 2FA bukan pengganti seluruh praktik hardening. Firewall, pembatasan akses jaringan, SSH key, fail2ban, patch keamanan, logging, monitoring, dan prinsip least privilege tetap diperlukan.

Apa Itu PAM?

PAM adalah singkatan dari Pluggable Authentication Modules.

PAM merupakan framework autentikasi yang digunakan Linux untuk berbagai layanan.

Secara sederhana, PAM dapat dianalogikan sebagai “mesin pemeriksaan identitas”.

Ketika pengguna login:

User
 ↓
SSH
 ↓
PAM
 ├── Password verification
 ├── OTP verification
 └── Account checks
 ↓
Login allowed / denied

pam_google_authenticator.so bertindak sebagai salah satu modul autentikasi yang dapat dipanggil PAM.

Menurut dokumentasi modul, secret secara default disimpan dalam file .google_authenticator di home directory pengguna. Modul kemudian menggunakan secret tersebut untuk memverifikasi OTP. (Ubuntu Manpages)

Google Authenticator Sebenarnya Bukan Hanya untuk Google

Ada kesalahpahaman umum bahwa Google Authenticator hanya dapat digunakan untuk akun Google.

Dalam konteks ini, Google Authenticator berfungsi sebagai aplikasi pembangkit kode OTP.

Server tidak perlu melakukan login ke Google untuk memvalidasi kode.

Alurnya lebih sederhana:

                  SECRET
              ┌─────────────┐
              │             │
              ▼             ▼
       Authenticator      Linux Server
              │             │
              │             │
          TOTP Code    PAM Verification
              │             │
              └──────┬──────┘
                     ▼
                Match?
                 /    \
               Yes     No
                ↓       ↓
              Allow    Deny

Secret yang sama digunakan oleh aplikasi authenticator dan server untuk menghasilkan atau memvalidasi kode TOTP.

Persiapan Sebelum Mengaktifkan 2FA

Jangan langsung mengaktifkan 2FA pada server produksi tanpa persiapan.

Kesalahan konfigurasi PAM atau SSH dapat membuat administrator terkunci dari server.

Sebelum memulai, pastikan:

• Memiliki akses administrator atau sudo.
• SSH saat ini dapat digunakan dengan normal.
• Memiliki sesi SSH aktif sebagai jalur pemulihan.
• Memiliki akses console/VPS console jika tersedia.
• Memiliki aplikasi authenticator di perangkat.
• Waktu server sudah benar.
• SSH key sudah tersedia jika ingin menggunakan skema yang lebih kuat.
• Mengetahui lokasi file konfigurasi PAM dan SSH.

Untuk deployment produksi, Ubuntu sendiri merekomendasikan agar autentikasi public key dan konfigurasi 2FA dipersiapkan sebelum 2FA dibuat wajib bagi pengguna. (Ubuntu)

Studi Kasus

Misalnya kita mempunyai server:

OS       : Ubuntu Server
Hostname : server01
IP       : 203.0.113.10
User     : admin
SSH Port : 22

Target keamanan:

SSH Key
   +
TOTP
   ↓
Login SSH

Dengan demikian, penyerang membutuhkan lebih dari satu faktor.

Langkah 1 — Update Sistem

Sebelum memasang paket, update repository:

sudo apt update
sudo apt upgrade

Pada server produksi, sebaiknya pahami terlebih dahulu paket apa saja yang akan diperbarui sebelum melakukan upgrade.

Langkah 2 — Install Google Authenticator PAM

Ubuntu menyediakan paket libpam-google-authenticator.

Jalankan:

sudo apt update
sudo apt install libpam-google-authenticator

Ubuntu mendokumentasikan paket tersebut sebagai PAM module untuk autentikasi TOTP/HOTP. (Ubuntu)

Setelah instalasi, pastikan binary tersedia:

which google-authenticator

Biasanya akan menghasilkan:

/usr/bin/google-authenticator

Paket tersebut juga memasang modul PAM pam_google_authenticator.so. (Ubuntu Packages)

Langkah 3 — Buat Secret TOTP

Login sebagai user yang ingin diamankan.

Contohnya:

su - admin

Kemudian jalankan:

google-authenticator

Program tersebut akan membuat secret key dan konfigurasi pengguna.

Pada sistem yang mendukung QR encoding, konfigurasi dapat menampilkan QR Code yang bisa dipindai menggunakan aplikasi Google Authenticator. (GitHub)

Setelah QR Code muncul:

1. Buka aplikasi authenticator.
2. Pilih opsi menambahkan akun.
3. Scan QR Code.
4. Pastikan kode yang ditampilkan aplikasi sesuai dengan kode yang diminta server.
5. Simpan konfigurasi dengan aman.

File secret secara default berada di:

~/.google_authenticator

Dokumentasi PAM menyatakan bahwa file tersebut merupakan lokasi default secret untuk pengguna. (Ubuntu Manpages)

Langkah 4 — Lindungi File Secret

Periksa permission:

ls -la ~/.google_authenticator

Idealnya file secret tidak dapat dibaca oleh user lain.

Periksa:

stat ~/.google_authenticator

Jika diperlukan, gunakan:

chmod 600 ~/.google_authenticator

Kepemilikan juga harus sesuai:

chown admin:admin ~/.google_authenticator

Modul Google Authenticator secara default melakukan pemeriksaan ownership dan permission terhadap secret file. Dokumentasi proyek juga memperingatkan bahwa opsi seperti no_strict_owner dan allowed_perm dapat menurunkan perlindungan jika digunakan sembarangan. (GitHub)

Langkah 5 — Konfigurasi PAM SSH

Edit konfigurasi PAM untuk SSH:

sudo nano /etc/pam.d/sshd

Tambahkan:

auth required pam_google_authenticator.so

Baris tersebut membuat PAM meminta verifikasi Google Authenticator.

Dokumentasi resmi modul menggunakan pola:

auth required pam_google_authenticator.so

dan merekomendasikan penggunaan required, bukan requisite, untuk kombinasi autentikasi tertentu agar password dan OTP tetap diproses sesuai kebijakan autentikasi. (GitHub)

Bagaimana dengan nullok?

Anda mungkin menemukan konfigurasi:

auth required pam_google_authenticator.so nullok

nullok memungkinkan user tetap login jika belum mempunyai secret OTP. Fitur ini berguna ketika melakukan rollout bertahap. (GitHub)

Namun untuk kondisi ketika 2FA sudah diwajibkan, lebih baik tidak menggunakan nullok.

Dengan kata lain:

nullok
↓
OTP belum tersedia → masih bisa login

Sedangkan:

tanpa nullok
↓
OTP wajib tersedia

Untuk deployment produksi yang sudah selesai migrasi, gunakan kebijakan yang benar-benar mewajibkan faktor kedua.

Langkah 6 — Konfigurasi SSH

Edit:

sudo nano /etc/ssh/sshd_config

Pastikan PAM aktif:

UsePAM yes

Aktifkan keyboard-interactive authentication:

KbdInteractiveAuthentication yes

Pada OpenSSH modern, KbdInteractiveAuthentication adalah konfigurasi yang digunakan untuk mengizinkan keyboard-interactive authentication. ChallengeResponseAuthentication merupakan alias lama yang sudah deprecated pada dokumentasi OpenSSH modern. (Man OpenBSD)

Opsi A — Password + OTP

Untuk skenario yang masih menggunakan password:

UsePAM yes
KbdInteractiveAuthentication yes
PasswordAuthentication yes

Kemudian PAM menangani proses autentikasi sesuai konfigurasi.

Namun untuk server yang terekspos internet, pendekatan yang lebih kuat adalah menggunakan SSH public key sebagai faktor pertama.

Opsi B — SSH Key + OTP

Pendekatan yang lebih baik untuk server administrasi adalah:

SSH Public Key
       +
      TOTP
       ↓
     Login

Contoh:

AuthenticationMethods publickey,keyboard-interactive:pam

Artinya pengguna harus berhasil melalui public key terlebih dahulu, kemudian menyelesaikan keyboard-interactive authentication melalui PAM.

OpenSSH mendukung AuthenticationMethods untuk menentukan beberapa metode autentikasi yang harus berhasil secara berurutan. Dokumentasi OpenSSH juga menjelaskan penggunaan keyboard-interactive:pam untuk membatasi metode keyboard-interactive ke PAM. (Man OpenBSD)

Pastikan public key authentication aktif:

PubkeyAuthentication yes

Sehingga konfigurasi penting dapat menjadi:

UsePAM yes
PubkeyAuthentication yes
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive:pam

Catatan penting: konfigurasi aktual harus disesuaikan dengan versi OpenSSH, distribusi Linux, metode login yang sudah digunakan, dan konfigurasi PAM yang ada.

Langkah 7 — Validasi Konfigurasi SSH

Jangan langsung restart SSH setelah mengubah konfigurasi.

Periksa terlebih dahulu:

sudo sshd -t

Jika tidak ada output, biasanya konfigurasi sintaks berhasil diproses.

Jika terdapat error, jangan restart SSH sebelum masalah tersebut diperbaiki.

Ini adalah salah satu kebiasaan penting sysadmin:

Edit
 ↓
Validate
 ↓
Test
 ↓
Reload

Bukan:

Edit
 ↓
Restart
 ↓
Panik

Langkah 8 — Reload SSH

Setelah konfigurasi valid:

sudo systemctl reload ssh

Pada beberapa distribusi/service naming dapat menggunakan:

sudo systemctl reload sshd

Periksa status:

sudo systemctl status ssh

Jika service menggunakan nama sshd, sesuaikan dengan sistem Anda.

Langkah 9 — Jangan Tutup Sesi SSH Lama

Ini sangat penting.

Biarkan sesi SSH lama tetap terbuka.

Buka terminal baru dan lakukan pengujian:

ssh admin@203.0.113.10

Jika menggunakan SSH key + OTP, alurnya kira-kira:

SSH key authentication
        ↓
Keyboard-interactive
        ↓
Verification code
        ↓
Login berhasil

Jika berhasil, barulah sesi lama dapat ditutup.

Langkah 10 — Uji OTP Salah

Pengujian keamanan tidak hanya dilakukan dengan kode yang benar.

Coba masukkan kode yang salah.

Hasil yang diharapkan:

Password/Key
    ↓
OTP salah
    ↓
Authentication failed

Kemudian gunakan kode yang benar.

Jika OTP benar:

Password/Key
    ↓
OTP benar
    ↓
Authentication successful

Cara Kerja TOTP

TOTP dapat dianalogikan seperti kunci yang berubah setiap periode waktu.

Server dan aplikasi authenticator memiliki secret yang sama.

Secara konseptual:

Secret Key + Current Time
          ↓
       Algorithm
          ↓
      OTP Code

Server melakukan perhitungan serupa:

Secret Key + Current Time
          ↓
       Algorithm
          ↓
Expected OTP

Kemudian:

User OTP == Server OTP
        ↓
      Valid

Karena kode berubah berdasarkan waktu, satu kode tidak dapat digunakan selamanya.

Inilah perbedaan penting antara password biasa dan OTP.

Password:

Password123
Password123
Password123

TOTP:

123456
↓
827194
↓
451203
↓
...

Masalah Waktu Server

Salah satu penyebab umum OTP gagal adalah sinkronisasi waktu.

Pastikan server memiliki waktu yang benar:

timedatectl

Periksa:

System clock synchronized
NTP service
Time zone

Jika waktu server terlalu melenceng, kode TOTP dapat ditolak.

Aktifkan sinkronisasi waktu menggunakan mekanisme NTP yang sesuai dengan distribusi Linux Anda.

Apa yang Terjadi Jika Ponsel Hilang?

Ini salah satu alasan mengapa recovery plan harus dibuat sebelum 2FA diterapkan.

Jangan hanya bertanya:

“Bagaimana mengaktifkan 2FA?”

Pertanyaan yang lebih penting:

“Bagaimana saya masuk ketika perangkat authenticator hilang?”

Beberapa strategi:

• Simpan recovery/emergency codes di tempat aman.
• Pastikan tersedia console access.
• Siapkan akun administrator alternatif.
• Simpan backup secret secara offline dan terenkripsi jika kebijakan organisasi mengizinkannya.
• Dokumentasikan prosedur recovery.
• Jangan menyimpan secret OTP di repository Git.
• Jangan mengirim QR Code melalui chat biasa.

Modul Google Authenticator juga mendukung emergency codes yang dapat digunakan sebagai alternatif kode OTP dalam kondisi tertentu. (GitHub)

Kesalahan yang Sering Terjadi

1. Langsung Mengaktifkan 2FA di Server Produksi

Kesalahan:

Install PAM
↓
Edit sshd_config
↓
Restart SSH
↓
Tidak bisa login

Solusi:

Pertahankan sesi SSH aktif, validasi konfigurasi, dan lakukan pengujian dari koneksi kedua.

2. Mengaktifkan 2FA Sebelum User Menyiapkan Secret

Jika 2FA dibuat wajib sebelum user mempunyai secret, user dapat kehilangan akses.

Untuk rollout bertahap, nullok dapat digunakan sementara agar pengguna tanpa secret tetap dapat login. Setelah seluruh pengguna selesai enrollment, kebijakan dapat diperketat dengan menghapus nullok. (GitHub)

3. Salah Mengedit /etc/pam.d/sshd

PAM sangat sensitif.

Satu kesalahan konfigurasi dapat memengaruhi autentikasi SSH.

Sebelum mengedit:

sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.backup

4. Tidak Memvalidasi sshd_config

Selalu jalankan:

sudo sshd -t

sebelum reload atau restart.

5. Waktu Server Tidak Sinkron

Jika OTP terus ditolak walaupun terlihat benar, periksa:

timedatectl

6. Menggunakan Secret File dengan Permission Longgar

Jangan membuat file secret dapat dibaca semua user.

Gunakan:

chmod 600 ~/.google_authenticator

dan pastikan ownership sesuai.

7. Menonaktifkan SSH Password Tanpa Memastikan Key Berfungsi

Jangan melakukan:

PasswordAuthentication no

sebelum memastikan public key authentication berhasil.

Gunakan sesi kedua untuk pengujian.

8. Tidak Menyiapkan Recovery

2FA meningkatkan keamanan, tetapi juga menambah kemungkinan administrator kehilangan akses jika recovery tidak dirancang.

Security tanpa recovery plan adalah resep untuk rapat darurat pukul 02.00.

Troubleshooting

OTP Selalu Ditolak

Periksa waktu:

timedatectl

Pastikan waktu server dan perangkat authenticator relatif sinkron.

Periksa file secret:

ls -la ~/.google_authenticator

Pastikan owner dan permission benar.

Login Berhenti Setelah Memasukkan Password

Periksa konfigurasi:

sudo nano /etc/pam.d/sshd

Pastikan modul tersedia:

find /lib /usr/lib -name 'pam_google_authenticator.so' 2>/dev/null

Periksa log autentikasi.

Pada Ubuntu, salah satu lokasi yang umum digunakan:

sudo tail -f /var/log/auth.log

Kemudian lakukan percobaan login dari terminal lain.

SSH Tidak Bisa Start Setelah Konfigurasi

Jangan panik dan jangan langsung menghapus konfigurasi secara acak.

Periksa:

sudo sshd -t

Kemudian:

sudo journalctl -u ssh -n 100 --no-pager

Jika service bernama sshd, gunakan:

sudo journalctl -u sshd -n 100 --no-pager

Tidak Mendapat Prompt OTP

Periksa:

UsePAM yes
KbdInteractiveAuthentication yes

Jika menggunakan AuthenticationMethods, pastikan metode yang dipilih memang tersedia dan konfigurasi PAM untuk SSH benar.

OpenSSH hanya menawarkan metode autentikasi yang diizinkan oleh konfigurasi server, sehingga kesalahan pada AuthenticationMethods dapat mengubah alur login. (Man OpenBSD)

Best Practice 2FA untuk SSH

Untuk server produksi, jangan berhenti pada instalasi Google Authenticator.

Gunakan defense in depth.

1. Prioritaskan SSH Key + TOTP

Arsitektur yang baik:

SSH Key
   +
TOTP
   +
Firewall
   +
Fail2ban
   +
Monitoring
   +
Logging

2. Nonaktifkan Root Login

Jika memungkinkan:

PermitRootLogin no

Gunakan akun administrator biasa dengan sudo.

3. Gunakan SSH Key

SSH key lebih kuat dan lebih nyaman dibanding password jika dikelola dengan benar.

4. Batasi Akses SSH

Jika server hanya digunakan dari jaringan tertentu, pertimbangkan pembatasan firewall atau VPN.

Contoh arsitektur:

Internet
   ↓
Firewall
   ↓
VPN / Bastion
   ↓
SSH
   ↓
2FA
   ↓
Server

5. Gunakan Fail2ban atau Mekanisme Rate Limiting

2FA bukan pengganti proteksi terhadap brute-force.

Tetap gunakan mekanisme pembatasan percobaan login sesuai kebutuhan.

6. Monitoring

Pantau:

• Failed SSH login.
• Successful login.
• Perubahan konfigurasi PAM.
• Perubahan sshd_config.
• Login administrator.
• Anomali waktu login.
• Percobaan brute-force.

7. Backup Konfigurasi

Backup file penting sebelum perubahan:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.backup

8. Dokumentasikan Recovery

Dokumentasi harus mencakup:

Siapa administrator?
Di mana console access?
Bagaimana recovery OTP?
Di mana emergency code?
Bagaimana menonaktifkan 2FA sementara?
Siapa yang memiliki akses darurat?

Ini sangat penting untuk organisasi.

Apakah 2FA Membuat SSH 100% Aman?

Tidak.

Tidak ada satu mekanisme keamanan yang membuat server 100% aman.

2FA terutama membantu mengurangi risiko akibat credential yang dicuri.

Namun masih terdapat risiko lain seperti:

• Private key dicuri.
• Endpoint administrator terinfeksi malware.
• Session hijacking.
• Server terkena vulnerability.
• Misconfiguration.
• Privilege escalation.
• Social engineering.
• Kompromi perangkat authenticator.
• Kebocoran secret TOTP.

Karena itu, 2FA sebaiknya dipandang sebagai satu lapisan dalam defense in depth.

Arsitektur Keamanan yang Direkomendasikan

Untuk server penting, arsitektur sederhana dapat dibuat seperti:

                    INTERNET
                       │
                       ▼
                 ┌───────────┐
                 │ FIREWALL  │
                 └─────┬─────┘
                       │
                       ▼
                ┌─────────────┐
                │ SSH SERVICE │
                └──────┬──────┘
                       │
              ┌────────┴────────┐
              │                 │
              ▼                 ▼
          SSH PUBLIC KEY       PAM
                                │
                                ▼
                              TOTP
                                │
                                ▼
                         AUTHENTICATED
                                │
                                ▼
                             SERVER

Untuk lingkungan enterprise, akses dapat ditambahkan melalui VPN atau bastion host.

Checklist Implementasi

Gunakan checklist berikut sebelum menyatakan konfigurasi selesai.

[ ] SSH key sudah diuji
[ ] Console/recovery access tersedia
[ ] Paket PAM terinstal
[ ] Secret TOTP dibuat
[ ] Authenticator berhasil membaca QR
[ ] File .google_authenticator terlindungi
[ ] PAM dikonfigurasi
[ ] UsePAM aktif
[ ] Keyboard-interactive aktif
[ ] AuthenticationMethods sesuai desain
[ ] sshd_config sudah divalidasi
[ ] SSH berhasil reload
[ ] Login OTP berhasil
[ ] OTP salah ditolak
[ ] Waktu server sinkron
[ ] Log autentikasi dapat dipantau
[ ] Recovery procedure tersedia
[ ] Backup konfigurasi tersedia

Kesimpulan

2FA untuk SSH adalah salah satu peningkatan keamanan yang cukup efektif dan relatif mudah diterapkan pada server Linux.

Dengan Google Authenticator dan PAM, administrator dapat menambahkan faktor autentikasi berbasis TOTP di atas mekanisme autentikasi yang sudah ada.

Arsitektur sederhananya:

SSH Key / Password
        +
      TOTP
        ↓
   SSH Authentication

Untuk server produksi, pendekatan yang lebih kuat adalah menggabungkan SSH public key dengan TOTP, kemudian melengkapinya dengan firewall, pembatasan akses, hardening SSH, logging, monitoring, dan recovery plan.

Hal paling penting bukan sekadar berhasil memasang Google Authenticator.

Yang lebih penting adalah memastikan seluruh proses login, deployment, recovery, dan monitoring dirancang sebagai satu sistem keamanan.

Jika server adalah aset penting, jangan biarkan SSH menjadi satu pintu dengan satu kunci.

Tambahkan lapisan pertahanan.

Dan pastikan Anda sendiri masih memiliki kunci cadangan ketika lapisan tersebut mulai bekerja.

Referensi Teknis

Dokumentasi Ubuntu menjelaskan instalasi libpam-google-authenticator dan konfigurasi TOTP/HOTP untuk autentikasi server. (Ubuntu)

Dokumentasi proyek Google Authenticator PAM menjelaskan konfigurasi PAM, secret file, TOTP/HOTP, opsi nullok, serta pertimbangan permission dan ownership. (GitHub)

Dokumentasi OpenSSH menjelaskan AuthenticationMethods, KbdInteractiveAuthentication, dan penggunaan keyboard-interactive melalui PAM. (Man OpenBSD)

FAQ

Pertanyaan: Apa itu 2FA untuk SSH?

Jawaban: 2FA untuk SSH adalah mekanisme autentikasi yang membutuhkan faktor tambahan selain password atau SSH key, misalnya kode TOTP dari aplikasi authenticator.

Pertanyaan: Apakah Google Authenticator bisa digunakan untuk SSH?

Jawaban: Bisa. Google menyediakan PAM module yang dapat digunakan untuk menambahkan autentikasi TOTP atau HOTP pada layanan seperti SSH. (GitHub)

Pertanyaan: Apakah Google Authenticator harus terhubung ke internet?

Jawaban: Untuk menghasilkan kode TOTP, aplikasi authenticator pada dasarnya tidak perlu terhubung ke internet. Yang penting waktu perangkat dan server cukup sinkron.

Pertanyaan: Di mana secret Google Authenticator disimpan?

Jawaban: Secara default, modul menggunakan file .google_authenticator di home directory pengguna. (Ubuntu Manpages)

Pertanyaan: Apakah 2FA menggantikan SSH key?

Jawaban: Tidak. Untuk keamanan yang lebih kuat, SSH public key dapat digunakan sebagai faktor pertama dan TOTP sebagai faktor kedua.

Pertanyaan: Apa fungsi nullok pada PAM Google Authenticator?

Jawaban: nullok memungkinkan pengguna tanpa secret OTP tetap login. Biasanya berguna saat rollout bertahap, tetapi sebaiknya dihapus setelah seluruh pengguna sudah menggunakan 2FA. (GitHub)

Pertanyaan: Apa penyebab OTP selalu gagal?

Jawaban: Penyebab umum adalah waktu server tidak sinkron, secret salah, file secret bermasalah, konfigurasi PAM tidak tepat, atau konfigurasi SSH tidak mengizinkan keyboard-interactive authentication.

Pertanyaan: Apakah 2FA membuat server sepenuhnya aman?

Jawaban: Tidak. 2FA hanya satu lapisan keamanan. Server tetap membutuhkan SSH hardening, firewall, patch keamanan, monitoring, logging, access control, dan recovery plan.

SSH adalah salah satu akses paling sensitif pada server. Jangan biarkan username dan password menjadi satu-satunya benteng pertahanan.

Dengan mengombinasikan SSH key, PAM, dan TOTP melalui Google Authenticator, Anda dapat menambahkan lapisan keamanan yang jauh lebih kuat pada server Linux.

Sudah menggunakan 2FA untuk SSH?

Bagikan pengalaman Anda di kolom komentar. Apakah menggunakan Google Authenticator, hardware security key, VPN, bastion host, atau metode lainnya?

Jika artikel ini bermanfaat, bagikan kepada rekan sysadmin, network administrator, DevOps, atau siapa pun yang mengelola server Linux.

Jangan lupa baca artikel teknologi lainnya untuk mempelajari Linux Server, Networking, MikroTik, Cybersecurity, DevOps, Cloud Computing, dan Infrastruktur IT.

Keamanan server bukan satu fitur. Keamanan adalah proses.

Untuk tutorial ini, konfigurasi sebaiknya diuji terlebih dahulu pada server lab sebelum diterapkan ke server produksi. PAM dan SSH berada langsung di jalur autentikasi; satu kesalahan konfigurasi dapat menyebabkan lockout. Ubuntu dan dokumentasi proyek Google Authenticator juga menekankan pentingnya menyiapkan metode akses yang diperlukan sebelum 2FA diwajibkan. (Ubuntu)