SSH Anahtarı Nasıl Oluşturulur? Sunucuya Yükleme ve Kullanımı

Sunucunuzun kimlik doğrulama günlüğüne bir bakın: internete açık her makinede, 22 numaralı porta dakikada onlarca otomatik parola denemesi gelir. Bu botların hepsi aynı şeyi yapar — yaygın kullanıcı adlarıyla sözlük parolalarını dener. Ne kadar uzun bir parola seçerseniz seçin, bu denklem bir olasılık hesabıdır ve olasılığı tamamen ortadan kaldırmanın yolu vardır: SSH anahtarı oluşturma. Anahtarla giriş kurulduğunda parola diye bir şey kalmaz, dolayısıyla denenecek bir şey de kalmaz.

Bu yazıda ssh-keygen ile anahtar çiftini nasıl üreteceğinizi, ssh-copy-id ile sunucuya nasıl yükleyeceğinizi, Windows tarafında OpenSSH ile PuTTYgen arasındaki farkı ve en çok kafa karıştıran konuyu — dosya izinleri yüzünden çıkan Permission denied (publickey) hatasını — adım adım anlatacağım. Türkçe kaynakların büyük kısmı hâlâ on yıl önceki ssh-keygen -t rsa -b 4096 komutunu öğretiyor; bugün varsayılan tercih ed25519 ve nedenleri var. Passphrase'in tam olarak ne işe yaradığı, ssh-agent'ın onu neden her seferinde sormadığı ve .ssh klasörü izin hatasının kaynağı da bu yazıda tek yerde toplanıyor.

SSH Anahtarı Nedir ve Parolaya Göre Neden Daha Güvenli#

SSH anahtarı, birbirine matematiksel olarak bağlı iki dosyadan oluşan bir çifttir: özel anahtar (private key) sizin bilgisayarınızda kalır, genel anahtar (public key) sunucuya yüklenir. Giriş sırasında sunucu size rastgele bir veri gönderir, siz onu özel anahtarınızla imzalarsınız, sunucu imzayı genel anahtarla doğrular. Özel anahtar bu alışverişte hiçbir zaman ağa çıkmaz.

Paroladan üstün olmasının üç somut nedeni var:

Ağdan geçmez. Parola, ne kadar şifreli bir kanaldan gitse de sonuçta sunucuya iletilir; anahtar iletilmez, yalnızca imza iletilir. Sunucu ele geçse bile oradan özel anahtarınız çıkmaz.

Tahmin edilemez. 20 karakterlik güçlü bir parolanın entropi değeri kabaca 128 bit civarındadır ve bu bile iyimser bir tahmindir; ed25519 anahtarının güvenlik seviyesi bunun çok ötesindedir. Kaba kuvvet saldırısı seçenek olmaktan çıkar.

Ölçeklenir. On sunucunuz varsa on farklı parola ezberlemek ya da bir parolayı hepsinde kullanmak zorundasınız. Anahtarla tek bir özel anahtar dosyası tüm sunuculara girer ve bir kişi ekipten ayrıldığında yalnızca onun genel anahtarını authorized_keys dosyalarından silersiniz.

İki yöntemi karşılaştıralım:

Tablodaki tek zayıf nokta anahtarın çalınmasıdır ve tam olarak bu yüzden passphrase vardır.

ssh-keygen ile Anahtar Çifti Oluşturma#

Anahtarı kendi bilgisayarınızda üretin, sunucuda değil. Bu, özel anahtarın hiç ağa çıkmaması için önemlidir. macOS, Linux ve Windows 10/11 (PowerShell veya Terminal) için komut aynıdır:

ssh-keygen -t ed25519 -C "mehmet@laptop-2026"

Komut üç soru sorar:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/mehmet/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Birinci soruda Enter'a basıp varsayılan yolu kabul edebilirsiniz. Farklı sunucular için ayrı anahtarlar tutmak isterseniz burada isim verin, örneğin /home/mehmet/.ssh/id_ed25519_prod.

