macOS veya Linux’ta OpenSSH ile SSH Anahtarları Nasıl Oluşturulur

SSH anahtar tabanlı kimlik doğrulama, uzak sunucu erişimini güvence altına almak için sektör standardı yöntemdir. Ağ üzerinden bir parola iletmek yerine, istemciniz kimliğini yalnızca özel anahtarın sahibinin yanıtlayabileceği kriptografik bir meydan okumayı çözerek kanıtlar — sunucu özel anahtarın kendisini hiçbir zaman görmez.

Bir SSH anahtar çifti, matematiksel olarak birbirine bağlı iki dosyadan oluşur: bir özel anahtar (yalnızca yerel makinenizde saklanır, asla paylaşılmaz) ve bir genel anahtar (erişmeniz gereken her sunucuya dağıtılır). Bir bağlantı başlattığınızda, OpenSSH özel anahtarınızın sunucudaki genel anahtara karşılık geldiğini doğrulamak için bir meydan okuma-yanıt el sıkışması kullanır ve parola istemi olmadan erişim sağlar.

SSH Anahtarlarının Parola Kimlik Doğrulamasından Kesinlikle Üstün Olmasının Nedenleri

Parolalar kaba kuvvet saldırılarına, kimlik bilgisi doldurma saldırılarına, kimlik avına ve kötü yapılandırılmış ağlarda ele geçirilmeye karşı savunmasızdır. SSH anahtarları bu saldırı vektörlerinin tamamını aynı anda ortadan kaldırır.

• Kriptografik güç: 4096 bitlik bir RSA anahtarı veya Ed25519 anahtarı, mevcut donanımla kaba kuvvet uygulamak için hesaplama açısından imkânsızdır.
• Kablo üzerinden iletilen sır yok: Özel anahtar makinenizi hiçbir zaman terk etmez. Kimlik doğrulama protokolü, ifşa etmeden sahipliği kanıtlar.
• Otomasyona hazır: CI/CD ardışık düzenleri, Ansible playbook’ları, rsync işleri ve cron tabanlı yedeklemeler, etkileşimsiz kimlik doğrulama gerektirir. SSH anahtarları, bunu betiklere düz metin parolalar gömmeden mümkün kılar.
• Denetlenebilirlik: Her anahtar çifti, parmak iziyle benzersiz şekilde tanımlanabilir; bu da kimlik bilgilerini her yerde değiştirmeden tek bir güvenliği ihlal edilmiş anahtarı iptal etmeyi kolaylaştırır.
• authorized_keys ACL’leriyle uyumluluk: Belirli bir genel anahtarı yalnızca tek bir komut çalıştıracak şekilde kısıtlayabilir, bir kaynak IP’ye bağlayabilir veya port yönlendirmesini engelleyebilirsiniz — parola kimlik doğrulamasının çoğaltamayacağı denetimler.

Bir VPS veya dedicated sunucu yönetiyorsanız, parola kimlik doğrulamasını tamamen devre dışı bırakmak ve yalnızca anahtar tabanlı girişi zorunlu kılmak, alabileceğiniz en yüksek etkili güvenlik sertleştirme adımlarından biridir.

Doğru Anahtar Algoritmasını Seçme

Orijinal OpenSSH belgeleri ve çoğu eski eğitim varsayılan olarak RSA’yı kullanır. Alan ilerledi. İşte ssh-keygen‘nin bugün desteklediği her algoritmanın kesin bir karşılaştırması:

Ed25519, 2024’te doğru varsayılandır. Daha kısa anahtarlar üretir, daha hızlı imzalar ve sabit anahtar boyutu, yanlışlıkla küçük boyutlu bir anahtar oluşturma riskini ortadan kaldırır. 4096 bitlik RSA, Ed25519 desteğinden önce gelen eski sistemlerle (OpenSSH < 6.5, 2014’te yayımlandı) birlikte çalışması gereken ortamlar için kabul edilebilir olmaya devam etmektedir.

Ön Koşullar

• OpenSSH yüklü bir macOS veya Linux iş istasyonu. Her iki işletim sistemi de OpenSSH’yi varsayılan olarak içerir. Şununla doğrulayın:

ssh -V

• Hesabınızın bulunduğu (root veya ayrıcalıksız) bir uzak sunucuya ağ erişimi.
• Terminal konusunda temel düzeyde bilgi.

Minimal kurulum içeren Linux dağıtımlarında (Alpine, bazı Debian netinstall’ları), istemci araçlarını şununla yükleyin:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Adım 1: Terminal Açın

