Linux sunucularda SSH anahtarı ile iki faktörlü kimlik doğrulama nasıl kurulur?

Dijital dönüşümün ve bulut bilişim altyapılarının hızla geliştiği günümüzde, sunucu güvenliği artık sadece bir tercih değil, mutlak bir zorunluluk haline gelmiştir. Özellikle kurumsal verilerin ve hassas sistemlerin barındığı Linux sunucular, siber saldırganların birincil hedefleri arasında yer almaktadır. Geleneksel şifre tabanlı giriş yöntemlerinin zayıflığı artık herkes tarafından bilinmektedir; ancak sadece SSH anahtarı (SSH Key) kullanmak da tek başına her senaryoda yeterli korumayı sağlamayabilir. Özel anahtarınızın (private key) çalınması, kaybolması veya yetkisiz kişilerin eline geçmesi durumunda sunucunuz tamamen savunmasız kalabilir. İşte bu noktada, siber güvenlik dünyasının en etkili savunma mekanizmalarından biri devreye girmektedir.

Peki, sunucu güvenliğimizi en üst düzeye çıkarmak için ne yapmalıyız? Bu rehberimizde, Linux sunucularda SSH anahtarı ile iki faktörlü kimlik doğrulama nasıl kurulur? sorusunun yanıtını en ince ayrıntılarına kadar ele alacağız. SSH anahtarı tabanlı kimlik doğrulama ile TOTP (Time-based One-Time Password - Zaman Tabanlı Tek Kullanımlık Şifre) protokolünü birleştirerek, sunucularınız için aşılması neredeyse imkansız çift katmanlı bir güvenlik duvarı oluşturacağız. Bu kurulum sayesinde, bir saldırgan SSH özel anahtarınızı ele geçirse bile, akıllı telefonunuzdaki kimlik doğrulama uygulaması tarafından üretilen anlık şifreye sahip olmadan sunucunuza erişim sağlayamayacaktır.

Bu makalede adım adım Ubuntu, Debian, Rocky Linux ve AlmaLinux gibi popüler dağıtımlarda Google PAM (Pluggable Authentication Modules) modülünü kullanarak iki faktörlü kimlik doğrulamayı (2FA) nasıl entegre edeceğinizi öğreneceksiniz. Kurulum esnasında sisteminizden kilitlenmemeniz için dikkat etmeniz gereken kritik güvenlik önlemlerini, yapılandırma dosyalarının detaylarını ve olası hata senaryolarını ele alacağız. Hazırsanız, Linux sunucunuzun güvenlik standartlarını profesyonel seviyeye taşıyacak rehberimize başlayalım.

SSH Anahtarı ve İki Faktörlü Kimlik Doğrulama (2FA) Nedir?

Sistem yöneticileri ve güvenlik uzmanları için sunucu erişim güvenliği, çok katmanlı bir savunma stratejisi gerektirir. Tek bir savunma hattına güvenmek, modern siber tehditler karşısında büyük bir risk barındırır. SSH anahtarları ve iki faktörlü kimlik doğrulama sistemleri, bu çok katmanlı yapının en güçlü iki bileşenidir.

SSH Anahtarı ile Kimlik Doğrulama Nasıl Çalışır?

SSH anahtarı ile kimlik doğrulama, asimetrik şifreleme algoritmasına dayanır. Bu sistemde bir adet "Açık Anahtar" (Public Key) ve bir adet "Özel Anahtar" (Private Key) bulunur. Açık anahtar sunucuya yüklenirken, özel anahtar kullanıcının yerel bilgisayarında güvenli bir şekilde saklanır. Sunucuya bağlanmak istediğinizde, sunucu yerel bilgisayarınızdaki özel anahtarı doğrulamak için kriptografik bir meydan okuma (challenge) gönderir. Bu yöntem, geleneksel şifrelere kıyasla kaba kuvvet (brute-force) saldırılarına karşı olağanüstü bir direnç gösterir. Ancak, yerel bilgisayarınızın hacklenmesi veya özel anahtar dosyanızın sızdırılması durumunda bu güvenlik hattı tamamen çöker.

İki Faktörlü Kimlik Doğrulama (2FA) Neden Gereklidir?

İki faktörlü kimlik doğrulama (2FA), kullanıcıların kimliklerini doğrulamak için iki farklı bileşeni sunmalarını gerektiren bir güvenlik sürecidir. Güvenlik teorisinde bu bileşenler üç ana kategoriye ayrılır: Bildiğiniz bir şey (şifre), sahip olduğunuz bir şey (telefon, güvenlik anahtarı) ve olduğunuz bir şey (biyometrik veri). Standart bir SSH anahtarı "sahip olduğunuz bir şey" kategorisine girer. Eğer bu anahtara bir de mobil cihazınızda anlık olarak üretilen ve sadece 30 saniye geçerli olan TOTP kodunu (sahip olduğunuz ikinci bir şey) eklerseniz, saldırganların her iki faktörü de aynı anda ele geçirmesi neredeyse imkansız hale gelir.

İki Yöntemin Birleşimi: SSH Key + TOTP Güvenlik Seviyesi