İkinci ve üçüncü soru passphrase içindir; bir sonraki bölümde ayrıntısına gireceğiz. Şimdilik: boş bırakmayın.

Sonuçta iki dosya oluşur:

/home/mehmet/.ssh/id_ed25519       → özel anahtar (ASLA paylaşılmaz)
/home/mehmet/.ssh/id_ed25519.pub   → genel anahtar (sunucuya yüklenir)

Genel anahtar tek satırlık, okunabilir bir metindir:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKq3Bv... mehmet@laptop-2026

Sonundaki yorum alanı (-C ile verdiğiniz değer) tamamen bilgilendirme amaçlıdır ama çok işinize yarar: sunucudaki authorized_keys dosyasında on satır varken hangisinin kime ait olduğunu ancak buradan anlarsınız. Kişi + cihaz biçiminde yazmanızı öneririm.

ed25519 mü, RSA mı#

Bugün varsayılan tercih ed25519 olmalıdır. Nedenleri:

• Anahtar dosyası çok daha kısadır (bir satır), 4096 bitlik RSA anahtarı ise sekiz satırdır.
• İmza ve doğrulama işlemleri daha hızlıdır.
• Parametre seçimi yoktur; RSA'da olduğu gibi "kaç bit yeterli" tartışması bulunmaz.
• Modern OpenSSH sürümlerinin tamamı destekler.

RSA'ya yalnızca çok eski bir sisteme bağlanmak zorundaysanız dönün, o da 4096 bit ile:

ssh-keygen -t rsa -b 4096 -C "mehmet@laptop-2026"

⚠️ ssh-keygen -t dsa ve -t ecdsa seçeneklerinden uzak durun. DSA modern OpenSSH sürümlerinde tamamen devre dışıdır; ECDSA ise desteklenmeye devam etse de eğri seçimi konusundaki tartışmalar nedeniyle ed25519 kadar tercih edilmez.

Mevcut anahtarınızın tipini ve parmak izini görmek için:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
# 256 SHA256:9Xk2... mehmet@laptop-2026 (ED25519)

Baştaki sayı anahtar boyutunu, sondaki parantez algoritmayı verir.

Passphrase Ne İşe Yarar#

Passphrase, özel anahtar dosyanızı şifreleyen bir paroladır. Sunucuya gitmez, sunucu onu bilmez; yalnızca yerel diskteki dosyayı açmak için kullanılır.

Neden gerekli olduğunu bir senaryoyla anlatayım: dizüstü bilgisayarınız çalındı ya da bir zararlı yazılım ~/.ssh/ klasörünü sızdırdı. Passphrase yoksa, o dosyayı ele geçiren kişi anahtarınızın yüklü olduğu tüm sunuculara anında girer. Passphrase varsa, elinde şifreli bir dosya vardır ve önce o parolayı kırması gerekir; bu size anahtarları iptal edip yenilerini dağıtmak için zaman kazandırır.

Passphrase koymanın "her seferinde parola girmek zorunda kalırım" itirazının cevabı ssh-agent'tır: passphrase'i oturum başına bir kez girersiniz, ajan çözülmüş anahtarı bellekte tutar ve sonraki bağlantılarda sormaz. Yani konfor kaybı bir kereliktir.

Mevcut bir anahtara sonradan passphrase eklemek ya da değiştirmek mümkündür:

ssh-keygen -p -f ~/.ssh/id_ed25519

Komut önce eski passphrase'i (yoksa boş geçilir), sonra yenisini sorar. Anahtarın kendisi değişmez, yalnızca dosyanın şifrelemesi yenilenir — yani sunuculardaki genel anahtarı güncellemenize gerek yoktur.

Passphrase'i hangi durumda boş bırakabilirsiniz? Yalnızca tamamen otomatik bir işlem için üretilen, tek bir sunucuya sınırlı yetkiyle tanımlanmış hizmet anahtarlarında. O durumda bile anahtarı authorized_keys içinde kısıtlamanız gerekir; buna aşağıda geleceğiz. Özel anahtarların saklanması ve korunması konusunun tamamı için private key güvenliği yazısına bakabilirsiniz.

