Mevcut Bir VPS’e SSH Genel Anahtarı Nasıl Yüklenir

Bir SSH açık anahtarı, uzak bir sunucudaki ~/.ssh/authorized_keys içinde saklanan ve karşılık gelen özel anahtara sahip herhangi bir istemciye ağ üzerinden parola iletmeden erişim sağlayan bir kriptografik kimlik bilgisidir. Açık anahtarınızı mevcut bir VPS’e yüklemek, parola tabanlı kimlik doğrulamayı asimetrik kriptografi ile değiştirir veya tamamlar; bu sayede kaba kuvvet ve kimlik bilgisi doldurma saldırılarının istismar ettiği saldırı yüzeyi ortadan kalkar.

Bu kılavuz sürecin her aşamasını kapsamaktadır: anahtar oluşturma, manuel ve otomatik yükleme yöntemleri, izin sıkılaştırma, sshd_config ayarlaması, çoklu anahtar yönetimi ve deneyimli yöneticilerin bile tökezlediği yaygın hata durumları.

SSH Anahtar Kimlik Doğrulaması Neden Parolalardan Üstündür

Tek bir komuta dokunmadan önce kriptografik mekanizmayı anlamak faydalıdır. Bir anahtar çiftiyle kimlik doğruladığınızda, sunucu açık anahtarınızla şifrelenmiş bir meydan okuma gönderir. Yalnızca eşleşen özel anahtarın sahibi yanıtı çözüp imzalayabilir. Hiçbir sır iletilmez — bunu, kimlik bilgisinin bizzat kablo üzerinden iletildiği (TLS ile sarılmış olsa bile) parola kimlik doğrulamasıyla karşılaştırın.

Pratik sonuç: Genel internete açık herhangi bir VPS Hosting ortamında SSH anahtarları isteğe bağlı bir sıkılaştırma değil — temel gerekliliktir.

Ön Koşullar

• SSH üzerinden erişilebilen mevcut bir VPS (şu anda parola veya mevcut anahtar girişi çalışıyor olmalı)
• Linux, macOS veya OpenSSH ya da PuTTY yüklü Windows çalıştıran yerel bir makine
• VPS üzerinde hedef kullanıcının ana dizinine yazma için yeterli ayrıcalıklar
• Terminal ve nano ya da vim gibi bir metin düzenleyiciyle temel düzeyde deneyim

Adım 1: SSH Anahtar Çifti Oluşturma

~/.ssh/id_ed25519 veya ~/.ssh/id_rsa konumunda zaten bir anahtar çiftiniz varsa ileriye atlayın. Aksi takdirde şimdi bir tane oluşturun.

Doğru Algoritmayı Seçme

Ed25519 modern standarttır. RSA 4096’yı yalnızca Ed25519’u desteklemeyen eski sunuculara bağlanırken kullanın.

Ed25519 anahtar çifti oluşturma:

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

RSA 4096 anahtar çifti oluşturma (eski sistemler):

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

Anahtar oluşturma sırasında kayıt yolu ve isteğe bağlı bir parola girmeniz istenecektir. Varsayılan yolu (~/.ssh/id_ed25519) kabul etmek çoğu kullanıcı için uygundur. Her zaman bir parola belirleyin — bu, özel anahtarı diskte AES-256 kullanarak şifreler; böylece çalınan bir dizüstü bilgisayar otomatik olarak ele geçirilmiş bir sunucu anlamına gelmez.

Bu işlem iki dosya üretir:

• ~/.ssh/id_ed25519 — özel anahtarınız. Bunu asla paylaşmayın, asla bir sunucuya kopyalamayın, asla sürüm kontrolüne işlemeyin.
• ~/.ssh/id_ed25519.pub — açık anahtarınız. Bunu serbestçe dağıtmak güvenlidir.

Kopyalayabilmek için açık anahtarı görüntüleyin:

cat ~/.ssh/id_ed25519.pub

Çıktı şuna benzer görünecektir:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Algoritma öneki ve sondaki yorum dahil tüm tek satırlık dizeyi kopyalayın.

Adım 2: VPS’inize Giriş Yapın

Mevcut kimlik doğrulama yönteminizi kullanarak VPS’e bağlanın:

ssh root@your_vps_ip

your_vps_ip kısmını sunucunuzun gerçek IPv4 veya IPv6 adresiyle değiştirin. Kök olmayan bir kullanıcı hesabını yönetiyorsanız root kısmını uygun kullanıcı adıyla değiştirin. Birden fazla kullanıcı hesabına sahip olabileceğiniz Dedicated Servers üzerinde, anahtarları her zaman kök olmayan bir kullanıcıya dağıtmayı ve ayrıcalık yükseltme için sudo kullanmayı tercih edin.