Linux sunucularda SSH anahtarı ile iki faktörlü kimlik doğrulama nasıl kurulur sorusunun temel amacı, bu iki güçlü yöntemi ardışık olarak çalıştırmaktır. Sistem, sizden önce geçerli bir SSH anahtarı sunmanızı ister. SSH anahtarı başarıyla doğrulandıktan sonra, sistem bağlantıyı hemen kabul etmek yerine sizden mobil uygulamanızdaki (Google Authenticator, Authy, Aegis vb.) 6 haneli kodu girmenizi talep eder. Bu sayede, siber güvenlik dünyasında "Defense in Depth" (Derinlemesine Savunma) olarak adlandırılan ve bir güvenlik katmanı aşılsa bile diğerinin sistemi korumaya devam ettiği yapı kurulmuş olur.

Kurulum Öncesi Hazırlıklar ve Gereksinimler

Sunucunuzda hassas sistem dosyalarını ve SSH yapılandırmasını değiştireceğimiz için, kuruluma başlamadan önce gerekli tüm hazırlıkları eksiksiz bir şekilde tamamlamanız hayati önem taşır. Yanlış yapılan tek bir satır ayar, sunucuyla olan bağlantınızın tamamen kopmasına ve sistemin dışına kilitlenmenize neden olabilir.

ÖNEMLİ UYARI: Bu rehberdeki adımları uygularken, mevcut SSH bağlantınızı kesinlikle kapatmayın. Tüm adımları tamamlayıp yeni bir terminal penceresinden başarılı bir şekilde giriş yaptığınızı doğrulamadan mevcut oturumu sonlandırmak, olası bir hata durumunda sunucuya bir daha erişememenize yol açabilir.

Hangi Linux Dağıtımları Destekleniyor?

Bu rehberde anlatılan yöntemler, modern Linux dağıtımlarının neredeyse tamamında geçerlidir. Özellikle aşağıdaki dağıtımlarda test edilmiş ve kararlı bir şekilde çalıştığı onaylanmıştır:

• Ubuntu (20.04 LTS, 22.04 LTS, 24.04 LTS ve üzeri)
• Debian (11 Bullseye, 12 Bookworm ve üzeri)
• Rocky Linux / AlmaLinux / CentOS Stream (8 ve 9 sürümleri)
• Fedora Server

Sudo Yetkilerine Sahip Kullanıcı Tanımlama

Güvenlik protokolleri gereği, sunucunuza doğrudan "root" kullanıcısı ile SSH bağlantısı gerçekleştirmek büyük bir güvenlik açığıdır. Bu nedenle, işlemlerimizi sudo yetkilerine sahip normal bir sistem kullanıcısı üzerinden gerçekleştireceğiz. Eğer sunucunuzda henüz böyle bir kullanıcı yoksa, kuruluma geçmeden önce yeni bir kullanıcı oluşturmalı ve bu kullanıcıya sudo yetkisi tanımlamalısınız.

SSH Anahtar Tabanlı Girişin Doğrulanması

2FA kurulumuna geçmeden önce, sunucunuza SSH anahtarı ile şifresiz olarak sorunsuz bir şekilde bağlanabildiğinizden emin olmalısınız. Eğer halihazırda şifre ile bağlanıyorsanız, öncelikle yerel bilgisayarınızda bir SSH anahtar çifti üretmeli ve bunu sunucunuza aktarmalısınız. Yerel bilgisayarınızda anahtar üretmek için:

ssh-keygen -t ed25519 -a 100

komutunu kullanabilirsiniz. Üretilen açık anahtarı sunucuya göndermek için ise:

ssh-copy-id kullanıcı_adı@sunucu_ip_adresi

komutunu çalıştırmanız yeterlidir. Bu aşamadan sonra sunucuya şifre girmeden, sadece SSH anahtarınızla erişebildiğinizi doğrulamalısınız.

Mobil Kimlik Doğrulama Uygulamasının Seçimi

Sunucu tarafından üretilecek QR kodu taratmak ve zaman tabanlı tek kullanımlık şifreleri (TOTP) üretmek için akıllı telefonunuza güvenilir bir kimlik doğrulama uygulaması yüklemelisiniz. Aşağıdaki uygulamalardan herhangi birini tercih edebilirsiniz:

• Google Authenticator (Android ve iOS için hızlı ve sade)
• Aegis Authenticator (Android için açık kaynaklı ve şifreli yedekleme destekli)
• Microsoft Authenticator (Bulut yedekleme desteği mevcut)
• Authy (Çoklu cihaz senkronizasyonu sunar)

Adım Adım Linux Sunucularda SSH Anahtarı ile İki Faktörlü Kimlik Doğrulama Kurulumu

Gerekli hazırlıkları tamamladığımıza göre, artık teknik kurulum aşamasına geçebiliriz. Bu bölümdeki adımları sırasıyla ve dikkatle uygulayınız. Komutlar ve dosya yolları dağıtımınıza göre küçük değişiklikler gösterebilir; bu durumlarda ilgili dağıtıma özel açıklamaları dikkate alınız.

Adım 1: Google Authenticator PAM Modülünün Kurulması