Anahtarı Sunucuya Yükleme: ssh-copy-id ve Manuel Yöntem#

Genel anahtarı sunucuya yüklemenin en temiz yolu ssh-copy-id komutudur. Kendi bilgisayarınızda çalıştırın:

ssh-copy-id mehmet@sunucu-ip

Komut parolayla bir kez bağlanır ve şunları yapar: ~/.ssh dizini yoksa oluşturur, izinlerini 700 yapar, authorized_keys dosyasını oluşturup 600 izin verir, genel anahtarınızı dosyanın sonuna ekler (mevcut anahtarları silmez). İzin hatalarının büyük kısmı bu komutu kullandığınızda hiç yaşanmaz.

Belirli bir anahtarı yüklemek isterseniz:

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub mehmet@sunucu-ip

SSH portunu değiştirdiyseniz:

ssh-copy-id -p 2222 mehmet@sunucu-ip

Manuel yükleme#

ssh-copy-id yoksa (bazı Windows kurulumlarında bulunmaz) ya da sunucuya yalnızca konsoldan erişiyorsanız, elle ekleyebilirsiniz. Önce genel anahtarınızın içeriğini kopyalayın:

cat ~/.ssh/id_ed25519.pub

Sonra sunucuda, giriş yapacağınız kullanıcı olarak:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKq3Bv... mehmet@laptop-2026' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

⚠️ >> yerine > yazmayın. Tek > dosyanın içeriğini siler ve o sunucuya erişimi olan diğer herkesin anahtarını uçurur. Bu, ekip sunucularında yaşanmış ve gece yarısı telefon açtırmış bir hatadır.

⚠️ Anahtarı kopyalarken satır sonu eklemeyin. Genel anahtar tek satırdır; kopyalama sırasında ortadan bölünürse OpenSSH satırı geçersiz sayar ve sessizce yok sayar, size yalnızca Permission denied der. wc -l ~/.ssh/authorized_keys ile satır sayısını, cat -A ile satır sonlarını kontrol edebilirsiniz.

Anahtarı yetkiyle sınırlamak#

Bir anahtarı yalnızca belirli bir komutu çalıştırmakla sınırlayabilirsiniz. Bu özellikle yedekleme betikleri için çok değerlidir; anahtar çalınsa bile kabuk açmaz:

command="/usr/local/bin/yedek-al.sh",no-port-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3... yedek@backup-sunucu

from="203.0.113.10" seçeneğiyle anahtarı belirli bir IP'den gelen bağlantılarla da sınırlayabilirsiniz.

authorized_keys Nedir, Nerede Durur#

authorized_keys, bir kullanıcının hangi genel anahtarlarla giriş yapabileceğini listeleyen düz metin dosyasıdır. Yolu, giriş yapılan kullanıcının ev dizinidir:

Her satır bir anahtardır ve satır sırası önemsizdir. Bir kullanıcı için beş kişinin anahtarı tanımlıysa beşi de girebilir.

En sık yapılan kavram hatası şudur: anahtarı yanlış kullanıcının dizinine koymak. Root'un authorized_keys dosyasına anahtar eklerseniz ssh mehmet@sunucu çalışmaz; ssh root@sunucu çalışır. Yeni bir sudo kullanıcısı açtıysanız anahtarı onun dizinine kopyalamayı unutmayın — bu adımın ayrıntıları root yerine kullanıcı ile çalışmak yazısında var.

Sunucudaki tüm anahtarları denetlemek için:

sudo find /root /home -name authorized_keys -exec echo "--- {}" \; -exec cat {} \;

Bu komutu ayda bir çalıştırın. Tanımadığınız bir anahtar, bir güvenlik olayının en net işaretlerinden biridir ve parola değiştirmek onu engellemez.

