SSH anahtarları: sunucuya parolasız giriş kurulumu

SSH anahtarı bir çift dosyadır: özel anahtar (private key) sizde kalır, genel anahtar (public key) sunucuya konur. Bağlanırken sunucu, genel anahtarlardan birine karşılık gelen özel anahtarın sizde olduğunu doğrular ve sizi parolasız içeri alır. Bu, parolaya göre hem daha rahat hem de çok daha güvenlidir: anahtarı kaba kuvvetle kırmak neredeyse imkânsızdır. Aşağıda anahtar oluşturmadan parola girişini kapatmaya kadar SSH anahtarı kurulumu ve insanların en çok takıldığı hatalar anlatılıyor.

Anahtar kimlik doğrulaması nasıl çalışır

Anahtarlar asimetriktir. Genel anahtar (id_ed25519.pub) herkese gösterilebilir; ondan özel anahtar yeniden üretilemez. Özel anahtar (id_ed25519) makinenizden asla çıkmaz ve ağda gönderilmez.

Bağlanırken istemci sunucuya hangi anahtarla girmek istediğini bildirir. Sunucu o genel anahtarı kullanıcının ~/.ssh/authorized_keys dosyasında arar; bulursa istemciden oturum verisini özel anahtarla imzalamasını ister. İmza genel anahtarla doğrulanır ve giriş onaylanır. Bu süreçte parola hiç gönderilmez.

Adım 1. Anahtar oluşturun: ssh-keygen

