SSH Erişimi: Güvenli Uzak Sunucu Yönetimine Kapsamlı Teknik Rehber

SSH (Secure Shell), iki ağa bağlı ana bilgisayar arasında şifreli bir tünel oluşturan kriptografik bir ağ protokolüdür; güvenilmeyen ağlar üzerinden kimliği doğrulanmış komut yürütme, dosya transferi ve port yönlendirme imkânı sağlar. Varsayılan olarak TCP port 22 üzerinde çalışır ve düz metin kullanan önceki protokollerin — Telnet, rsh ve FTP — yerini alır; tek bir el sıkışmayla gizlilik, bütünlük ve karşılıklı kimlik doğrulama sağlayan bir protokol sunar.

Bir VPS veya dedicated sunucu yöneten herhangi bir yönetici için SSH, isteğe bağlı bir altyapı değildir — birincil kontrol düzlemidir. SSH etrafında aldığınız her yapılandırma kararı, sunucunuzun saldırı yüzeyini, operasyonel güvenilirliğini ve uyumluluk durumunu doğrudan etkiler.

SSH Nasıl Çalışır: Protokol Mimarisi

SSH’yi protokol düzeyinde anlamak, onu doğru yapılandıran yöneticileri istismar edilebilir boşluklar bırakanlardan ayıran şeydir.

Üç Katmanlı Model

SSH, RFC 4251–4254 tarafından tanımlanmıştır ve TCP’nin üzerine yığılmış üç ayrı alt katmanda çalışır:

• SSH Transport Katmanı Protokolü — sunucu kimlik doğrulamasını, anahtar değişimini, şifreleme müzakeresini ve MAC (mesaj kimlik doğrulama kodu) kurulumunu yönetir. Kriptografik el sıkışmanın gerçekleştiği yer burasıdır.
• SSH Kullanıcı Kimlik Doğrulama Protokolü — transport katmanının üzerinde çalışır ve publickey, password, keyboard-interactive veya gssapi-with-mic gibi yöntemler kullanarak istemciden sunucuya kimlik doğrulamasını yönetir.
• SSH Bağlantı Protokolü — şifreli tüneli mantıksal kanallara çoğullar; her kanal bir kabuk oturumu, bir SFTP alt sistemi, yönlendirilmiş bir port veya bir ajan bağlantısı taşır.

El Sıkışmanın Ayrıntıları

ssh user@host komutunu çalıştırdığınızda, bir komut istemi görmeden önce aşağıdaki sıra yürütülür:

1. Yapılandırılmış portta sunucuya TCP bağlantısı kurulur.
2. Sürüm değişimi — istemci ve sunucu protokol sürümü dizelerini değiştirir (SSH-2.0-OpenSSH_9.x).
3. Algoritma müzakeresi (SSH_MSG_KEXINIT) — her iki taraf da desteklenen anahtar değişim algoritmalarını, ana bilgisayar anahtar türlerini, şifreleri, MAC’leri ve sıkıştırma yöntemlerini duyurur. Her listede karşılıklı olarak desteklenen ilk seçenek kazanır.
4. Anahtar değişimi (KEX) — genellikle Diffie-Hellman veya Elliptic Curve Diffie-Hellman (ECDH). Her iki taraf da iletmeden ortak bir sır türetir. Bu, oturum anahtarları üretir.
5. Sunucu ana bilgisayar anahtarı doğrulaması — sunucu, özel ana bilgisayar anahtarıyla bir değeri imzalar. İstemci bu imzayı ~/.ssh/known_hosts dosyasına karşı kontrol eder. Bir uyumsuzluk, varsayılan olarak bir uyarı tetikler ve bağlantıyı engeller.
6. Şifreleme etkinleştirildi — sonraki tüm trafik, müzakere edilen şifre (örn. chacha20-poly1305) ve MAC kullanılarak şifrelenir ve bütünlük korumasına alınır.
7. Kullanıcı kimlik doğrulaması — istemci, müzakere edilen yöntemi kullanarak kimlik doğrulamayı dener. publickey kimlik doğrulamasında, istemci özel anahtarıyla bir meydan okumayı imzalar; sunucu, depolanan genel anahtarı kullanarak doğrular.
8. Kanal açma — bir kabuk, SFTP alt sistemi veya exec kanalı açılır ve oturum başlar.

