Sadece key'le SSH kurulduktan sonra, sıradaki öneri genelde key'in üzerine two-factor authentication oluyor, bir authenticator app'ten bir TOTP code, private key'e ek olarak gerekiyor. Bu, obvious bir sonraki adım gibi sunuluyor, daha fazla factor, daha fazla security. Yanlış değil, ama bunun gerçekte hangi threat'i adresslediği konusunda spesifik olmaya değer, çünkü bu, friction'ın nerede değdiğini ve nerede değmediğini belirliyor.
Gerçekte neye karşı koruyor
Sadece key'le SSH, zaten guess edilen, leak olan, ya da phish edilen bir password'ün kimseyi içeri almadığı anlamına geliyor, çalınacak bir password yok. SSH 2FA'nın ek koruması spesifik olarak private key'in kendisinin compromise olmasına karşı, bir laptop'tan çalınması, unencrypted bir backup'tan kopyalanması, ya da başka bir şekilde compromise olmuş bir machine'den kullanılması. Bu olursa, key tek başına yetmiyor, attacker'ın ayrıca, ayrı bir device'da yaşayan TOTP code'una da ihtiyacı oluyor.
Bu gerçek bir senaryo, laptop'lar çalınıyor, backup'lar misconfigure ediliyor, ve "key encrypted bir disk'te, o yüzden sorun yok" disk encryption'ın gerçekten configure edilmiş olduğunu ve laptop'un locked olduğunu assume ediyor. Ama bu spesifik bir senaryo, ve adresslenen şeyin, key-only auth'un zaten oldukça iyi adresslediği "genel olarak SSH security"si değil, tam olarak bu olduğunu açık etmeye değer.
Setup
pam_google_authenticator, Linux'ta SSH'a TOTP eklemenin yaygın yolu:
apt install libpam-google-authenticator
google-authenticator
Bu bir secret (bir authenticator app için QR code olarak gösteriliyor) ve bir set backup code generate ediyor. Sonra SSH ve PAM'a bunu require etmesi söylenmesi gerekiyor:
# /etc/pam.d/sshd
auth required pam_google_authenticator.so
# /etc/ssh/sshd_config
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive önemli satır, ikisinden biri değil, key ve TOTP prompt'unun ikisini birden gerektiriyor. Bunu yanlış yapmak (örneğin default AuthenticationMethods'u unset bırakmak), her iki factor'ü de tek başına accept eden bir setup'la sonuçlanabilir, ki bu amacı tamamen yok ediyor, o yüzden ilk terminal'den logout olmadan önce bunu ikinci bir terminal'de test etmeye değer.
Nerede engel oluyor
Friction iki yerde ortaya çıkıyor. Birincisi, her interactive login artık bir telefon ya da authenticator app'e ihtiyaç duyuyor, ara sıra login'ler için büyük bir mesele değil, günde düzinelerce kez bir server'a SSH'lıyorsanız daha noticeable. İkincisi, ve daha önemlisi, automation bozuluyor. SSH üzerinden deploy eden bir CI/CD pipeline'ı, bir Ansible playbook'u, remote bir host'a rsync yapan bir cron job'ı, bunların hiçbirinde bir TOTP code yazacak bir insan yok. AuthenticationMethods publickey,keyboard-interactive'i server-wide apply etmek bunların hepsini aynı anda bozuyor, genelde bir sonraki scheduled job fail edene kadar obvious olmayan bir şekilde.
Gerçekte işe yarayan orta yol
Her yere 2FA yerine, kullandığım yaklaşım onu sadece interactive human login'lere apply etmek, automation ise ayrı, daha restricted service account'ları kullanıyor, 2FA requirement'ına subject olmayan, genelde çünkü bunlar da başka şekillerde restricted (authorized_keys'te bir forced command, ya da sadece bir spesifik script çalıştırabilen bir key):
# /etc/ssh/sshd_config
Match User deploy,admin
AuthenticationMethods publickey,keyboard-interactive
Match User ci-deploy
AuthenticationMethods publickey
Bu şekilde, bir insanın login olup arbitrary command'lar çalıştırmak için kullandığı account'lar extra factor'ü alıyor, narrowly-scoped automation account'ları ise, ki bunlar zaten gerçekçi olarak bir TOTP code sağlayamazdı, ve bir laptop'un compromise olması bunları direkt expose etmezdi (key'leri birinin laptop'unda değil, CI secret'larında yaşıyor), onsuz çalışmaya devam ediyor.
Nereye varıyorum
Sadece automation'ın eriştiği, hiç human interactive login'i olmayan bir server için, SSH 2FA çok bir şey eklemiyor, adresslediği threat (çalınmış, bir insanın elinde olan bir key) gerçekten apply olmuyor. İnsanların direkt login olduğu server'lar için, özellikle production data'ya access'i ya da change yapma yeteneği olanlar için, laptop-theft senaryosu, login'de bir TOTP prompt'u olan nispeten küçük ek friction'ın değdiği kadar gerçek, sadece o spesifik account'lara scope'lu kalması ve her şeyi ayakta tutan automation'ı sessizce bozmaması koşuluyla.