SSH üzerinden parola kimlik doğrulaması, sıradan bir sunucunun sahip olduğu en büyük açık yüzeydir. Ona karşı ne Fail2ban ne de herhangi bir eşik yardımcı olur: saatte bir denemeyle bin adres hiçbir zaman bir sınıra ulaşmaz ve tahmin etmek mümkün olduğu sürece tahmin etmeye devam ederler. Anahtarlar bu olasılığın kendisini ortadan kaldırır ve bütün sertleştirme listesi içinde durumu niteliksel olarak değiştiren tek ayar budur.

Bu konuda korkutucu olan tek bir şey vardır: parolayı kapatıp dışarıda kalmak. İşte bunun olamayacağı sıra.

Anahtar

Sunucuda değil, kendi makinenizde üretilir:

ssh-keygen -t ed25519 -C "work laptop"

RSA yerine ed25519: daha kısa, daha hızlı ve uzunlukla ilgili soru yok. RSA yalnızca çok eski bir şeye erişmeniz gerekiyorsa gerekir; o zaman -t rsa -b 4096.

Anahtara bir parola ifadesi koymaya değer: anahtar dosyası bir dizüstünden çalınabilir ve parola ifadesi olmadan hemen çalışır. Her seferinde yazmak zorunda kalmazsınız — bunu ssh-agent halleder ve macOS ile çoğu masaüstü Linux sisteminde zaten çalışır durumdadır.

Parola hâlâ çalışırken sunucuya kopyalamak tek bir komut sürer:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

ssh-copy-id yoksa .pub dosyasının içeriği, sunucuda ~/.ssh/authorized_keys dosyasına bir satır olarak eklenir. İzinler önemlidir: .ssh dizini 700, dosya 600, sahibi kullanıcı. Başka bir şeyle sshd dosyayı okumayı sessizce reddeder ve bu, «anahtar çalışmıyor» durumunun en sık görülen nedenidir.

İşi bitiren kontrol

Hiçbir şeyi kapatmadan önce, birincisini kapatmadan ikinci bir bağlantı açın:

ssh -o PasswordAuthentication=no user@203.0.113.25

Bu seçenek istemcinin parolaya geri dönmesini yasaklar — yani oturum açma başarılıysa, anahtarla başarılı olmuştur. Bu komut çalışana kadar ilerlemeyin. Ve ilk bağlantıyı sonuna kadar açık tutun: bozmayı başardığınız her şeyi düzelten odur.

Parolaları kapatmak ve apaçık olmayan bir engel

Ayarlar, bir paket güncellemesi üzerlerine yazamasın diye ayrı bir dosyaya konur. Ama dosya adı önemlidir:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Mesele şu ki OpenSSH, neredeyse her yerde olduğu gibi sonuncuyu değil, bir parametre için elde ettiği ilk değeri kullanır. sshd_config.d içindeki dosyalar alfabetik sırayla okunur ve Ubuntu bulut imajları oraya, sıklıkla PasswordAuthentication yes içeren 50-cloud-init.conf dosyasını koyar. 90 numaralı dosyanız bu durumda hiçbir şey yapmaz: ayar yerinde görünürken parola çalışmaya devam eder. 10 sayısının nedeni budur — daha önce okunur.

Gerçekte ne çıktığını tahmin etmeden görebilirsiniz:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Bu komut, bütün include’lardan sonraki etkin yapılandırmayı yazdırır. Dosyaların içeriğine değil, ona güvenin.

Ardından bir sözdizimi kontrolü ve servisin nazikçe yeniden yüklenmesi:

sudo sshd -t && sudo systemctl reload ssh

sshd -t zorunludur: yapılandırmadaki bir yazım hatası restart ile birlikte servisi kapalı, sizi de dışarıda bırakır. reload ayrıca açık oturumları bozmaz.

Ubuntu 24.04: port sandığınız yerde değil

Güncel Ubuntu’da ayrı bir tuzak: sshd orada bir systemd soketi üzerinden başlatılır. Bu kipte sshd_config içindeki Port satırı hiçbir şey yapmaz — daemon değil, soket dinler. Portu değiştiriyorsanız düzenlenmesi gereken şey budur:

sudo systemctl edit ssh.socket

ve ListenStream= (boş bir değer öncekini sıfırlar) yeni portu belirtmelidir. Bunu ele veren belirti: yapılandırma değişti, servis yeniden başlatıldı ve sunucu hâlâ 22’den yanıt veriyor.

Port değiştirmekten söz açılmışken: koruma olarak işe yaramaz — tarayıcılar bir servisi herhangi bir portta dakikalar içinde bulur. Tek etkisi daha sessiz günlüklerdir, çünkü toplu tahmin yalnızca 22’ye gider. Bu kullanışlıdır, ama onu güvenlikle karıştırmayın.

Kim oturum açabilir

Faydalı bir ekleme açık bir listedir:

AllowUsers deploy admin

Listede olmayan her şey, anahtar bile kontrol edilmeden kesilir. Bu ayrıca bir paketin kabuğu ve ev dizini olan bir sistem kullanıcısı oluşturduğu durumu da kapsar.

Yedek bir giriş yolu

Bir dizüstünde bir anahtar, tek bir arıza noktasıdır. Disk ölür, dizüstü kaybolur ve sunucu temelli olarak erişilemez hale gelir. Makul bir asgari:

  • authorized_keys içinde başka bir cihazdan ikinci bir anahtar;
  • özel anahtarın bir parola yöneticisinde ya da şifreli bir bellekte kopyası;
  • sağlayıcınızda test edilmiş konsol erişimi — VNC ya da seri. Test edilmiş demek, «panelde bir yerde bir düğme var» değil, en az bir kez oradan oturum açmış olmanız demektir.

Hazır oradayken authorized_keys içinde zaten ne olduğuna bakın — hem kendi kullanıcınızınkine hem de root’unkine. Oradaki başkasına ait bir anahtar her parola değişikliğinden sağ çıkar ve çalışan bir erişim olarak kalır.

Sonrasında

Parola tahmini ortadan kalkmaz, yalnızca işe yaramaz hale gelir: günlüklerde binlerce Failed password satırı birikmeye devam eder ve hiçbiri başarıyla bitemez. Şimdi izlemeye değen şey başarılı oturum açmalardır: hangi adresten, hangi kullanıcıyla, hangi saatte. Tanınmayan bir adresten anahtarla yapılan başarılı bir oturum açma, bir milyon başarısızlıktan çok daha önemli bir olaydır ve genel akış içinde fark etmesi çok daha zordur. Aşağıdaki demo sayfası tam da bu görüntüyü verir.