Adım 3: .ssh Dizinini Hazırlama

Giriş yaptıktan sonra hedef kullanıcı için .ssh dizinini doğrulayın veya oluşturun:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

700 izni (rwx------) zorunludur. OpenSSH, .ssh dizini grup veya herkes tarafından yazılabilir durumdaysa authorized_keys dosyasını sessizce kullanmayı reddeder. Bu, aksi takdirde doğru bir kurulumdan sonra anahtar kimlik doğrulamasının başarısız olmasının en yaygın nedenlerinden biridir.

Adım 4: Açık Anahtarı authorized_keys Dosyasına Ekleme

Yöntem A: Manuel Yapıştırma (Evrensel)

authorized_keys dosyasını açın veya oluşturun:

nano ~/.ssh/authorized_keys

Açık anahtarınızı yeni bir satıra yapıştırın. Bu dosyadaki her satır bir yetkili anahtarı temsil eder. Ctrl+X ile kaydedin, ardından Y, ardından Enter.

Doğru izinleri ayarlayın:

chmod 600 ~/.ssh/authorized_keys

600 izni (rw-------) yalnızca dosya sahibinin okuyup yazabilmesini sağlar. OpenSSH bunu katı biçimde uygular.

Yöntem B: ssh-copy-id (Hız İçin Önerilen)

Yerel makinenizde ssh-copy-id mevcutsa (Linux ve macOS’ta standarttır), bu tek komut dizin oluşturma, anahtar ekleme ve izin ayarlamayı otomatik olarak gerçekleştirir:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Mevcut SSH parolası için bir kez istemde bulunulacaktır. Bundan sonra anahtar tabanlı giriş etkinleşir. -i bayrağı hangi açık anahtarın yükleneceğini açıkça belirtir ve yanlış anahtarın yanlışlıkla yüklenmesini önler.

Yöntem C: cat ve Pipe ile Tek Satır (Betiklenebilir)

Otomasyon hatlarında veya ssh-copy-id kullanılamadığında kullanışlıdır:

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

Bu yaklaşım, üzerine yazmak yerine ekleyerek mevcut yetkili anahtarları koruduğundan idempotent açısından güvenlidir.

Adım 5: Doğru Dosya Sahipliğini Doğrulama

Sıkça gözden kaçan bir tuzak: başka bir kullanıcının hesabını kurarken .ssh dizinini veya authorized_keys dosyasını root olarak oluşturduysanız, sahiplik yanlış olacak ve SSH anahtarı sessizce reddedecektir.

Sahipliği kontrol edin:

ls -la ~/.ssh/

Çıktı, hem dizin hem de dosya için hedef kullanıcı adını hem sahip hem de grup olarak göstermelidir:

drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys

Sahiplik yanlışsa düzeltin (root olarak çalıştırın):

chown -R alice:alice /home/alice/.ssh

Adım 6: SSH Anahtar Girişini Test Etme

Mevcut oturumdan çıkın:

exit

Kurulumu doğrulamak için açık anahtar belirterek yeniden bağlanın:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Giriş parola istemi olmadan başarılı olursa (veya yalnızca yerel anahtar parolanızı isterse), yapılandırma doğrudur. Hâlâ sunucu parolasını soruyorsa aşağıdaki sorun giderme bölümüne geçin.

Adım 7: SSH Daemon Yapılandırmasını Sıkılaştırma

Anahtar tabanlı girişin çalıştığı onaylandıktan sonra, parola kaba kuvvet saldırısı vektörünü tamamen ortadan kaldırmak için parola kimlik doğrulamasını devre dışı bırakın.

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

nano /etc/ssh/sshd_config

Aşağıdaki yönergeleri bulun ve ayarlayın. Bir satır # ile yorum satırı yapılmışsa # işaretini kaldırın ve değeri ayarlayın:

PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes

PermitRootLogin prohibit-password hakkında bir not: bu ayar, root girişine yalnızca anahtar aracılığıyla izin verir; parola tabanlı root erişimini engellerken anahtar doğrulamalı root oturumlarına hâlâ izin verir. Maksimum sıkılaştırma için no olarak ayarlayın ve sudo ile kök olmayan bir kullanıcı kullanın.

Bazı dağıtımlarda, ikincil bir yapılandırma eklentisi ayarlarınızı geçersiz kılabilir. Geçersiz kılmaları kontrol edin:

grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/

Bu dizindeki herhangi bir dosya PasswordAuthentication yes ayarlıyorsa düzenleyin veya kaldırın.

Yeniden başlatmadan önce yapılandırma sözdizimini doğrulayın:

sshd -t

Temiz bir çıktı (hata yok) yeniden yüklemenin güvenli olduğu anlamına gelir. Değişiklikleri uygulayın:

systemctl restart sshd

Kritik uyarı: İkinci bir terminal açıp anahtarınızla hâlâ giriş yapabildiğinizi doğrulamadan mevcut SSH oturumunuzu kapatmayın. Yanlış yapılandırılmış bir dosyayla veya anahtarınız çalışmadan önce sshd yeniden başlatılırsa erişiminiz kesilir. Çoğu VPS Control Panels, kurtarma için acil konsol (KVM/VNC erişimi) sağlar; ancak durumdan tamamen kaçınmak çok daha iyidir.

Adım 8: ~/.ssh/config ile Birden Fazla Anahtar ve Sunucuyu Yönetme

Birden fazla sunucuyu yönetirken — hazırlama/üretim ortamlarında veya birden fazla Dedicated Servers yönetirken yaygındır — SSH istemci yapılandırma dosyası IP adreslerini, kullanıcı adlarını ve anahtar yollarını hatırlama ihtiyacını ortadan kaldırır.

Yerel makinenizde ~/.ssh/config dosyasını oluşturun veya düzenleyin:

nano ~/.ssh/config

Birden fazla ana bilgisayar için örnek yapılandırma:

Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa

Yapılandırma dosyasında doğru izinleri ayarlayın:

chmod 600 ~/.ssh/config

Artık temiz takma adlarla bağlanabilirsiniz:

ssh production-vps
ssh staging-vps

Eski girişteki PubkeyAcceptedKeyTypes +ssh-rsa yönergesi önemlidir: daha yeni OpenSSH istemcileri (8.8+) RSA-SHA1’i varsayılan olarak devre dışı bırakır. Bu geçersiz kılma olmadan, eski sunuculara yapılan bağlantılar şifreli bir “eşleşen ana bilgisayar anahtarı türü yok” hatasıyla başarısız olur.

Sorun Giderme: SSH Anahtar Kimlik Doğrulaması Neden Başarısız Olur

Doğru bir kurulumda bile birçok çevresel faktör, anahtar kimlik doğrulamasının sessizce parola istemine geri dönmesine neden olabilir:

.ssh veya authorized_keys üzerinde yanlış izinler:

Sunucuda ls -la ~/.ssh/ komutunu çalıştırın. Dizin 700 ve dosya 600 olmalıdır. Daha gevşek izinler OpenSSH’nin dosyayı yok saymasına neden olur.

SELinux veya AppArmor bağlam uyuşmazlığı:

SELinux zorlama modundaki RHEL/CentOS/AlmaLinux sistemlerinde authorized_keys dosyasının güvenlik bağlamı yanlış olabilir. Şu komutla geri yükleyin:

restorecon -Rv ~/.ssh

Yanlış kullanıcının ana dizini:

Kullanıcının ana dizini yalnızca sahibi tarafından yazılabilir değilse SSH anahtar kimlik doğrulamasını reddeder. Şu komutla kontrol edin:

ls -ld ~

Ana dizinin kendisi grup veya herkes tarafından yazılabilir olmamalıdır.

AuthorizedKeysFile yönergesi başka bir yere işaret ediyor:

Bazı dağıtımlar AuthorizedKeysFile ayarını standart olmayan bir yol kullanacak şekilde yapılandırır (örn. /etc/ssh/authorized_keys/%u). Etkin ayarı doğrulayın:

sshd -T | grep authorizedkeysfile

Birden fazla anahtar ve ssh-agent çakışmaları:

ssh-agent birden fazla yüklü anahtarla çalışıyorsa, sunucu doğru anahtarı denemeden önce çok fazla başarısız anahtar girişiminin ardından bağlantıyı reddedebilir. Anahtarı açıkça belirtmek için -i kullanın veya ~/.ssh/config içinde IdentitiesOnly yes yapılandırın.

Güvenlik duvarı veya fail2ban IP’nizi engelliyor:

Daha önce birden fazla başarısız giriş denemesi yaptıysanız, fail2ban veya ufw/iptables kuralları IP’nizi geçici olarak yasaklamış olabilir. Şu komutla kontrol edin:

fail2ban-client status sshd

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

Anahtar döndürme, sıkça ihmal edilen bir güvenlik hijyeni uygulamasıdır. Belirli bir anahtarı iptal etmek için sunucudaki ~/.ssh/authorized_keys dosyasını açın ve ilgili satırı silin. Her satır bir anahtardır — satırı kaldırmak, diğer yetkili anahtarları etkilemeden o özel anahtarın sahibinin erişimini anında iptal eder.