Linux sistemlerde iki faktörlü kimlik doğrulamayı yönetmek için Google tarafından geliştirilen açık kaynaklı PAM (Pluggable Authentication Modules) modülünü kullanacağız. İlk olarak sunucumuzdaki paket listelerini güncelliyor ve ilgili modülü yüklüyoruz.

Ubuntu ve Debian tabanlı sistemler için:

sudo apt update && sudo apt install libpam-google-authenticator -y

Rocky Linux, AlmaLinux ve RHEL tabanlı sistemler için:

Bu dağıtımlarda öncelikle EPEL (Extra Packages for Enterprise Linux) deposunun aktif edilmesi gerekmektedir:

sudo dnf install epel-release -y && sudo dnf install google-authenticator -y

Kurulum tamamlandıktan sonra, PAM modülü sistemimize entegre edilmeye hazır hale gelecektir.

Adım 2: Kullanıcı İçin 2FA Yapılandırmasının Çalıştırılması

Modülü yükledikten sonra, SSH ile bağlandığımız kullanıcı hesabında 2FA yapılandırma sihirbazını çalıştırmamız gerekiyor. Bu sihirbaz, kullanıcımıza özel gizli bir anahtar üretecek, bir QR kod gösterecek ve güvenlik tercihlerimizi belirlememizi sağlayacaktır.

google-authenticator

Bu komutu çalıştırdığınızda, karşınıza sırasıyla bazı sorular çıkacaktır. Bu sorulara vermeniz gereken yanıtlar ve açıklamaları şu şekildedir:

1. Do you want authentication tokens to be time-based (y/n): Bu soruya kesinlikle y (evet) yanıtını verin. Bu sayede zaman tabanlı (TOTP) jetonlar aktif hale gelecektir.
2. QR Kodunun ve Kodların Görüntülenmesi: Ekranda büyük bir QR kod belirecektir. Akıllı telefonunuzdaki kimlik doğrulama uygulamasını açın, yeni hesap ekleme seçeneğinden "QR Kodunu Tara" diyerek bu kodu taratın. Eğer terminalinizde QR kod düzgün görüntülenmiyorsa, QR kodun hemen altında yer alan "secret key" (gizli anahtar) değerini uygulamanıza manuel olarak girin.
3. Yedek Kodların Saklanması: QR kodun altında "Your emergency scratch codes are:" başlığıyla 5 adet 8 haneli sayı görüntülenecektir. Bu kodlar, telefonunuzu kaybetmeniz veya uygulamanın silinmesi durumunda sunucuya giriş yapabilmeniz için tek şansınızdır. Bunları güvenli, fiziksel bir kağıda veya şifreli bir parola yöneticisine not edin.
4. Do you want me to update your "/home/kullanici/.google_authenticator" file (y/n): Yapılandırmanın kaydedilmesi için bu soruya y yanıtını verin.
5. Do you want to disallow multiple uses of the same authentication token (y/n): Aynı kodun birden fazla kez kullanılmasını engellemek (replay attacks önlemek) için bu soruya y yanıtını verin.
6. Zaman Toleransı Sorusu (By default, tokens are valid for 30 seconds...): Sunucu saati ile telefonunuzun saati arasında küçük kaymalar olabileceği için zaman toleransını artırmak isteyip istemediğinizi sorar. Güvenliği maksimumda tutmak için bu soruya n (hayır) diyebilirsiniz. Eğer saat senkronizasyon sorunları yaşıyorsanız daha sonra y olarak değiştirebilirsiniz.
7. Do you want to enable rate-limiting (y/n): Kaba kuvvet saldırılarını önlemek amacıyla, 30 saniyede en fazla 3 giriş denemesine izin veren hız sınırlamasını aktif etmek için bu soruye y yanıtını verin.

Adım 3: PAM (Pluggable Authentication Modules) Yapılandırması

Google Authenticator yapılandırmasını tamamladık ancak Linux sistemi henüz SSH girişlerinde bu modülü kontrol etmesi gerektiğini bilmiyor. Şimdi PAM yapılandırma dosyasını düzenleyerek sisteme bu kuralı öğreteceğiz.

Favori metin editörünüzle (örneğin nano) SSH PAM yapılandırma dosyasını açın:

sudo nano /etc/pam.d/sshd

Dosyanın en üstüne veya uygun bir yerine aşağıdaki satırı ekleyin. Bu satır, sisteme SSH girişlerinde Google Authenticator modülünün zorunlu olduğunu bildirir:

auth required pam_google_authenticator.so

Eğer sunucunuzda bazı kullanıcıların 2FA kullanmasını, bazılarının ise sadece SSH anahtarı ile (2FA olmadan) girmesini istiyorsanız, satırı şu şekilde düzenleyebilirsiniz:

auth required pam_google_authenticator.so nullok

Not: "nullok" parametresi, henüz "google-authenticator" komutunu çalıştırmamış kullanıcıların 2FA kodu girmeden sadece SSH anahtarları veya şifreleri ile giriş yapabilmelerine izin verir. Tüm kullanıcılar yapılandırmayı tamamladıktan sonra güvenliği artırmak için "nullok" parametresini kaldırmanız önerilir.