macOS: Cmd + Space tuşlarına basın, Terminal yazın ve Enter’a basın. Alternatif olarak Uygulamalar > Yardımcı Programlar > Terminal’e gidin. İleri düzey kullanıcılar iTerm2 veya VS Code’daki yerleşik terminali kullanabilir.

Linux: Çoğu masaüstü ortamında Ctrl + Alt + T tuşlarına basın veya uygulama menüsünden dağıtımınızın terminal öykünücüsünü başlatın.

Adım 2: SSH Anahtar Çiftini Oluşturun

Ed25519 Anahtarı Oluşturma (Önerilen)

ssh-keygen -t ed25519 -C "your_email@example.com"

-C bayrağı, genel anahtara insan tarafından okunabilir bir yorum ekler. E-posta adresinizi, bir ana bilgisayar adını veya "deploy-key-prod" gibi açıklayıcı bir etiket kullanın — kriptografik bir işlevi yoktur ancak düzinelerce giriş biriken authorized_keys dosyalarını denetlerken paha biçilmezdir.

RSA Anahtarı Oluşturma (Eski Uyumluluk)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

-b 4096‘ü açıkça kullanın. 2048 bitlik tarihsel varsayılan teknik olarak hâlâ kabul edilebilir, ancak çarpanlara ayırma algoritmalarındaki gelecekteki gelişmelere karşı daha az marj sağlar. 4096 kullanılabiliyorsa yeni anahtarlar için asla -b 1024 veya -b 2048 kullanmayın.

Belirli Bir Ana Bilgisayar için Adlandırılmış Anahtar Oluşturma

Birden fazla sunucu veya rol yönetirken, her yerde tek bir anahtar yeniden kullanmak yerine ayrı anahtar dosyaları kullanın. Güvenliği ihlal edilmiş bir anahtar yalnızca dağıtıldığı sistemleri etkiler:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Adım 3: Depolama Konumunu Seçin

ssh-keygen çalıştırdıktan sonra şunu göreceksiniz:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Varsayılanı kabul etmek için Enter’a basın (Ed25519 için ~/.ssh/id_ed25519, RSA için ~/.ssh/id_rsa) veya özel bir yol yazın. Tek genel amaçlı bir anahtar için varsayılan konum uygundur. Role özgü anahtarlar için, önceki adımda gösterildiği gibi her zaman açıklayıcı bir dosya adı belirtin.

Kritik dosya izni notu: ~/.ssh/ dizini 700 modunda olmalı ve özel anahtar dosyaları 600 modunda olmalıdır. OpenSSH, aşırı izin verilen anahtarları kullanmayı reddeder ve bir uyarı yazdırır. Anahtarları makineler arasında kopyalarsanız, izinleri hemen doğrulayın:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Adım 4: Parola Belirleyin

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Bir parola, özel anahtar dosyasını diskte AES-256-CBC kullanarak şifreler (modern OpenSSH’de). Bir saldırgan özel anahtar dosyanızı ele geçirirse — çalınan bir dizüstü bilgisayar, güvenliği ihlal edilmiş bir yedek veya yanlış yapılandırılmış bir bulut anlık görüntüsü aracılığıyla — güçlü bir parola, onu kullanmalarını engelleyen son savunma hattıdır.

Parolayı atlamanın zamanı: Gözetimsiz çalışan otomatik hizmet hesapları (dağıtım ardışık düzenleri, yedekleme aracıları) meşru olarak parolasız anahtarlara ihtiyaç duyar. Bu durumda, anahtarın sunucu tarafındaki izinlerini authorized_keys seçeneklerini kullanarak kısıtlayın (aşağıdaki gelişmiş bölüme bakın) ve özel anahtarı paylaşılan bir dosya sisteminde değil, bir gizli yöneticisinde saklayın.

Parolayı onayladıktan sonra, OpenSSH anahtar parmak izini ve rastgele sanat görüntüsünü çıktılar:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Parmak izini kaydedin. Sunucuları denetlerken anahtarın kimliğini doğrulamak için kullanacaksınız.

Adım 5: Genel Anahtarı Uzak Sunucuya Kopyalayın

Yöntem 1: ssh-copy-id (En Hızlı)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

-i bayrağı, hangi genel anahtarın kopyalanacağını açıkça belirtir ve ssh-copy-id‘nin aracınızdaki her anahtarı yüklemesini önler. Sunucunun parolası için bir kez isteneceksiniz. Araç, dizin oluşturma, dosya ekleme ve izin ayarlamayı otomatik olarak gerçekleştirir.