Denetim amacıyla her anahtarda farklı yorumlar kullanın (anahtar materyalinden sonraki kısım, örn. alice@workstation-2024); böylece hangi anahtarın hangi kişi veya cihaza ait olduğunu belirleyebilirsiniz. Bir çalışan ayrıldığında veya bir cihaz hizmet dışı bırakıldığında, anahtarını yoruma göre bulun ve kaldırın.

Kendi anahtarınızı döndürmek için yeni bir çift oluşturun, yeni açık anahtarı authorized_keys dosyasına ekleyin, yeni anahtarla girişin çalıştığını doğrulayın, ardından eski anahtar girişini kaldırın.

Pratik Kontrol Listesi

• Varsayılan olarak Ed25519 anahtarları oluşturun; RSA 4096’yı yalnızca eski sunucu uyumluluğu için kullanın
• Özel anahtarınızı her zaman güçlü bir parola ile koruyun
• Mümkün olduğunda hızlı ve hatasız anahtar dağıtımı için ssh-copy-id kullanın
• .ssh dizin izinlerinin 700 ve authorized_keys dosyasının 600 olduğunu doğrulayın
• .ssh ve authorized_keys sahipliğinin hedef kullanıcıyla eşleştiğini onaylayın
• Parola kimlik doğrulamasını devre dışı bırakmadan önce ikinci bir terminalde anahtar girişini test edin
• Daemon’ı yeniden başlatmadan önce yapılandırma sözdizimini doğrulamak için sshd -t çalıştırın
• En az PermitRootLogin prohibit-password ayarlayın; sudo kullanıcısıyla no tercih edin
• Ayarlarınızı geçersiz kılabilecek eklenti dosyaları için /etc/ssh/sshd_config.d/ kontrol edin
• Birden fazla sunucuyu düzenli biçimde yönetmek için ~/.ssh/config takma adları kullanın
• Anahtarları periyodik olarak denetleyin ve döndürün; personel veya cihaz değişikliklerinde derhal iptal edin
• SELinux sistemlerinde, herhangi bir manuel dosya işleminin ardından restorecon -Rv ~/.ssh çalıştırın

SSS

Aynı VPS kullanıcı hesabına birden fazla SSH açık anahtarı ekleyebilir miyim?

Evet. ~/.ssh/authorized_keys dosyasındaki her satır bağımsız bir yetkili anahtardır. Satır başına bir anahtar ekleyin. Bu, birden fazla yöneticiye veya birden fazla cihazdan erişim vermek için standart yaklaşımdır — her kişi veya cihaz benzersiz bir özel anahtara sahiptir ve iptal satır başına yapılır.

Parola kimlik doğrulamasını devre dışı bıraktıktan sonra özel anahtarımı kaybedersem ne olur?

SSH erişiminiz kesilir. Kurtarma, barındırma sağlayıcınızın bant dışı konsol erişimini (KVM/VNC) kullanmayı gerektirir; bu erişim çoğu VPS Hosting kontrol panelinde mevcuttur. Konsoldan /etc/ssh/sshd_config dosyasında PasswordAuthentication yes ayarını yeniden etkinleştirin, sshd yeniden başlatın ve yeni bir anahtar yükleyin. Bu nedenle parolaları devre dışı bırakmadan önce anahtar girişini test etmek vazgeçilmezdir.

Ed25519 tüm sunucularda destekleniyor mu?

Ed25519, OpenSSH 6.5 veya üzerini gerektirir (2014’te yayımlandı). Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ gibi modern Linux dağıtımları bunu yerel olarak destekler. Yalnızca gerçekten eski sistemler RSA geri dönüşü gerektirir.

Yönettiğim her sunucu için aynı SSH anahtar çiftini kullanmalı mıyım?

İşlevsel açıdan kullanışlıdır ancak tek bir tehlike noktası oluşturur. Daha iyi bir uygulama, rol veya ortam başına bir anahtar çifti kullanmaktır (örn. kişisel sunucular için bir anahtar, müşteri altyapısı için bir anahtar). Bu, özel bir anahtarın açığa çıkması durumunda hasar yarıçapını sınırlar.

SSH anahtarı yüklemek SSL Certificates veya web sunucusu yapılandırmamı etkiler mi?

Hayır. SSH anahtarları işletim sistemine terminal erişimini yönetir ve web sunucularının (Apache, Nginx) HTTPS için kullandığı TLS/SSL sertifikalarından tamamen ayrıdır. Farklı portlar (22 ile 443), farklı anahtar biçimleri ve farklı güven zincirleri kullanırlar. Birini değiştirmenin diğeri üzerinde hiçbir etkisi yoktur.