Ayrıca, eğer mevcutsa şifre tabanlı kimlik doğrulamayı devre dışı bırakmak veya PAM kurallarını optimize etmek için aşağıdaki satırın başına # işareti koyarak yorum satırı haline getirebilirsiniz (isteğe bağlı, SSH yapılandırmasında da bunu engelleyeceğiz):

@include common-auth

Dosyayı kaydedip kapatın (Nano için: CTRL+O, Enter, CTRL+X).

Adım 4: SSH Daemon (sshd_config) Ayarlarının Düzenlenmesi

Şimdi SSH servisinin kendisini yapılandırmamız gerekiyor. SSH servisine hem SSH anahtarını hem de klavyeden girilecek etkileşimli kodu (2FA) aynı anda sormasını söyleyeceğiz.

SSH yapılandırma dosyasını açın:

sudo nano /etc/ssh/sshd_config

Dosya içerisinde aşağıdaki parametreleri bulun ve değerlerini belirtilen şekilde güncelleyin. Eğer bu parametreler dosyada yoksa, dosyanın en altına ekleyebilirsiniz:

• KbdInteractiveAuthentication yes (Eski Linux sürümlerinde bu parametre ChallengeResponseAuthentication yes olarak geçebilir. Her ikisini de kontrol edin ve "yes" yapın.)
• PubkeyAuthentication yes (SSH anahtarı kullanımını aktif tutar.)
• UsePAM yes (PAM modüllerinin SSH tarafından kullanılmasını sağlar.)

Şimdi en kritik adıma geldik. SSH servisine, kullanıcının sisteme girebilmesi için sırasıyla hangi adımları tamamlaması gerektiğini söyleyen AuthenticationMethods parametresini eklemeliyiz. Dosyanın en altına şu satırı ekleyin:

AuthenticationMethods publickey,keyboard-interactive

Bu satırın anlamı şudur: "Kullanıcı önce geçerli bir SSH genel anahtarı (publickey) sunmalıdır. Bu başarılı olursa, ardından klavye etkileşimli (keyboard-interactive) yani bizim durumumuzda Google Authenticator kodunu girmelidir."

Dosyayı kaydedip kapatın.

Adım 5: SSH Servisinin Yeniden Başlatılması ve Test Edilmesi

Yaptığımız değişikliklerin aktif olabilmesi için SSH servisini yeniden başlatmamız gerekir. Ancak unutmayın, mevcut terminal oturumunuzu kesinlikle kapatmıyorsunuz!

Ubuntu ve Debian sistemlerde SSH servisini yeniden başlatmak için:

sudo systemctl restart ssh

Rocky Linux, AlmaLinux ve RHEL sistemlerde SSH servisini yeniden başlatmak için:

sudo systemctl restart sshd

Servis sorunsuz bir şekilde yeniden başladıysa, şimdi yaptığımız yapılandırmayı test etme zamanı.

Mevcut terminalinizi açık bırakarak, bilgisayarınızdan yeni bir terminal penceresi açın ve sunucunuza bağlanmayı deneyin:

ssh kullanıcı_adı@sunucu_ip_adresi

Eğer her şeyi doğru yapılandırdıysanız, sistem sizden şifre istemeyecek, doğrudan SSH anahtarınızı doğrulayacak ve ardından terminalde şu şekilde bir uyarı gösterecektir:

Verification code:

Bu aşamada telefonunuzdaki kimlik doğrulama uygulamasını açın, sunucunuz için üretilen 6 haneli güncel kodu girin ve Enter tuşuna basın. Tebrikler! Sunucunuza SSH anahtarı ve iki faktörlü kimlik doğrulama ile başarıyla giriş yaptınız.

SSH ve PAM Yapılandırma Parametrelerinin Karşılaştırılması

Farklı kimlik doğrulama kombinasyonlarının sunucu güvenliğine ve kullanıcı deneyimine olan etkilerini daha iyi analiz edebilmeniz için aşağıdaki karşılaştırma tablosunu hazırladık. Bu tablo, projenizin ihtiyaçlarına göre en doğru güvenlik politikasını belirlemenize yardımcı olacaktır.

Güvenlik Duvarı ve Gelişmiş SSH Sıkılaştırma İpuçları

Linux sunucularda SSH anahtarı ile iki faktörlü kimlik doğrulama nasıl kurulur sorusunu yanıtladıktan sonra, sunucu güvenliğinizi bir üst seviyeye taşıyacak tamamlayıcı önlemleri de almanız gerekir. Güvenlik, tek bir ayarla biten bir süreç değil, sürekli geliştirilmesi gereken bir bütündür.

SSH Portunu Değiştirmek Güvenli mi?

Varsayılan olarak SSH servisi 22 numaralı port üzerinden çalışır. İnternet üzerindeki botlar, sürekli olarak IP adreslerini tarayarak 22. portu açık olan sunuculara kaba kuvvet saldırıları düzenler. SSH portunu örneğin 2244 gibi rastgele bir porta taşımak, bu otomatik bot taramalarının %99'undan kurtulmanızı sağlar. Ancak unutmayın, bu bir "gizleme yoluyla güvenlik" (security through obscurity) yöntemidir ve gerçek bir güvenlik açığını kapatmaz, sadece gürültüyü azaltır. Port değiştirmek için `/etc/ssh/sshd_config` dosyasındaki `Port 22` satırını düzenleyebilirsiniz.