Kendi bilgisayarınızda (Linux, macOS veya yerleşik OpenSSH'li Windows 10/11) çalıştırın:

ssh-keygen -t ed25519 -C "alena@laptop"

-t algoritmayı, -C ise genel anahtarın sonuna eklenen ve anahtarın kime ait olduğunu hatırlatan yorumu belirler. Ed25519 günümüzün önerilen algoritmasıdır: anahtarlar kısa, hızlı ve güvenilirdir. Sunucu çok eskiyse ve Ed25519 desteklemiyorsa en az 3072 bitlik RSA kullanın: ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

Parola ifadesi gerekli mi

Passphrase, özel anahtarı diskte şifreler. Dizüstü bilgisayarınız çalınırsa ya da dosya sızarsa, parola olmadan anahtar işe yaramaz hâle gelir. Kişisel anahtarlarınıza parola koyun; her bağlantıda tekrar yazmamak için ssh-agent kullanın: oturum boyunca açılmış anahtarı bellekte tutar.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # yüklü anahtarların listesi

Parolasız anahtarlar otomasyon için uygundur, örneğin CI veya yedekleme betikleri için. Böyle bir anahtarı sunucuda kısıtlamanız (aşağıda anlatılır) daha iyidir.

Adım 2. Genel anahtarı sunucuya gönderin: ssh-copy-id

En kolay yol ssh-copy-id'dir. Parolayla bir kez bağlanır, genel anahtarınızı sunucudaki ~/.ssh/authorized_keys dosyasına ekler ve doğru izinleri ayarlar.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Sunucu standart dışı bir portta dinliyorsa -p 2222 ekleyin.

ssh-copy-id yoksa

Windows'ta ssh-copy-id bulunmaz. Anahtarı tek bir komutla elle gönderebilirsiniz:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Bulut sağlayıcıları genellikle genel anahtarı sunucuyu oluştururken ister; anahtar cloud-init aracılığıyla authorized_keys dosyasına yazılır.

Adım 3. Girişi doğrulayın

ssh deploy@203.0.113.10

Parola artık sorulmuyorsa (ya da yalnızca anahtarın parolası soruluyorsa), her şey yolunda demektir. Yeni bir sunucuya ilk kez bağlanırken SSH, sunucunun anahtar parmak izini gösterir ve ona güvenip güvenmediğinizi sorar. yes dediğinizde parmak izi ~/.ssh/known_hosts dosyasına kaydedilir; sonradan sunucunun anahtarı değişirse SSH uyarır.

İstemcinin hangi anahtarları denediğini ve sunucunun neden reddettiğini görmek için bağlantıyı ayrıntılı modda çalıştırın:

ssh -v deploy@203.0.113.10

~/.ssh/config: sunucular için kısa adlar

Birden fazla sunucunuz varsa her seferinde kullanıcı, IP, port ve anahtar yolunu yazmak yorucudur. Bunların hepsi ~/.ssh/config dosyasına yazılır:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-internal
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Artık ssh prod yeterli; scp, rsync ve Git de bu adları anlar: rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes — yalnızca belirtilen anahtarı kullanır. Bu satır olmazsa istemci aracının tüm anahtarlarını dener ve sunucu deneme sınırına ulaşınca doğru anahtara gelmeden bağlantıyı kesebilir.
• ProxyJump — ara sunucu (bastion) üzerinden iç ağdaki bir sunucuya tek komutla bağlanmak.
• ServerAliveInterval — her 60 saniyede bir «canlılık» paketi göndererek boşta kalınca bağlantının kopmasını önler.

Dosyanın izni 600 olmalıdır, yoksa SSH onu okumayı reddedebilir: chmod 600 ~/.ssh/config.

Agent forwarding: ne zaman gerekir ve neden tehlikelidir

Bazen sunucudan öteye bağlanmanız gerekir, örneğin özel bir depodan git pull yapmak için. Özel anahtarı oraya kopyalamak yanlıştır. Bunun yerine ssh -A veya ForwardAgent yes kullanılır: sunucu, oturum süresince sizin ajanınıza erişir. Ancak o sunucuda root yetkisi olan herkes, siz bağlıyken ajanı kullanabilir. Bu yüzden yönlendirmeyi yalnızca güvendiğiniz sunucularda açın; ara sunucudan geçmek için ajanı açmayan ProxyJump'ı tercih edin.

Adım 4. Parola girişini kapatın

Parolayla giriş açık kaldığı sürece sunucu kaba kuvvet saldırılarının hedefi olur. Anahtarla girdiğinizi doğruladıktan sonra parolayı kapatın. Önemli: yeni bir pencerede girişi denemeden mevcut oturumunuzu kapatmayın, yoksa erişimi kaybedebilirsiniz.

/etc/ssh/sshd_config dosyasını açın (ya da ana yapılandırma Include ile /etc/ssh/sshd_config.d/ dizinini okuyorsa oraya bir dosya ekleyin) ve şunları yazın:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no, root olarak girişi tamamen yasaklar: yöneticiler kendi kullanıcılarıyla girer ve sudo ile yetki yükseltir. Root olmadan olmuyorsa, root'un yalnızca anahtarla girmesine izin veren PermitRootLogin prohibit-password kullanın.

Sözdizimini kontrol edip servisi yeniden yükleyin:

sudo sshd -t
sudo systemctl reload ssh      # Debian/Ubuntu'da; RHEL türevlerinde — sshd

sshd -t yapılandırma doğruysa sessiz kalır. Şimdi yeni bir terminalde anahtarla girişin çalıştığını, parolayla ise sunucunun reddettiğini kontrol edin:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Ek güvenlik

Parolayı kapatmak en önemli adımdır. Bundan sonra genellikle 22 numaralı port güvenlik duvarıyla sınırlanır (ufw allow from 198.51.100.0/24 to any port 22) ve birkaç başarısız denemeden sonra IP'yi engelleyen fail2ban kurulur. SSH korumasının durumunu sudo fail2ban-client status sshd gösterir.

Otomasyon anahtarını, authorized_keys dosyasında anahtarın önüne yazılan seçeneklerle kısıtlayabilirsiniz: örneğin from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup yalnızca tek bir adresten ve etkileşimsiz kabuk olmadan girişe izin verir.

Sık yapılan hatalar ve çözümleri

Permission denied (publickey)

En sık karşılaşılan hata. Nedenler, sıklıktan nadire doğru:

1. Sunucuda yanlış izinler. sshd, dizin veya dosya başkaları tarafından yazılabiliyorsa authorized_keys dosyasını yok sayar. Çözüm: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys ve ev dizininin grup veya diğerleri tarafından yazılamaması.
2. Yanlış sahip. Dosyaları sudo ile oluşturduysanız root'a aittirler. Çözüm: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. Anahtar yanlış kullanıcı için konmuş. Anahtarı root için kopyaladınız ama deploy ile giriyorsunuz ya da tersi.
4. İstemci yanlış anahtarı sunuyor. ssh -v çıktısındaki Offering public key satırları hangi anahtarların denendiğini gösterir. Doğru anahtarı -i ile veya IdentityFile ile belirtin.
5. Kopyalamada anahtar bozulmuş. Genel anahtar tek satır olmalıdır. Panodan kopyalarken eklenen satır sonu anahtarı bozar.

Sunucu tarafındaki nedeni günlük gösterir: sudo journalctl -u ssh -n 30 (RHEL'de -u sshd). Orada şuna benzer satırlar bulunur: Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

İstemci, başkalarının okuyabildiği bir özel anahtarı kullanmayı reddeder. Çözüm: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

Sunucunun anahtarı known_hosts dosyasındakiyle uyuşmuyor. Bu, sunucu yeniden kurulduğunda ya da IP değiştiğinde olabilir; ama «ortadaki adam» saldırısında da aynı mesaj görülür. Sunucunun gerçekten yeniden oluşturulduğundan emin olun, sonra eski kaydı silin: ssh-keygen -R 203.0.113.10.

Too many authentication failures

Ajan sunucuya çok fazla anahtar gönderdi ve sunucu MaxAuthTries sınırında bağlantıyı kesti. Çözüm: ~/.ssh/config içinde IdentitiesOnly yes ve açık bir IdentityFile.

Sonuç

SSH anahtarı kurulumu beş dakikalık bir iştir: ssh-keygen -t ed25519, ssh-copy-id, girişin denenmesi, ardından PasswordAuthentication no ve ikinci bir oturum açıkken sshd'nin yeniden yüklenmesi. ~/.ssh/config uzun komutlardan kurtarır, 700/600 izinleri de «Permission denied» hatalarının çoğunu çözer. SSH, rsync ve sunucunun güvenlik duvarı ile fail2ban'le korunması kurs içinde uygulamalı olarak işlenmektedir.