Permission Denied (publickey) Hatasının Asıl Nedeni: İzinler#

Anahtarı doğru yükledi ama giremiyorsanız, sorunun %90 ihtimalle dosya izinlerinden kaynaklandığını söyleyebilirim. OpenSSH, izinleri fazla gevşek olan bir .ssh dizinini ya da anahtar dosyasını sessizce yok sayar — güvenlik gerekçesiyle, çünkü başkasının okuyabildiği bir anahtar dosyası güvenilmezdir.

Doğru izinler şunlardır:

# Sunucu tarafında
chmod 755 ~                        # ev dizini başkasına yazılabilir OLMAMALI
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Kendi bilgisayarınızda
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519        # özel anahtar
chmod 644 ~/.ssh/id_ed25519.pub    # genel anahtar
chmod 600 ~/.ssh/config            # varsa

Özel anahtar dosyanız fazla açık ise istemci tarafında şu hatayı alırsınız:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: UNPROTECTED PRIVATE KEY FILE!               @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/mehmet/.ssh/id_ed25519' are too open.

Sunucu tarafındaki reddi görmek için sunucu günlüğüne bakın:

sudo tail -f /var/log/auth.log        # Debian/Ubuntu
sudo tail -f /var/log/secure          # RHEL ailesi

Karşılaşacağınız satır genelde şudur:

Authentication refused: bad ownership or modes for directory /home/mehmet/.ssh

Sorunu istemci tarafından teşhis etmenin en hızlı yolu ayrıntılı mod:

ssh -vvv mehmet@sunucu-ip

Çıktıda hangi anahtar dosyalarının denendiğini, sunucunun hangilerini reddettiğini ve doğrulamanın hangi aşamada durduğunu görürsünüz. Offering public key: /home/mehmet/.ssh/id_ed25519 satırından sonra Authentications that can continue: publickey,password geliyorsa anahtar sunulmuş ama kabul edilmemiştir — yani sorun sunucudadır. Bu hata ailesinin tüm varyasyonları için SSH permission denied publickey hatası yazısına bakabilirsiniz; dosya izinlerinin genel mantığı ise Linux dosya izinleri yazısında anlatılıyor.

Bir diğer sessiz neden SELinux'tur. AlmaLinux, Rocky Linux ve RHEL kurulumlarında .ssh dizinini elle oluşturduysanız güvenlik bağlamı yanlış olabilir:

restorecon -Rv ~/.ssh

Windows'ta Anahtar Oluşturma: OpenSSH ve PuTTYgen#

Windows tarafında iki ayrı dünya vardır ve karışıklığın kaynağı budur: OpenSSH ve PuTTY. İkisi farklı anahtar dosya formatları kullanır.

OpenSSH (önerilen)#

Windows 10 ve 11'de OpenSSH istemcisi yerleşiktir. PowerShell'i açıp Linux'takiyle aynı komutu çalıştırırsınız:

ssh-keygen -t ed25519 -C "mehmet@windows-pc"

Dosyalar C:\Users\mehmet\.ssh\ altına düşer. Bağlanmak için de yine aynı komut:

ssh mehmet@sunucu-ip

ssh-copy-id Windows'ta bulunmadığı için genel anahtarı elle göndermeniz gerekir:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh mehmet@sunucu-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

⚠️ Windows'ta bu komutu çalıştırırken dosyanın UTF-8 BOM ile başlamamasına dikkat edin; type yerine Get-Content kullanırsanız PowerShell bazı sürümlerde BOM ekleyebilir ve anahtar satırı bozulur. Yukarıdaki type biçimi güvenlidir.

Windows'ta anahtar dosyasının izinleri de sorun çıkarabilir. chmod yoktur; onun yerine dosyanın erişim listesinden diğer kullanıcıları kaldırmanız gerekir:

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r /grant:r "$($env:USERNAME):(R)"

PuTTYgen#