Bu sürecin tamamı genellikle yerel bir ağda 100 milisaniyenin altında tamamlanır.

SSH’de Simetrik ve Asimetrik Kriptografi

Yaygın bir yanılgı, SSH’nin tüm trafik için “genel anahtar şifrelemesi kullandığı”dır. Bu doğru değildir. Roller birbirinden farklıdır:

SSH ile Eski Uzak Erişim Protokollerinin Karşılaştırması

SSH Anahtar Çiftleri Oluşturma

SSH anahtar çiftleri, güvenli ve ölçeklenebilir sunucu erişiminin temelidir. Parola kimlik doğrulaması, kaba kuvvet saldırılarına ve kimlik bilgisi doldurma saldırılarına karşı savunmasızdır; anahtar tabanlı kimlik doğrulama ise değildir.

Doğru Anahtar Algoritmasını Seçme

Ed25519, günümüzdeki en iyi uygulamadır. Curve25519 eliptik eğri kriptografisi kullanır, kompakt 256-bit anahtarlar üretir, eşdeğer güvenlik seviyelerinde RSA’dan daha hızlıdır ve OpenSSH 6.5+ (2014’te yayımlandı) tarafından desteklenir.

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

RSA’yı yalnızca Ed25519’u desteklemeyen eski sistemlerle uyumluluk gerektiğinde kullanın:

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

DSA kullanmayın (1024 bit ile sınırlı, kırılmış) veya NIST eğrileriyle ECDSA kullanmayın (NIST eğrisi parametre kökeni hakkında endişeler). Ed25519, yeni dağıtımlar için tartışmasız tercihtir.

Anahtar Oluşturma Adım Adım

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Aşağıdakiler için istem alacaksınız:

• Dosya konumu — varsayılan ~/.ssh/id_ed25519‘dır. Çoklu anahtar ortamları için varsayılanı kabul edin veya özel bir yol belirtin.
• Parola — her zaman bir parola belirleyin. Parola, özel anahtarı AES-256-CBC (veya daha yeni OpenSSH ile bcrypt) kullanarak beklemedeyken şifreler. Özel anahtar dosyanız çalınırsa, parola son savunma hattıdır.

Bu işlem iki dosya üretir:

~/.ssh/id_ed25519 — özel anahtar. Bunu asla paylaşmayın. İzinler 600 olmalıdır.
~/.ssh/id_ed25519.pub — genel anahtar. Sunuculara dağıttığınız şey budur.