IP Kısıtlaması ile Erişim Kontrolü

Eğer sunucunuza sadece belirli bir ofis IP'sinden veya VPN üzerinden erişilmesi gerekiyorsa, güvenlik duvarı (firewall) kuralları ile SSH portuna erişimi sadece bu IP adreslerine izin verecek şekilde kısıtlayabilirsiniz. Örneğin Ubuntu üzerinde UFW kullanarak sadece belirli bir IP'ye izin vermek için:

sudo ufw allow from 192.168.1.100 to any port 22 proto tcp

komutunu kullanabilirsiniz. Bu, sızma girişimlerini ağ düzeyinde engelleyen en etkili yöntemlerden biridir.

Fail2ban ile Kaba Kuvvet Saldırılarını Engelleme

Fail2ban, sunucu log dosyalarını (örneğin `/var/log/auth.log`) sürekli tarayarak, belirli bir süre içinde çok sayıda hatalı giriş denemesi yapan IP adreslerini güvenlik duvarı (iptables/ufw) seviyesinde geçici veya kalıcı olarak engeller. SSH anahtarı ve 2FA kurulumunuzun yanına Fail2ban entegre etmek, hatalı 2FA kodu girerek sistemi meşgul eden kötü niyetli aktörleri otomatik olarak sistemden uzaklaştıracaktır.

Olası Sorunlar ve Çözüm Yolları (Troubleshooting)

Sistem yöneticiliğinde en tecrübeli uzmanlar bile bazen küçük detayları gözden kaçırabilir. SSH ve PAM yapılandırmaları doğrudan kimlik doğrulama katmanını etkilediği için, en ufak bir hata sunucuya erişiminizi engelleyebilir. İşte en sık karşılaşılan sorunlar ve bunların profesyonel çözüm yolları.

Sunucuya Erişim Kaybedilirse Ne Yapılmalı?

Eğer yapılandırmada bir hata yaptıysanız ve yeni bir terminalden bağlanmaya çalışırken hata alıyorsanız, mevcut açık olan terminal oturumunuzu kesinlikle kapatmayın. Açık olan oturum üzerinden hemen hata loglarını inceleyin:

sudo tail -f /var/log/auth.log (Debian/Ubuntu için)

sudo tail -f /var/log/secure (RHEL/Rocky Linux için)

Eğer mevcut oturumu çoktan kapattıysanız ve sunucuya hiçbir şekilde erişemiyorsanız, şu alternatif yolları denemelisiniz:

• Bulut Sağlayıcı Konsolu: AWS, DigitalOcean, Linode veya Hetzner gibi bulut sağlayıcılarının web panellerinde sunduğu "VNC Console" veya "Serial Console" özelliğini kullanarak sunucuya doğrudan tarayıcı üzerinden erişebilir ve hatalı yapılandırmayı geri alabilirsiniz.
• Kurtarma Modu (Rescue Mode): Sunucuyu kurtarma modunda başlatarak diskleri bağlayabilir (mount) ve `/etc/ssh/sshd_config` ile `/etc/pam.d/sshd` dosyalarını eski haline getirebilirsiniz.

"Permission Denied (publickey,keyboard-interactive)" Hatası

Bu hata genellikle SSH daemon'ın (sshd) yapılandırma dosyasındaki parametreleri doğru yorumlayamadığı durumlarda meydana gelir. Çözüm için şu adımları kontrol edin:

1. `/etc/ssh/sshd_config` dosyasında `KbdInteractiveAuthentication yes` satırının aktif olduğundan emin olun.
2. `AuthenticationMethods publickey,keyboard-interactive` satırında virgül işaretinden sonra boşluk olup olmadığını kontrol edin. Bazı SSH sürümleri boşluk karakterine karşı duyarlıdır.
3. Dosya izinlerini kontrol edin. Kullanıcının ev dizinindeki `.google_authenticator` dosyasının izinleri sadece o kullanıcıya ait olmalıdır: chmod 600 ~/.google_authenticator

Saat Senkronizasyonu Sorunları ve TOTP Hataları

Zaman tabanlı tek kullanımlık şifreler (TOTP), sunucu saati ile mobil cihazınızın saatinin mükemmel bir şekilde senkronize olmasına dayanır. Eğer sunucunuzun saati birkaç dakika bile geri veya ileri ise, ürettiğiniz 2FA kodları sunucu tarafından reddedilecektir. Bu sorunu çözmek için sunucunuzda NTP (Network Time Protocol) servisini aktif etmelisiniz:

sudo systemctl restart systemd-timesyncd

Sunucu saatini manuel olarak doğrulamak için `date` komutunu kullanabilir ve telefonunuzun dünya saatiyle eşleştiğinden emin olabilirsiniz.

Yedek Kodların (Scratch Codes) Güvenli Saklanması