PuTTY kullanıyorsanız anahtarınız .ppk uzantılı olmalıdır. PuTTYgen'i açın, alt kısımdan EdDSA (Ed25519) seçin, Generate düğmesine basın ve fare imlecini pencerede gezdirin (rastgelelik için gereklidir). Üretim bitince:

1. Üstteki kutuda görünen tek satırlık metin genel anahtardır; kopyalayıp sunucudaki authorized_keys dosyasına yapıştırın.
2. Key passphrase alanına bir passphrase yazın.
3. Save private key ile .ppk dosyasını kaydedin.

PuTTY'de bağlanırken bu dosyayı Connection → SSH → Auth → Credentials bölümünde tanıtırsınız.

⚠️ PuTTYgen'in üstteki kutuda gösterdiği metni kullanın; "Save public key" düğmesiyle kaydedilen dosyayı authorized_keys içine koymayın. O dosya RFC 4716 formatındadır, çok satırlıdır ve ---- BEGIN SSH2 PUBLIC KEY ---- ile başlar; OpenSSH bu formatı authorized_keys içinde kabul etmez. Yıllardır gördüğüm Windows kaynaklı SSH anahtarı sorunlarının birinci nedeni budur.

İki format arasında dönüşüm yapmak isterseniz PuTTYgen'in Conversions menüsünü kullanabilirsiniz; komut satırından ise puttygen id_ed25519 -O private -o key.ppk çalışır. Windows'tan bağlanmanın tüm yöntemleri için Windows bilgisayardan sunucuya SSH bağlantısı yazısına bakabilirsiniz.

ssh-agent ile Passphrase'i Bir Kez Girmek#

ssh-agent, çözülmüş özel anahtarınızı bellekte tutan küçük bir arka plan sürecidir. Sayesinde passphrase'i oturum başına bir kez girersiniz.

Linux ve macOS'ta:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

ssh-add passphrase'i sorar ve anahtarı ajana ekler. Yüklü anahtarları görmek için ssh-add -l, hepsini silmek için ssh-add -D kullanılır. macOS'ta anahtarı Anahtar Zinciri'ne kaydedip her açılışta otomatik yüklemek için ssh-add --apple-use-keychain ~/.ssh/id_ed25519 çalıştırabilirsiniz.

Windows'ta ajan bir servis olarak gelir ama varsayılan olarak kapalıdır; yönetici PowerShell'inde açın:

Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Birden fazla sunucu ve anahtarınız varsa ~/.ssh/config dosyası hayatınızı kolaylaştırır:

Host prod
    HostName 203.0.113.25
    User mehmet
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

Host test
    HostName 203.0.113.26
    User mehmet
    IdentityFile ~/.ssh/id_ed25519

Bu tanımlarla ssh prod yazmak yeterlidir. IdentitiesOnly yes satırı önemlidir: onsuz istemci ajandaki tüm anahtarları sırayla dener ve sunucudaki MaxAuthTries sınırına takılıp Too many authentication failures hatası verebilirsiniz. Ajan ve anahtar yönetiminin ileri konuları için ssh-agent ve anahtar yönetimi yazısına göz atın.

⚠️ Agent forwarding (ForwardAgent yes) konusunda dikkatli olun. Bu özellik, bağlandığınız sunucunun sizin ajanınızı kullanmasına izin verir; o sunucunun root yetkisine sahip biri sizin adınıza başka sunuculara bağlanabilir. Atlama sunucusu senaryosunda forwarding yerine ProxyJump kullanın; ayrıntısı SSH jump host bastion sunucu yazısında.

Parola ile Girişi Kapatma#

Anahtar çalışıyorsa son adım, parolayla girişi tamamen kapatmaktır. Bu yapılmadığı sürece sunucunuz bot trafiğine hedef olmaya devam eder — siz anahtar kullanıyor olsanız bile.

⚠️ Kapatmadan önce mutlaka ikinci bir terminalde anahtarla giriş yapabildiğinizi doğrulayın ve mevcut oturumunuzu kapatmayın. Ekipteki herkesin anahtarının yüklü olduğundan da emin olun.

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3