~/.ssh/config ile Birden Fazla Anahtarı Yönetme
Birden fazla sunucu veya hesabı yönetirken, her bağlantıda bayrak belirtmekten kaçınmak için bir SSH yapılandırma dosyası kullanın:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
Bu yapılandırmayla, ssh prod-web otomatik olarak tam bağlantı parametrelerine genişler.
Genel Anahtarınızı Sunucuya Dağıtma
Yöntem 1: ssh-copy-id (İlk Kurulum için Önerilen)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Bu, genel anahtarı uzak ana bilgisayardaki ~/.ssh/authorized_keys dosyasına ekler ve doğru izinleri otomatik olarak ayarlar.
Yöntem 2: Manuel Dağıtım (ssh-copy-id Kullanılamadığında)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Yöntem 3: Bulut Sağlayıcı Konsolu veya API
Çoğu bulut sağlayıcısı ve barındırma kontrol paneli, örnek sağlama sırasında genel anahtarlar eklemenize izin verir. Bu, otomatik altyapı için doğru yaklaşımdır — anahtar, örnek başlamadan önce mevcut olur ve SSH anahtarlarını dağıtmak için SSH’ye ihtiyaç duyma kısır döngüsünü ortadan kaldırır.
authorized_keys Dosya Biçimi
~/.ssh/authorized_keys dosyasındaki her satır, isteğe bağlı olarak seçeneklerle öneklenmiş bir genel anahtardır:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
restrict seçeneği, o anahtar için port yönlendirmeyi, ajan yönlendirmeyi ve PTY tahsisini devre dışı bırakır — etkileşimli kabuk erişimine sahip olmaması gereken dağıtım anahtarları veya yedekleme otomasyon hesapları için kullanışlıdır.
SSH Sunucusunu Sertleştirme: /etc/ssh/sshd_config
Varsayılan bir OpenSSH kurulumu işlevseldir ancak sertleştirilmemiştir. Aşağıdaki yapılandırma, üretim düzeyinde bir temel çizgiyi temsil eder. Değişiklikleri /etc/ssh/sshd_config dosyasına uygulayın, ardından doğrulayın ve yeniden yükleyin:
sshd -t && systemctl reload sshd
Yeniden yüklemeden önce her zaman sshd -t komutunu çalıştırın — sshd_config dosyasındaki bir sözdizimi hatası çalışan daemon’ı çökertmez, ancak yeniden başlatmadan sonra yeniden başlamasını engeller ve sizi dışarıda bırakır.
Önerilen sshd_config Sertleştirme Bloğu
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Kritik Sertleştirme Kararlarının Açıklaması
PermitRootLogin no — SSH üzerinden root girişi yüksek değerli bir hedeftir. Normal bir kullanıcı kullanın ve sudo ile yetki yükseltin. Belirli bir anahtar aracılığıyla root eşdeğeri erişime kesinlikle ihtiyaç duyuyorsanız (örn. otomasyon için), parola girişimlerini engellerken yalnızca anahtarla root girişine izin vermek için PermitRootLogin prohibit-password kullanın.
AllowTcpForwarding no — Sunucunuz bir kale veya atlama ana bilgisayarı değilse, TCP yönlendirmeyi devre dışı bırakın. Geçerli bir SSH oturumuna sahip bir saldırgan, aksi takdirde sunucunuzu iç ağ kaynaklarına ulaşmak için proxy olarak kullanabilir.
TCPKeepAlive no ile ClientAliveInterval — TCPKeepAlive, TCP katmanında çalışır ve ağ aracıları tarafından görülebilir. ClientAliveInterval, şifreli SSH kanalı üzerinden canlı tutma mesajları gönderir; bu hem daha güvenilir hem de daha gizlidir.
LoginGraceTime 30 — Kimliği doğrulanmamış bir bağlantının sunucu yuvası tuttuğu pencereyi azaltır. Varsayılan 120 saniye aşırıdır.
AllowUsers — Yalnızca meşru olarak SSH erişimine ihtiyaç duyan hesapları beyaz listeye alın. Bu, herhangi bir kimlik doğrulama girişiminden önce çalışan sert bir kapıdır.
Varsayılan SSH Portunu Değiştirme
SSH’yi port 22’den taşımak, hedefli bir saldırgana karşı güvenliği artırmaz — herhangi bir port taraması onu bulacaktır. Ancak yaptığı şey, yalnızca port 22’yi hedef alan otomatik, fırsatçı kaba kuvvet botlarının büyük hacmini ortadan kaldırmaktır. Bu, günlük gürültüsünü ve sunucu yükünü anlamlı ölçüde azaltır.
# In /etc/ssh/sshd_config
Port 2222
Yeniden yüklemeden önce, güvenlik duvarınızda yeni portu açın:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Sunucunuz SELinux çalıştırıyorsa, SELinux port bağlamını da güncellemeniz gerekir:
semanage port -a -t ssh_port_t -p tcp 2222
Sunucuya Bağlanma
Temel Bağlantı
ssh user@your_server_ip
Varsayılan Olmayan Bir Porta Bağlanma
ssh -p 2222 user@your_server_ip
Belirli Bir Anahtarla Bağlanma
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Hata Ayıklama için Ayrıntılı Mod
ssh -vvv user@your_server_ip
-vvv bayrağı, el sıkışmanın, kimlik doğrulama girişiminin ve kanal müzakeresinin her adımını yazdırır. Bir bağlantı beklenmedik şekilde başarısız olduğunda başvurulacak ilk araçtır.
SSH Üzerinden Güvenli Dosya Transferleri
SCP (Güvenli Kopyalama Protokolü)
SCP, basit ve etkileşimsiz bir dosya kopyalama aracıdır. Hızlı ve yaygın olarak kullanılabilir, ancak devam ettirme özelliği yoktur ve sınırlı hata işleme kapasitesine sahiptir.
Yerel bir dosyayı uzak sunucuya kopyalama:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Uzak dosyayı yerel konuma kopyalama:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Özyinelemeli dizin kopyalama:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Not: OpenSSH projesi, OpenSSH 9.0’da eski SCP protokolünü kullanımdan kaldırdı. Modern scp artık varsayılan olarak arka planda SFTP protokolünü kullanmaktadır. Komut arayüzü aynı kalır, ancak temel aktarım daha sağlamdır.
SFTP (SSH Dosya Aktarım Protokolü)
SFTP, dizin listeleme, izin yönetimi ve devam ettirme desteği olan tam özellikli bir dosya aktarım alt sistemidir. Etkileşimli dosya yönetimi için doğru tercihtir.
sftp -P 2222 user@your_server_ip
Etkileşimli oturum içindeki yaygın SFTP komutları:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
SSH Üzerinden rsync (Üretim Önerisi)
Dizinleri senkronize etmek, artımlı yedeklemeler veya büyük veri kümeleri için SSH üzerinden rsync, SCP veya SFTP’den önemli ölçüde daha verimlidir. Tüm dosyaları değil, yalnızca değişen blokları aktarır.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
-z bayrağı, aktarım sırasında sıkıştırmayı etkinleştirir. Zaten sıkıştırılmış veriler için (arşivler, görüntüler) bunu atlayın — sıkıştırılmış verinin sıkıştırılması, aktarım boyutunu azaltmadan CPU’yu boşa harcar.
SSH Port Yönlendirme ve Tünelleme
Port yönlendirme, SSH’nin en güçlü ve az kullanılan özelliklerinden biridir. İnternete doğrudan açık olmayan hizmetlere güvenli şekilde erişmenizi sağlar.
Yerel Port Yönlendirme
Yerel bir portu uzak bir hizmete yönlendirme. Örnek: sunucuda localhost’a bağlı uzak bir MySQL örneğine (port 3306) erişim:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Artık yerel makinenizdeki mysql -h 127.0.0.1 -P 3307, şifreli tünel üzerinden uzak MySQL’e bağlanır.
Uzak Port Yönlendirme
Yerel bir hizmeti uzak sunucuya açma. Web kancalarını test etmek veya yerel bir geliştirme sunucusunu paylaşmak için kullanışlıdır:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Dinamik Port Yönlendirme (SOCKS Proxy)
SSH bağlantısını bir SOCKS5 proxy’sine dönüştürme, rastgele TCP trafiğini sunucu üzerinden yönlendirme:
ssh -D 1080 user@your_server_ip -N
Tarayıcınızı veya uygulamanızı SOCKS5 127.0.0.1:1080 kullanacak şekilde yapılandırın.
SSH Ajanı ve Ajan Yönlendirme
ssh-agent, her bağlantıda parolanızı yeniden girmenize gerek kalmayacak şekilde şifresi çözülmüş özel anahtarları bellekte tutar.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Ajan yönlendirme (ssh -A), uzak bir sunucunun üçüncü bir sunucuda kimlik doğrulamak için yerel ajanınızı kullanmasına izin verir. Bu, kale ana bilgisayar mimarileri için kullanışlıdır, ancak risk taşır: ara sunucudaki bir root kullanıcısı, yönlendirilmiş ajan soketinizi kullanabilir. Bunun yerine ProxyJump‘ı tercih edin:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump, TCP bağlantısını ajanınızı ona açmadan kale üzerinden yönlendirir.
Yaygın SSH Sorunlarını Giderme
Bağlantı Reddedildi (ssh: connect to host ... port 22: Connection refused)
Sistematik teşhis:

SSH daemon’ının çalıştığını doğrulayın: systemctl status sshd

• Dinleme portunu onaylayın: ss -tlnp | grep sshd
• Güvenlik duvarı kurallarını kontrol edin: ufw status veya iptables -L -n | grep 22
• Sunucunun ağ düzeyinde erişilebilir olduğunu doğrulayın: ping your_server_ip
• Bir bulut sağlayıcısı kullanıyorsanız, sağlayıcı konsolundaki güvenlik grubu veya ağ ACL kurallarını kontrol edin.

İzin Reddedildi (publickey)

Bu, en yaygın SSH hatasıdır. Bu kontrol listesini takip edin:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

İzinlerin ötesindeki yaygın nedenler:

• authorized_keys dosyası yanlış anahtarı içeriyor (örn. .pub dosyası yerine özel anahtarı kopyaladınız).
• sshd_config dosyasındaki StrictModes yes (varsayılan), ana dizin izinleri çok açıksa bağlantıları reddeder — izin verilen maksimum değer chmod 755 ~‘dir.
• sshd_config dosyasındaki AllowUsers veya AllowGroups, bağlanan kullanıcıyı dışarıda bırakıyor.
• SELinux, ~/.ssh/ dosyasına erişimi engelliyor — ausearch -m avc -ts recent dosyasını kontrol edin.