Telefonunuzun bozulması, çalınması veya sıfırlanması durumunda 2FA kodlarına erişemezsiniz. `google-authenticator` kurulumu esnasında size verilen 5 adet acil durum yedek kodunu (scratch codes) mutlaka güvenli bir yerde saklamalısınız. Bu kodların her biri tek kullanımlıktır ve "Verification code" kısmına girildiğinde doğrudan sisteme erişmenizi sağlar. Bu kodları dijital ortamda saklayacaksanız, şifreli bir KeePass veritabanında veya Bitwarden gibi güvenli bir parola yöneticisinde barındırmanız önerilir.

Sıkça Sorulan Sorular

SSH anahtarı kaybolursa 2FA kodu ile giriş yapabilir miyim?

Hayır, yapamazsınız. Yapılandırdığımız `AuthenticationMethods publickey,keyboard-interactive` kuralı gereği, sisteme giriş yapabilmek için hem geçerli bir SSH anahtarına hem de 2FA koduna aynı anda sahip olmanız gerekir. Biri olmadan diğeri tek başına geçersizdir. Bu durum, sunucu güvenliğini maksimuma çıkaran temel unsurdur.

Her SSH bağlantisinde 2FA kodu girmek zorunda mıyım?

Evet, varsayılan yapılandırmada her yeni SSH oturumu açtığınızda sistem sizden güncel 2FA kodunu talep edecektir. Ancak sık sık bağlantı kuruyorsanız, SSH'ın "ControlMaster" özelliğini yerel bilgisayarınızda aktif ederek mevcut bağlantı üzerinden tünelleme yapabilir ve her seferinde kod girmek zorunda kalmadan hızlıca yeni sekmeler açabilirsiniz.

Sunucuda birden fazla kullanıcı varsa hepsine 2FA zorunlu kılınabilir mi?

Evet, kılınabilir. `/etc/pam.d/sshd` dosyasındaki `pam_google_authenticator.so` satırının sonundaki `nullok` parametresini kaldırırsanız, sunucudaki tüm kullanıcılar için 2FA zorunlu hale gelir. Bu durumda, henüz `google-authenticator` kurulumu yapmamış olan kullanıcılar sunucuya kesinlikle giriş yapamazlar.

Ansible veya SFTP gibi otomasyon araçları 2FA'dan nasıl etkilenir?

Ansible, rsync, SFTP gibi otomatik araçlar ve scriptler etkileşimli olarak kod giremedikleri için 2FA yapılandırmasından sonra sunucuya bağlanamazlar. Bu sorunu çözmek için otomasyon kullanıcılarını 2FA zorunluluğundan muaf tutabilir veya bu servisler için sadece SSH anahtarı gerektiren özel SSH portları/kuralları tanımlayabilirsiniz.

Google Authenticator yerine fiziksel bir güvenlik anahtarı (YubiKey) kullanabilir miyim?

Evet, kullanabilirsiniz. YubiKey gibi fiziksel güvenlik anahtarları FIDO2/U2F protokollerini destekler. SSH, modern sürümlerinde doğrudan `ecdsa-sk` veya `ed25519-sk` anahtar tipleri aracılığıyla donanımsal güvenlik anahtarlarını desteklemektedir. Bu yöntem, mobil uygulama tabanlı TOTP çözümlerine göre daha da yüksek bir güvenlik seviyesi sunar.

Sonuç

Linux sunucularınızın güvenliğini sadece şifrelere veya tek başına SSH anahtarlarına emanet etmek, günümüz siber tehdit dünyasında büyük bir risk barındırmaktadır. Bu kapsamlı rehberimizde, Linux sunucularda SSH anahtarı ile iki faktörlü kimlik doğrulama nasıl kurulur? sorusunu tüm teknik detayları, yapılandırma aşamaları ve güvenlik ipuçları ile birlikte yanıtladık.

SSH anahtar tabanlı kimlik doğrulama ile zaman tabanlı tek kullanımlık şifre (TOTP) protokolünü birleştirmek, sunucularınızı kaba kuvvet saldırılarına, kimlik avı girişimlerine ve özel anahtar hırsızlıklarına karşı koruma altına alır. Kurulum esnasında aldığınız yedek kodları güvenli bir yerde saklamayı, sistem saatini her zaman senkronize tutmayı ve en önemlisi yeni yapılandırmayı test ederken mevcut SSH oturumunuzu kapatmamayı unutmayın. Güvenli ve kesintisiz çalışmalar dileriz.

Alternatif İki Faktörlü Kimlik Doğrulama Yöntemleri ve Protokolleri

Linux sunucu güvenliğinde iki faktörlü kimlik doğrulama (2FA) denildiğinde akla ilk gelen yöntem Google Authenticator ve benzeri uygulamalarla entegre çalışan TOTP (Time-Based One-Time Password) protokolüdür. Ancak kurumsal altyapılarda ve yüksek güvenlik gerektiren sistemlerde, operasyonel ihtiyaçlara göre farklı protokoller ve kimlik doğrulama yöntemleri de tercih edilmektedir. Sunucunuzun erişim modeline en uygun yöntemi seçebilmek için bu protokollerin çalışma mantığını anlamak kritik önem taşır.