Yöntem 2: Manuel Dağıtım (ssh-copy-id Kullanılamadığında)

Bu, uzak sistemin Windows, bir ağ aygıtı veya yolunda ssh-copy-id bulunmayan bir konteyner olduğu durumlarda doğru yaklaşımdır.

Önce genel anahtarınızı görüntüleyin:

cat ~/.ssh/id_ed25519.pub

Tüm çıktıyı kopyalayın — ssh-ed25519 (veya ssh-rsa) ile başlayan tek bir satırdır. Ardından sunucuya giriş yapın ve ekleyin:

ssh user@your-server.com

Bağlandıktan sonra:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Yaygın tuzak: > yerine >> kullanmak, tüm authorized_keys dosyasının üzerine yazar ve diğer tüm anahtarları kilitler. Her zaman eklemek için >> kullanın.

Yöntem 3: Tek Komutla SSH Üzerinden Aktarma

Zaten parola erişiminiz varsa ve etkileşimli olarak giriş yapmadan dağıtmak istiyorsanız:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Adım 6: Bağlantıyı Test Edin

ssh -i ~/.ssh/id_ed25519 user@your-server.com

Parola istemi olmadan (veya yalnızca yerel anahtarınız için parola istemiyle) başarılı bir bağlantı, kurulumun doğru olduğunu onaylar. Bağlantı başarısız olursa, tanılamak için ayrıntılı çıktıyla çalıştırın:

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

-vvv bayrağı, tam müzakere günlüğünü yazdırır; hangi anahtarın sunulduğunu, sunucunun onu kabul edip etmediğini ve el sıkışmasının nerede başarısız olduğunu tam olarak gösterir.

Adım 7: Kalıcı Ana Bilgisayar Profilleri için ~/.ssh/config‘i Yapılandırın

Her seferinde tam ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45‘yi yazmak hataya açık ve yavaştır. SSH istemci yapılandırma dosyası bunu ortadan kaldırır:

nano ~/.ssh/config

Bir ana bilgisayar bloğu ekleyin:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Şimdi yalnızca şununla bağlanın:

ssh prod-web

Bu model, düzinelerce sunucuya temiz bir şekilde ölçeklenir ve ölçekte altyapı yöneten herhangi bir mühendis için vazgeçilmezdir. ServerAliveInterval 60 yönergesi her 60 saniyede bir canlı tutma paketi gönderir; güvenlik duvarları tarafından boşta bırakılan bağlantıların kesilmesini önler — bulut sağlayıcılarında yaygın bir hayal kırıklığı kaynağı.

SSH Aracısıyla Birden Fazla Anahtarı Yönetme

SSH aracısı, şifresi çözülmüş özel anahtarları oturumunuz boyunca bellekte tutar; böylece her bağlantıda değil, yalnızca bir kez parola girersiniz.

Aracıyı başlatın ve bir anahtar ekleyin:

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

macOS’ta, ~/.ssh/config‘e aşağıdakileri ekleyerek anahtarları yeniden başlatmalar arasında kalıcı hale getirebilirsiniz:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

UseKeychain yes yönergesi, macOS Anahtarlığı ile entegre olur ve parolayı güvenli bir şekilde saklayarak sistem yeniden başlatmalarında hayatta kalmasını sağlar.

Aracıda şu anda yüklü olan tüm anahtarları listeleyin:

ssh-add -l

Aracıdan belirli bir anahtarı kaldırın:

ssh-add -d ~/.ssh/id_ed25519

Gelişmiş: authorized_keys‘de Anahtarları Kısıtlama

authorized_keys dosyası, güvenliği ihlal edilmiş bir anahtarın patlama yarıçapını önemli ölçüde azaltan anahtar başına seçenekleri destekler. Bunlar, aynı satırda anahtar türünden önce yerleştirilir:

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Bu seçenekler, tek bir güvenliği ihlal edilmiş CI/CD anahtarının tam kabuk erişimi vermemesi gereken dedicated sunuculardaki dağıtım anahtarları için özellikle değerlidir.

Anahtar Dağıtımından Sonra SSH Daemon’ını Sertleştirme

Anahtar tabanlı kimlik doğrulama çalışmaya başladıktan sonra, sunucuda parola kimlik doğrulamasını tamamen devre dışı bırakın. /etc/ssh/sshd_config‘yi düzenleyin:

sudo nano /etc/ssh/sshd_config

Aşağıdaki yönergeleri ayarlayın:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Mevcut oturumunuzun bağlantısını kesmeden daemon’ı yeniden yükleyin:

sudo systemctl reload sshd

Ayrı bir terminalde yeni bir bağlantıyı test etmeden önce mevcut SSH oturumunuzu kapatmayın. Sizi kilitleyen bir yanlış yapılandırma konsoldan kurtarılabilir, ancak bu rahatsız edici ve önlenebilir bir durumdur.

cPanel VPS ortamları çalıştıran sunucularda, bazı cPanel sürümlerinin kendi SSH yapılandırmalarını yönettiğini unutmayın. sshd_config değişikliklerinin cPanel güncellemelerinden sonra kalıcı olduğunu, geçersiz kılma dosyaları için /etc/ssh/sshd_config.d/‘yi kontrol ederek doğrulayın.

SSH Anahtarlarını Döndürme ve İptal Etme

Anahtar döndürme, bir anahtarın sessizce ele geçirilmesi durumunda maruz kalma penceresini sınırlayan bir güvenlik hijyeni uygulamasıdır. Pratik bir döndürme takvimi, kişisel anahtarlar için her 12 ayda bir ve hizmet hesabı anahtarları için her 90 günde birdir.

Bir anahtarı iptal etmek için: Dağıtıldığı her sunucudaki ~/.ssh/authorized_keys‘den satırını kaldırın. Standart OpenSSH’de merkezi bir iptal mekanizması yoktur — bu nedenle her anahtar parmak izinin nerede dağıtıldığına dair bir envanter tutmak önemlidir.

Bir anahtarı döndürmek için:

1. Yeni bir anahtar çifti oluşturun.
2. Yeni genel anahtarı tüm hedef sunuculara dağıtın.
3. Yeni anahtarla bağlantıyı test edin.
4. Eski genel anahtarı tüm authorized_keys dosyalarından kaldırın.
5. Eski özel anahtarı yerel olarak silin veya arşivleyin.

Birden fazla bölgede VPS hosting bulunan ortamlar için, Ansible gibi bir yapılandırma yönetim aracı, anahtar döndürmelerini ölçekte yaymak için pratik çözümdür.

Anahtarları Makineler Arasında Aktarma

Yeni bir iş istasyonu kurduğunuzda, yeni anahtarlar oluşturmak yerine (bu, genel anahtarları her yerde yeniden dağıtmayı gerektirirdi) mevcut özel anahtarlarınızı taşımanız gerekir.

Özel anahtarı SSH üzerinden scp veya rsync kullanarak güvenli bir şekilde kopyalayın:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Alternatif olarak, şifrelenmiş bir USB sürücü veya SSH anahtar depolamayı destekleyen bir parola yöneticisi kullanın (1Password, Bitwarden ve HashiCorp Vault bunların hepsini destekler). Özel anahtarları asla e-postayla göndermeyin veya şifrelenmemiş bulut depolamada saklamayın.

Aktarımdan sonra, yeni makinedeki izinleri hemen doğrulayın:

chmod 600 ~/.ssh/id_ed25519

Sunucunun Ana Bilgisayar Anahtarı Parmak İzini Doğrulama

Bir sunucuya ilk kez bağlandığınızda, OpenSSH sunucunun ana bilgisayar anahtarı parmak izini sunar ve bunu onaylamanızı ister:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Körü körüne yes yazmayın. Beklenen parmak izini bant dışı bir kanal aracılığıyla edinin — barındırma sağlayıcınızın kontrol paneli, sunucuyu hazırlayan bir iş arkadaşı veya sunucunun konsol çıktısı. Bu adım, ortadaki adam saldırılarını önler. Paylaşımlı hosting ortamları için, beklenen parmak izi genellikle kontrol panelinde SSH erişim ayarları altında listelenir.

Kabul edildikten sonra, parmak izi ~/.ssh/known_hosts‘de saklanır. Parmak izi sonraki bir bağlantıda beklenmedik şekilde değişirse, OpenSSH bağlanmayı reddeder ve bir uyarı görüntüler — bunu, devam etmeden önce araştırma gerektiren ciddi bir güvenlik olayı olarak değerlendirin.

Karar Matrisi ve Teknik Kontrol Listesi

SSH anahtar kurulumunuzu üretime hazır saymadan önce bu kontrol listesini kullanın:

• [ ] Anahtar algoritması Ed25519’dur (veya eski uyumluluk için RSA 4096) — DSA ve ECDSA 256, yeni dağıtımlar için kabul edilemez
• [ ] Özel anahtar dosyası izinleri 600; ~/.ssh/ dizin izinleri 700
• [ ] Tüm etkileşimli kullanıcı anahtarlarında güçlü bir parola ayarlanmış
• [ ] Parolasız hizmet hesabı anahtarları, authorized_keys seçenekleri aracılığıyla kısıtlanmış (command=, from=, no-pty)
• [ ] Tüm sunucularda PasswordAuthentication no, /etc/ssh/sshd_config‘de ayarlanmış
• [ ] PermitRootLogin prohibit-password veya PermitRootLogin no zorunlu kılınmış
• [ ] Sunucu ana bilgisayar anahtarı parmak izleri bant dışı olarak doğrulanmış
• [ ] Her parmak izini dağıtıldığı sunucularla eşleştiren bir anahtar envanteri mevcut
• [ ] Anahtar döndürme takvimi tanımlanmış ve takvime eklenmiş
• [ ] Manuel -i bayrağı kullanımını önlemek için ~/.ssh/config ana bilgisayar blokları yapılandırılmış
• [ ] Çalışma oturumları sırasında tekrarlanan parola girişini önlemek için SSH aracısı kullanılıyor
• [ ] known_hosts girişleri, eski veya beklenmedik girişler için periyodik olarak gözden geçiriliyor

SSS

Ed25519 ve RSA SSH anahtarları arasındaki fark nedir?

Ed25519, yaklaşık 128 bit güvenlik sağlayan sabit 256 bitlik bir anahtarla eliptik eğri kriptografisi kullanır, RSA’dan daha hızlı imzalar ve daha kısa anahtar dizeleri üretir. 4096 bitlik RSA karşılaştırılabilir güvenlik sağlar, ancak daha yavaştır ve daha büyük anahtar materyali oluşturur. OpenSSH 6.5 sürümünden daha eski bir sisteme bağlanmanız gerekmiyorsa tüm yeni anahtarlar için Ed25519 kullanın.

Birden fazla sunucu için aynı SSH anahtar çiftini kullanabilir miyim?

Evet, teknik olarak. Ancak en iyi uygulama, rol veya ortam başına ayrı anahtar çiftleri kullanmaktır (kişisel iş istasyonu erişimi, CI/CD dağıtımı, veritabanı bakımı). Bu, tek bir güvenliği ihlal edilmiş anahtarın etkisini sınırlar ve ilgisiz sistemleri aksatmadan iptali kolaylaştırır.

Özel anahtarımı kaybedersem ne olur?

O anahtar çiftini kullanarak kimlik doğrulama yapma yeteneğinizi kaybedersiniz. Sunucudaki genel anahtar işe yaramaz hale gelir. Sunucuya alternatif bir yöntemle erişmeniz gerekir — konsol erişimi, ikincil bir anahtar veya barındırma sağlayıcınızın acil erişimi — ardından sahipsiz genel anahtarı authorized_keys‘den kaldırın ve yeni bir anahtar çifti dağıtın.

Genel anahtarımı kopyaladıktan sonra SSH neden hâlâ parola istiyor?

En yaygın nedenler şunlardır: sunucuda ~/.ssh/ (700 olmalı) veya ~/.ssh/authorized_keys (600 olmalı) üzerindeki yanlış izinler; ana dizinin kendisinin herkes tarafından yazılabilir olması; SELinux veya AppArmor’ın .ssh dizinine erişimi engellemesi; veya PubkeyAuthentication no‘nin /etc/ssh/sshd_config‘de ayarlanmış olması. Hangi kimlik doğrulama yönteminin denendiğini ve reddedildiğini tam olarak belirlemek için ssh -vvv çalıştırın.

Artık erişimim olmayan bir sunucudan SSH anahtarını nasıl kaldırırım?

Başka bir kimlik doğrulama yönteminiz yoksa, barındırma sağlayıcınızın destek ekibiyle iletişime geçin veya bant dışı konsol erişimini kullanın (VPS ve dedicated sunucu müşterileri için mevcuttur) ve ~/.ssh/authorized_keys‘yi doğrudan düzenleyin. Bu nedenle konsol erişim kimlik bilgilerini SSH anahtarlarından ayrı tutmak, tartışmasız bir operasyonel gerekliliktir.