SSH Bağlantı Zaman Aşımı

# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

ClientAliveInterval, her 60 saniyede bir şifreli kanal üzerinden boş bir paket gönderir. ClientAliveCountMax ardışık kaçırılan yanıttan sonra sunucu bağlantıyı sonlandırır. Bu, hayalet oturumların birikmesini önler.

Ana Bilgisayar Anahtarı Doğrulaması Başarısız

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Bu uyarı, sunucunun ana bilgisayar anahtarının artık ~/.ssh/known_hosts dosyasında depolananla eşleşmediği anlamına gelir. Meşru nedenler arasında sunucunun yeniden kurulması veya IP adresi yeniden atanması yer alır. Kötü amaçlı nedenler arasında ortadaki adam saldırısı bulunur. Devam etmeden önce araştırın.

Sunucunun meşru olarak yeniden kurulduğunu onayladıysanız:

ssh-keygen -R your_server_ip

Ardından yeniden bağlanın ve kabul etmeden önce yeni ana bilgisayar anahtarı parmak izini sunucu konsolu veya sağlayıcı panosu üzerinden doğrulayın.

SSH için Çok Faktörlü Kimlik Doğrulama

Anahtar tabanlı kimlik doğrulama güçlüdür, ancak TOTP (Zamana Dayalı Tek Kullanımlık Parola) ikinci faktörü eklemek derinlemesine savunma oluşturur. Özel bir anahtar ve parolası ele geçirilse bile, bir saldırgan TOTP belirteci olmadan kimlik doğrulayamaz.

Sunucuya libpam-google-authenticator kurun ve yapılandırın:

apt install libpam-google-authenticator
google-authenticator

Ardından PAM ve sshd_config yapılandırın:

# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

AuthenticationMethods publickey,keyboard-interactive ile bir kullanıcı geçerli bir anahtar VE bir TOTP kodu sağlamalıdır. Bu, yüksek değerli sunucular için doğru üretim yapılandırmasıdır.

SSH Sertifika Yetkilisi: Anahtar Yönetimini Ölçeklendirme

Onlarca sunucu ve birden fazla yöneticinin bulunduğu ortamlarda, bireysel authorized_keys girişlerini yönetmek operasyonel olarak sürdürülemez hale gelir. SSH sertifikaları bunu çözer.

Bir SSH Sertifika Yetkilisi (CA), kullanıcı ve ana bilgisayar anahtarlarını imzalar. Sunucular, bireysel kullanıcı anahtarları yerine CA’nın genel anahtarına güvenir. Yeni bir yönetici eklemek, yalnızca genel anahtarlarını imzalamayı gerektirir — hiçbir sunucunun authorized_keys dosyasında değişiklik yapılmaz.

# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub

Her sunucuda CA için güveni yapılandırın:

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Büyük ölçekli altyapının (bulut sağlayıcıları ve işletmeler dahil) sunucu başına anahtar yönetimi olmadan SSH erişimini bu şekilde yönettiği budur.

Pratik Karar Matrisi: Kullanım Durumuna Göre SSH Yapılandırması

Kullanım Durumu	Anahtar Türü	Port	Parola Kimlik Doğrulaması	Root Girişi	Yönlendirme	MFA

—	—	—	—	—	—	—

Kişisel VPS	Ed25519	2222+	Devre dışı	Yasak	Devre dışı	İsteğe bağlı

Üretim web sunucusu	Ed25519	Varsayılan dışı	Devre dışı	Hayır	Devre dışı	Zorunlu

Kale / atlama ana bilgisayarı	Ed25519	22 veya özel	Devre dışı	Hayır	Kontrollü	Zorunlu

CI/CD otomasyonu	Ed25519 (dağıtım anahtarı)	Varsayılan dışı	Devre dışı	Hayır	Devre dışı	Hayır (yalnızca anahtar)

Veritabanı sunucusu	Ed25519	Varsayılan dışı	Devre dışı	Hayır	Yalnızca yerel	Zorunlu

Geliştirme sunucusu	Ed25519	Varsayılan veya özel	İsteğe bağlı	Hayır	İsteğe bağlı	İsteğe bağlı

AlexHost Altyapısında SSH Kurulumu

AlexHost üzerinden bir VPS veya dedicated sunucu sağladığınızda, SSH erişimi varsayılan olarak yapılandırılmıştır. İlk root parolası sağlama e-postası aracılığıyla iletilir ve önerilen ilk işlem şunlardır:

1. Root olarak giriş yapın, root olmayan bir yönetici kullanıcı oluşturun ve genel anahtarınızı o kullanıcının ~/.ssh/authorized_keys dosyasına ekleyin.
2. Yukarıda belgelenen sshd_config sertleştirme temel çizgisini uygulayın.
3. Parola kimlik doğrulamasını ve root girişini devre dışı bırakın.
4. Operasyonel olarak uygulanabilir olduğu durumlarda, güvenlik duvarınızı SSH erişimini bilinen IP aralıklarıyla kısıtlayacak şekilde yapılandırın.

SSH’nin yanı sıra grafiksel bir yönetim katmanı tercih ediyorsanız, AlexHost’un cPanel’li VPS ve VPS Kontrol Panelleri seçenekleri, tam yönetimsel kontrol için SSH’yi kullanılabilir bırakırken yaygın görevler için bir web arayüzü sağlar.

Aynı sunucuda çalışan web uygulamalarını güvence altına almanız gereken ortamlar için, SSH sertleştirmeyi düzgün yapılandırılmış bir SSL sertifikası ile eşleştirmek hem yönetimsel hem de uygulama aktarım katmanlarını kapsar.

Teknik Temel Çıkarımlar Kontrol Listesi

SSH yapılandırmanızı üretime hazır saymadan önce aşağıdakilerin her birini doğrulayın:

Anahtar Yönetimi

• Özel anahtarlar minimum Ed25519 veya RSA-4096 kullanıyor
• Tüm özel anahtarlar güçlü bir parola ile korunuyor
• ~/.ssh/ dizininin 700 izinleri var; authorized_keys dosyasının 600 izinleri var
• Dağıtım anahtarları, uygulanabilir olduğu durumlarda restrict ve command= seçeneklerini kullanıyor
• Anahtar rotasyon takvimi belgelenmiş ve uygulanıyor

Sunucu Yapılandırması

• PasswordAuthentication no ayarlanmış ve etkin
• PermitRootLogin no veya prohibit-password uygulanıyor
• SSH, güvenlik duvarı kuralları güncellenmiş şekilde varsayılan olmayan bir portta çalışıyor
• AllowUsers veya AllowGroups, adlandırılmış hesaplara erişimi kısıtlıyor
• LoginGraceTime 30 saniye veya daha az olarak ayarlanmış
• Her yapılandırma değişikliğinden sonra sshd -t hatasız geçiyor