Zaman Tabanlı (TOTP) ve Sayaç Tabanlı (HOTP) Algoritmalar Arasındaki Farklar

İki faktörlü kimlik doğrulamada kullanılan tek kullanımlık şifre (OTP) sistemleri temelde iki farklı matematiksel algoritmaya dayanır:

• TOTP (RFC 6238): Zaman tabanlı tek kullanımlık şifre algoritmasıdır. Sunucu ve istemci (mobil uygulama) arasında paylaşılan gizli bir anahtar (secret key) ile o anki zaman dilimini (genellikle 30 saniyelik pencereler) girdi olarak kullanır. Zaman senkronizasyonu mükemmel olmak zorundadır. İnternet bağlantısı gerektirmeden çalışır ve her 30 saniyede bir yeni kod üretir.
• HOTP (RFC 4226): Sayaç tabanlı tek kullanımlık şifre algoritmasıdır. Zaman yerine, her başarılı kimlik doğrulamada ve her yeni kod üretiminde bir artan "sayaç" değerini temel alır. Kullanıcı uygulamada butona bastığında sayaç artar ve yeni kod üretilir. Sunucu, istemcinin sayacı ile kendi sayacını karşılaştırır. Zaman senkronizasyonu sorunu yaşamaz ancak kullanıcının sunucuya bağlanmadan uygulamada ardışık olarak çok fazla kod üretmesi durumunda senkronizasyon kayması (desynchronization) yaşanabilir.

Modern Linux sunucu yönetiminde, zaman senkronizasyonunun kolayca yönetilebilmesi ve daha yüksek güvenlik sunması nedeniyle TOTP standardı ezici bir üstünlüğe sahiptir.

Kurulum Sürecinde En Sık Yapılan Kritik Hatalar

SSH ve PAM (Pluggable Authentication Modules) yapılandırması, en ufak bir syntax (sözdizimi) hatasında veya mantık hatasında sistem yöneticilerinin sunucu dışı kalmasına (lockout) neden olabilecek hassas bileşenlerdir. Kurulum sırasında en sık karşılaşılan hataları bilmek, olası kesintilerin önüne geçer.

PAM Yapılandırma Sırasının Yanlış Belirlenmesi

Linux PAM sistemi, kuralları yukarıdan aşağıya doğru sırayla işler. /etc/pam.d/sshd dosyası içerisine eklenen satırların sırası, kimlik doğrulama akışını doğrudan etkiler. Örneğin, eğer sisteminizde hem şifre hem SSH anahtarı hem de 2FA kullanmak istiyorsanız, PAM kurallarının sırasını yanlış yapılandırmak 2FA adımının tamamen atlanmasına veya tam tersine SSH anahtarı sunulsa bile kullanıcının şifre girmeye zorlanmasına neden olabilir.

Önemli Kural: PAM yapılandırmasında auth required pam_google_authenticator.so satırının konumu, sistemin diğer kimlik doğrulama modülleriyle (örneğin pam_unix.so veya sss/LDAP entegrasyonları) nasıl etkileşime gireceğini belirler. Eğer SSH anahtarı ile girişi zorunlu kılıp şifreyi devre dışı bırakmak istiyorsanız, PAM dosyasındaki standart şifre sorgulama satırlarını (@include common-auth gibi) dikkatli bir şekilde yönetmeniz gerekir.

Kullanıcı İzinleri ve .google_authenticator Dosya Sahipliği

Google Authenticator yapılandırması çalıştırıldığında, kullanıcının ev dizininde (home directory) .google_authenticator adında gizli bir dosya oluşturulur. Bu dosya, TOTP gizli anahtarını, acil durum yedek kodlarını ve yapılandırma parametrelerini içerir. Bu dosya ile ilgili yapılan en yaygın hatalar şunlardır:

• Yanlış İzinler: Dosyanın izinleri kesinlikle 0400 veya 0600 olmalıdır. Eğer dosya diğer kullanıcılar tarafından okunabilir durumdaysa (örneğin 0644), PAM modülü güvenlik gerekçesiyle bu dosyayı okumayı reddeder ve SSH bağlantısı başarısız olur.
• Yanlış Dosya Sahipliği: Eğer yapılandırma komutunu yanlışlıkla sudo google-authenticator şeklinde root yetkileriyle çalıştırdıysanız, dosyanın sahibi root olacaktır. Standart kullanıcı kendi ev dizinindeki bu dosyayı okuyamayacağı için SSH bağlantısı sırasında 2FA kodu doğrulanamayacak ve erişim engellenecektir.

Farklı Kullanıcı Grupları İçin Özel SSH ve 2FA Senaryoları

Her sunucu altyapısında tüm kullanıcıların aynı erişim politikalarına tabi olması beklenemez. Örneğin, sistem yöneticilerinin 2FA kullanması zorunluyken, sadece belirli bir IP adresinden bağlanan otomasyon servislerinin veya yedekleme betiklerinin bu adımdan muaf tutulması gerekebilir.

Sadece Belirli IP Adreslerine 2FA Muafiyeti Tanımlama