KbdInteractiveAuthentication no satırı gereklidir; bazı dağıtımlarda parola girişi bu ikinci kanaldan açık kalır ve yalnızca PasswordAuthentication no yazmak yetmez.

Kaydettikten sonra sözdizimini test edin, sonra uygulayın:

sudo sshd -t && sudo systemctl reload sshd

sshd -t sessizce çıkarsa yapılandırma geçerlidir. Bu testi atlamak, servisin hiç açılmaması ve sunucuya bağlanamamanız anlamına gelebilir. Yapılandırmanın gerçekten uygulandığını görmek için:

sudo sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Bundan sonra portu değiştirmek isterseniz SSH portu değiştirme, kalan gürültüyü kesmek için fail2ban kurulumu yazılarına bakabilirsiniz. Paylaşımlı hosting kullanıyorsanız SSH erişimi cPanel üzerinden açılır ve anahtar yönetimi de oradan yapılır; adımları cPanel SSH erişimi terminal yazısında bulabilirsiniz.

Sıkça Sorulan Sorular#

Aynı SSH anahtarını birden fazla sunucuda kullanabilir miyim#

Evet, kullanabilirsiniz ve yaygın uygulama budur. Genel anahtarınızı istediğiniz kadar sunucunun authorized_keys dosyasına ekleyebilirsiniz; anahtar çifti sunucuya değil size aittir. Ancak üretim ve test ortamlarını ayırmak isterseniz iki farklı anahtar üretip ~/.ssh/config dosyasında hangi sunucuda hangisinin kullanılacağını tanımlamak daha temiz bir yaklaşımdır. Bu ayrım, bir anahtarın ele geçmesi durumunda etki alanını daraltır.

Özel anahtarımı kaybedersem ne olur#

Sunuculara erişiminizi kaybedersiniz; kayıp özel anahtar yeniden üretilemez, çünkü genel anahtardan özel anahtar hesaplanamaz. Bu durumda sağlayıcınızın konsol ekranından ya da parola girişi hâlâ açıksa parolayla bağlanıp yeni bir anahtar tanımlamanız gerekir. Bu yüzden parola girişini kapatmadan önce mutlaka konsol erişiminizin çalıştığını test edin ve mümkünse ikinci bir yedek anahtarı authorized_keys dosyasına ekleyin. Kayıp anahtarın eski satırını da tüm sunuculardan silin.

Anahtar oluşturdum ama sunucu hâlâ parola soruyor#

Bu, anahtarın sunucu tarafından kabul edilmediği anlamına gelir ve nedeni genelde şu üçünden biridir. Birincisi, anahtar yanlış kullanıcının ~/.ssh/authorized_keys dosyasına eklenmiştir; root'a eklediyseniz normal kullanıcıyla giriş yapamazsınız. İkincisi, .ssh dizini veya authorized_keys dosyasının izinleri fazla geniştir ve OpenSSH dosyayı sessizce yok saymıştır. Üçüncüsü, genel anahtar kopyalanırken satır ortadan bölünmüştür. ssh -vvv çıktısı ve sunucudaki /var/log/auth.log dosyası üçünü de ayırt etmenizi sağlar.

Passphrase'i unuttum, ne yapabilirim#

Passphrase'i kurtarmanın bir yolu yoktur; özel anahtar dosyası o parolayla şifrelenmiştir ve parolasız açılamaz. Yapmanız gereken, yeni bir anahtar çifti üretip yeni genel anahtarı sunuculara tanımlamaktır. Hâlâ açık bir SSH oturumunuz veya konsol erişiminiz varsa bu işlem birkaç dakika sürer; hiçbir erişiminiz kalmadıysa sağlayıcının konsol ekranından girmeniz gerekir. Eski anahtarın satırını authorized_keys dosyalarından silmeyi unutmayın.

RSA anahtarım var, ed25519'a geçmeli miyim#