Kriptografik Sertleştirme

• KexAlgorithms, diffie-hellman-group1-sha1 ve diffie-hellman-group14-sha1‘ü dışarıda bırakıyor
• Ciphers, 3des-cbc, arcfour ve blowfish-cbc‘ü dışarıda bırakıyor
• MACs yalnızca -etm (şifrele-sonra-MAC) varyantlarını kullanıyor

Operasyonel Güvenlik

• SSH kimlik doğrulama günlükleri izleniyor (/var/log/auth.log veya journalctl -u sshd)
• fail2ban veya eşdeğeri, tekrarlanan kimlik doğrulama başarısızlıklarını engelleyecek şekilde yapılandırılmış
• Ana bilgisayar anahtarı parmak izleri kaydedilmiş ve doğrulama için bant dışında depolanmış
• Üretim sistemlerindeki tüm etkileşimli kullanıcı oturumları için MFA etkin
• Beşten fazla sunucu veya üçten fazla yöneticisi olan ortamlar için SSH CA kullanımda

SSS

SSH anahtarları ile SSH sertifikaları arasındaki fark nedir?

SSH anahtarları, her sunucunun kullanıcının genel anahtarını authorized_keys dosyasında depolamasını gerektirir. SSH sertifikaları bir Sertifika Yetkilisi tarafından imzalanır; sunucular bireysel anahtarlar yerine CA’ya güvenir. Sertifikalar, sunucu başına anahtar yönetimi olmadan büyük filolara ölçeklenir ve son kullanma sürelerini destekler, bu da iptali kolaylaştırır.

Anahtar doğru olduğunda bile neden Permission denied (publickey) görünür?

En yaygın nedenler, ~/.ssh/ (700 olmalı) veya authorized_keys (600 olmalı) üzerindeki yanlış dosya izinleri, dünya tarafından yazılabilir bir ana dizin (StrictModes tarafından engellenir) veya bağlanan hesabı dışarıda bırakan sshd_config dosyasındaki bir AllowUsers yönergesidir. Belirli red nedeni için sunucudaki journalctl -u sshd dosyasını kontrol edin.

SSH portunu 22’den değiştirmek gerçek bir güvenlik önlemi midir?

Port 22’yi hedef alan otomatik fırsatçı saldırıları ortadan kaldırır; bu da günlük gürültüsünü ve başarısız kimlik doğrulama girişimlerini anlamlı ölçüde azaltır. Hedefli bir saldırgana karşı, port taraması yapan birine karşı koruma sağlamaz. Anlamlı güvenlik iyileştirmesi için fail2ban, yalnızca anahtar kimlik doğrulaması ve güvenlik duvarı IP izin listesiyle birleştirilmelidir.

İstemci tarafında statik bir IP adresi olmadan SSH kullanabilir miyim?

Evet. Anahtar tabanlı kimlik doğrulama, sabit bir istemci IP’si gerektirmez. IP’ye göre kısıtlamak istiyorsanız, from= dosyasındaki authorized_keys seçeneğini veya güvenlik duvarı kurallarını kullanın. Dinamik IP’ler için, SSH’yi tüm internete açmak yerine bağlanmadan önce kararlı bir ağ kimliği oluşturmak amacıyla bir VPN kullanmayı düşünün.

Kilitlendiğimde SSH erişimini kurtarmanın en güvenli yolu nedir?

Barındırma sağlayıcınızın bant dışı konsolu (VNC, IPMI veya KVM over IP) aracılığıyla sunucuya erişin. Oradan dosya sistemini bağlayın, sshd_config veya authorized_keys sorununu düzeltin ve SSH daemon’ını yeniden başlatın. AlexHost VPS ve dedicated sunucu planlarında, sağlayıcı konsolu istemci portalı üzerinden kullanılabilir ve SSH’nin çalışır durumda olmasına bağlı değildir.