Şirket içi güvenli ağlardan (VPN veya ofis IP'si) gelen bağlantılarda 2FA adımını atlamak, dış dünyadan gelen bağlantılarda ise zorunlu kılmak için SSH daemon yapılandırma dosyasında (/etc/ssh/sshd_config) Match blokları kullanılabilir. Aşağıdaki örnek yapılandırma, belirli bir alt ağ dışındaki tüm bağlantılar için SSH anahtarı ve 2FA kombinasyonunu zorunlu kılmaktadır:

# Genel Kurallar (Tüm bağlantılar için 2FA zorunlu)
AuthenticationMethods publickey,keyboard-interactive

# Güvenli Ağ İçin İstisna Tanımlama
Match Address 192.168.10.0/24,10.0.0.5
    AuthenticationMethods publickey

Bu yapılandırma sayesinde, 192.168.10.0/24 ağından veya 10.0.0.5 IP adresinden gelen kullanıcılar sadece SSH anahtarları ile sisteme giriş yapabilirken, bu IP adresleri dışından gelen herkes hem SSH anahtarını sunmak hem de mobil uygulamalarındaki TOTP kodunu girmek zorundadır.

Yönetici (Admin) ve Standart Kullanıcılar İçin Ayrı Politika Belirleme

Sunucuda bulunan bazı kritik kullanıcıların (örneğin root veya admin grubuna dahil kullanıcılar) mutlaka çok faktörlü kimlik doğrulama kullanmasını isterken, kısıtlı yetkilere sahip standart kullanıcıların sadece SSH anahtarı ile bağlanmasını isteyebilirsiniz. Bunu gerçekleştirmek için yine Match Group veya Match User direktiflerinden yararlanabilirsiniz:

# Standart kullanıcılar için sadece SSH anahtarı yeterli
AuthenticationMethods publickey

# Yönetici grubuna dahil kullanıcılar için SSH anahtarı + 2FA zorunlu
Match Group wheel,sudo,admin
    AuthenticationMethods publickey,keyboard-interactive

Güvenlik Denetimi: 2FA Loglarının Analiz Edilmesi ve İzlenmesi

İki faktörlü kimlik doğrulama sisteminin kurulması tek başına yeterli değildir; bu sistemin ürettiği logların düzenli olarak analiz edilmesi ve şüpheli aktivitelerin izlenmesi gerekir. Başarısız 2FA denemeleri, bir saldırganın SSH özel anahtarınızı ele geçirdiğini ancak ikinci aşamayı geçemediğini gösteren çok önemli bir erken uyarı sinyalidir.

Başarısız 2FA Girişimlerinin Log Kayıtlarından Tespiti

Debian ve Ubuntu tabanlı sistemlerde SSH ve PAM logları /var/log/auth.log dosyasında tutulurken, RHEL, CentOS ve Rocky Linux sistemlerinde bu kayıtlar /var/log/secure dosyasında saklanır. Başarısız 2FA denemelerini filtrelemek için aşağıdaki komutları kullanabilirsiniz:

Debian/Ubuntu sistemlerde başarısız denemeleri izlemek için:

grep "google-authenticator" /var/log/auth.log

RHEL/Rocky Linux sistemlerde başarısız denemeleri izlemek için:

grep "google-authenticator" /var/log/secure

Eğer loglarda "Invalid verification code" veya "code-changing too fast" gibi uyarılar görüyorsanız, bu durum bir brute-force (kaba kuvvet) saldırısına veya kullanıcının cihazındaki saat senkronizasyonu problemine işaret ediyor olabilir.

SSH ve 2FA Güvenlik Seviyelerinin Karşılaştırma Matrisi

Farklı kimlik doğrulama yöntemlerinin sunduğu güvenlik seviyelerini ve operasyonel karmaşıklıklarını anlamak, doğru stratejiyi belirlemenize yardımcı olur. Aşağıdaki tablo, yaygın olarak kullanılan yöntemlerin avantaj ve dezavantajlarını karşılaştırmaktadır:

Tablodan da anlaşılacağı üzere, SSH anahtarı ile TOTP (MFA) kombinasyonu, ek bir donanım maliyetine katlanmadan elde edilebilecek en yüksek yazılımsal güvenlik seviyesini sunmaktadır. Ancak en üst düzey fiziksel ve kriptografik koruma için donanımsal güvenlik anahtarlarının entegrasyonu da değerlendirilebilir.

Donanımsal Güvenlik Anahtarları ve FIDO2 Protokolü

Mobil uygulamalar üzerinden üretilen TOTP kodları, yüksek güvenlik sunsa da kullanıcının telefonuna zararlı yazılım bulaşması veya SIM kart kopyalama (SIM swapping) gibi gelişmiş saldırı vektörlerine karşı tamamen bağışık değildir. Bu gibi durumlar için donanımsal güvenlik anahtarları devreye girmektedir. Bu cihazlar, kriptografik anahtarları güvenli bir çip içerisinde saklayarak kimlik doğrulama işlemini tamamen donanımsal düzeyde gerçekleştirirler. SSH bağlantılarınızı bu donanımlarla entegre ederek, güvenliğinizi en üst seviyeye çıkar