Acil bir gereklilik yok ama yeni anahtar üretirken ed25519 seçmenizi öneririm. 4096 bitlik bir RSA anahtarı bugün için güvenlidir; sorun yalnızca dosya boyutu ve işlem hızıdır. Geçiş yapmak isterseniz yeni anahtarı üretin, genel anahtarını sunuculara ekleyin, yeni anahtarla giriş yapabildiğinizi doğrulayın ve ancak ondan sonra eski RSA satırını authorized_keys dosyalarından silin. İki anahtarın bir süre birlikte tanımlı kalmasında sakınca yoktur.

SSH anahtarını sunucuda mı yoksa kendi bilgisayarımda mı üretmeliyim#

Kendi bilgisayarınızda üretin. Özel anahtarın hiçbir zaman ağa çıkmaması ve sizden başka bir makinede bulunmaması esastır; sunucuda üretip indirdiğinizde anahtar en az bir kez ağdan geçmiş, sunucu diskinde iz bırakmış ve muhtemelen yedeklere girmiş olur. Sunucuda anahtar üretmenin tek meşru senaryosu, o sunucunun başka bir sunucuya bağlanması gerektiği durumdur; o zaman da üretilen anahtar o makineye ait olur ve dışarı çıkarılmaz.

authorized_keys dosyasına kaç anahtar ekleyebilirim#

Pratikte bir sınır yoktur; her satır bir anahtardır ve onlarca satır olabilir. Ancak sunucu tarafındaki MaxAuthTries ayarı istemcinin kaç anahtar deneyebileceğini sınırlar, bu yüzden çok sayıda anahtarı olan bir istemci Too many authentication failures hatası alabilir. Bunu istemci tarafında IdentitiesOnly yes ve IdentityFile tanımlayarak çözersiniz. Yönetim açısından her satıra kim olduğunu belirten bir yorum eklemek ve dosyayı düzenli olarak denetlemek önemlidir.

Anahtarla giriş yaparken sudo parolası da gerekir mi#

Evet, ikisi farklı şeylerdir. SSH anahtarı sunucuya giriş için kullanılır; sudo ise giriş yaptıktan sonra yetki yükseltmek için kullanıcının kendi parolasını sorar. Yani anahtarla girseniz bile sudo systemctl restart nginx yazdığınızda parola istenir. Bu davranış kasıtlıdır: açık kalmış bir terminale erişen birinin ayrıcalıklı komut çalıştırmasını engeller. Yalnızca otomasyon gerektiren tekil komutlar için sudoers içinde NOPASSWD tanımı yapılabilir.

Kapanış#

SSH anahtarı oluşturmak tek bir komutluk iş: ssh-keygen -t ed25519 yazıp passphrase belirlemek, sonra ssh-copy-id ile sunucuya yüklemek. Zorluk komutta değil, etrafındaki üç ayrıntıda: anahtarın doğru kullanıcının ev dizinine gitmesi, .ssh ve authorized_keys izinlerinin sırasıyla 700 ve 600 olması, Windows'ta PuTTYgen'in kaydettiği dosya yerine ekrandaki tek satırlık metnin kullanılması. Bu üçünü bilen biri, Permission denied (publickey) hatasını dakikalar içinde çözer; bilmeyen ise saatlerce yanlış yerde arar. Kurulum tamamlandığında parolayla girişi kapatın — asıl kazanç oradadır, çünkü sunucunuz artık denenecek bir parola sunmaz.

Anahtar tabanlı erişimi baştan doğru kurmak için tam kök yetkisi ve acil durumlarda konsol bağlantısı gerekir; VDS sunucu paketleri bunu sağlar, daha yüksek kaynak esnekliği arıyorsanız bulut sunucu tarafına bakabilirsiniz. Sertleştirme, anahtar yönetimi ve güvenlik duvarı kurallarını kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz bu işleri devralır. Tüm sunucu seçeneklerini karşılaştırmak için sunucu paketleri sayfasına göz atabilirsiniz.