Sunucunuza veya Hesabınıza Nasıl Giriş Yapılır: SSH, Kontrol Panelleri ve Güvenli Erişim Yöntemleri

Sunucu kimlik doğrulaması, uzak bir sisteme, hosting kontrol paneline veya çevrimiçi hizmete yetkili erişim sağlamak için kimliğinizi doğrulama sürecidir. Üç baskın yöntem şunlardır: parola tabanlı SSH, SSH anahtar çifti kimlik doğrulaması ve web tabanlı kontrol paneli girişi — her birinin her yöneticinin anlaması gereken kendine özgü güvenlik profilleri, kullanım senaryoları ve hata modları vardır.

İster tek bir VPS Hosting örneğini ister bir grup bare-metal makineyi yönetiyor olun, bu giriş yöntemlerinde uzmanlaşmak operasyonel güvenlik duruşunuzu doğrudan belirler. Bu kılavuz her yöntemi derinlemesine ele almakta olup her birinin teknik mekanizmalarını, belgelerin nadiren bahsettiği gerçek dünya tuzaklarını ve hemen uygulayabileceğiniz bir sertleştirme kontrol listesini kapsamaktadır.

SSH Girişi: Parola Kimlik Doğrulaması ile Anahtar Tabanlı Kimlik Doğrulaması

SSH (Secure Shell Protocol, RFC 4253), istemciniz ile uzak sunucu arasında varsayılan olarak TCP port 22 üzerinden şifreli bir tünel oluşturur. Bir kimlik doğrulama yöntemi seçmeden önce, her birinin gerçekte neye karşı koruma sağladığını anlayın.

Herhangi Bir SSH Oturumu İçin Ön Koşullar

• `sshd` çalışan ve port 22’ye (veya özel bir porta) erişilebilen uzak bir sunucu
• Bir SSH istemcisi: Linux/macOS’ta yerel `ssh`, Windows için OpenSSH (Windows 10/11’e yerleşik) veya eski Windows ortamları için PuTTY
• Geçerli kimlik bilgileri: bir kullanıcı adı/parola çifti veya yapılandırılmış bir anahtar çifti

Kullanıcı Adı ve Parola ile Giriş Yapma

Terminalinizi açın ve şunu çalıştırın:

“`bash

ssh username@server_ip_address

“`

`username` yerine sistem hesap adınızı, `server_ip_address` yerine sunucunun IPv4, IPv6 veya tam nitelikli alan adını (FQDN) yazın.

“`bash

ssh deploy@203.0.113.45

“`

Sunucu SSH’yi standart dışı bir portta çalıştırıyorsa (yaygın bir sertleştirme uygulaması):

“`bash

ssh -p 2222 deploy@203.0.113.45

“`

Arka planda neler oluyor: İstemci ve sunucu bir şifre paketi üzerinde anlaşır (örn. `chacha20-poly1305` veya `aes256-gcm`), geçici Diffie-Hellman anahtarları değiştirir ve ancak bundan sonra parolanızı — şifreli olarak — iletir. Parolanın kendisi hiçbir zaman düz metin olarak iletilmez.

Kritik tuzak: Yeni bir sunucuya ilk bağlantınızda SSH, bir host anahtar parmak izi sunar ve bunu onaylamanızı ister. Asla körü körüne `yes` yazmayın. Parmak izini hosting sağlayıcınızın kontrol paneline veya güvenilir bir bant dışı kanala karşı doğrulayın. Sahte bir parmak izini kabul etmek, ortadaki adam saldırısı için giriş noktasıdır.

SSH Anahtar Çiftleriyle Giriş Yapma

SSH anahtar kimlik doğrulaması, parolayı kriptografik bir zorlukla değiştirir. Sunucu genel anahtarınızı tutar; siz özel anahtarı tutarsınız. Kimlik doğrulama yalnızca istemciniz, özel anahtarı hiçbir zaman iletmeden sahip olduğunu kanıtlayabildiğinde başarılı olur.

Adım 1 — Bir anahtar çifti oluşturun:

“`bash

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

“`

Yeni dağıtımlar için RSA-4096 yerine Ed25519‘u tercih edin. Ed25519 anahtarları daha kısa, doğrulaması daha hızlı ve eşdeğer veya üstün güvenlik sunar. RSA-4096’yı yalnızca uzak sistem Ed25519’u desteklemediğinde kullanın (modern dağıtımlarda nadirdir).

“`bash

RSA fallback for legacy systems

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

“`

Anahtarı varsayılan yola (`~/.ssh/id_ed25519`) kaydedin ve güçlü bir parola belirleyin. Parola, özel anahtarınızı diskte şifreler — iş istasyonunuz ele geçirilirse, bir saldırgan yine de parolasız şifreli bir anahtarı kullanamaz.

Adım 2 — Genel anahtarı sunucuya dağıtın:

“`bash

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip_address

“`

Bu, genel anahtarınızı sunucudaki `~/.ssh/authorized_keys` dosyasına doğru izinlerle (`600`) ekler. `ssh-copy-id` kullanılamıyorsa:

“`bash

cat ~/.ssh/id_ed25519.pub | ssh username@server_ip_address

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

cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

“`

Adım 3 — Bağlanın:

“`bash

ssh username@server_ip_address

“`

Parola istemi görünmez. Bir parola belirlediyseniz, yerel SSH ajanınız bunu önbelleğe alabilir:

“`bash

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/id_ed25519

“`

Uç durum — birden fazla anahtar: Sunucu çok fazla denemeden sonra yanlış anahtarı reddedip kimlik doğrulama hatalarına yol açmamak için belirli anahtarları belirli hostlara atamak üzere `~/.ssh/config` kullanın:

“`

Host prod-server

HostName 203.0.113.45

User deploy

IdentityFile ~/.ssh/id_ed25519_prod

Port 2222

“`

SSH Parola ile Anahtar Kimlik Doğrulaması: Doğrudan Karşılaştırma

Herhangi bir üretim Dedicated Server ortamında, anahtarları dağıttıktan sonra parola kimlik doğrulamasını tamamen devre dışı bırakın:

“`bash

/etc/ssh/sshd_config

PasswordAuthentication no

PubkeyAuthentication yes

PermitRootLogin prohibit-password

“`

Daemon’ı yeniden yükleyin: `systemctl reload sshd`

Web Tabanlı Kontrol Panellerine Giriş Yapma

Web tabanlı kontrol panelleri — cPanel, Plesk, DirectAdmin, Webmin ve özel sağlayıcı kontrol panelleri — sunucu yönetimini bir tarayıcı arayüzü üzerinden sunar. Doğrudan kabuk erişimi olmadan hosting yöneten kullanıcılar için birincil arayüzdür.

Standart Giriş Prosedürü

1. Bir tarayıcı açın ve panel URL’sine gidin. Yaygın varsayılanlar:

• cPanel: `https://yourdomain.com:2083` (SSL) veya `http://yourdomain.com:2082`
• Plesk: `https://yourdomain.com:8443`
• Webmin: `https://yourdomain.com:10000`
• DirectAdmin: `https://yourdomain.com:2222`

1. Hosting sağlayıcınız tarafından sağlanan veya sunucu hazırlama sırasında belirlenen kullanıcı adı ve parolayı girin.
2. İki Faktörlü Kimlik Doğrulama (2FA) etkinleştirilmişse, kimlik doğrulayıcı uygulamanızdan (Google Authenticator, Aegis veya Authy) TOTP kodunu girin.

Kontrol Panellerinde İki Faktörlü Kimlik Doğrulama

2FA, çalınan kimlik bilgilerini geçersiz kılan zamana dayalı tek kullanımlık parola (TOTP) katmanı ekler. Bir saldırgan cPanel parolanızı kimlik avı kampanyası veya kimlik bilgisi veritabanı sızıntısı yoluyla ele geçirse bile, dönen 6 haneli kod olmadan giriş yapamaz.

cPanel’de kurulum:

• Güvenlik > İki Faktörlü Kimlik Doğrulama bölümüne gidin
• QR kodunu kimlik doğrulayıcı uygulamanızla tarayın
• Test koduyla doğrulayın ve yedek kodları güvenli bir konumda saklayın (parola yöneticisi, yapışkan not değil)

Kritik operasyonel not: Yedek kodlarınızı çevrimdışı saklayın. Kimlik doğrulayıcı cihazınıza erişimi kaybederseniz ve yedek kodlarınız yoksa, kurtarma işlemi hosting sağlayıcınızla iletişime geçmeyi ve kimlik doğrulama sürecini tamamlamayı gerektirir — bu süreç bir olay sırasında saatler alabilir.

cPanel ile VPS kullanıyorsanız, 2FA’nın yalnızca root yöneticisi için değil, tüm bayi ve kullanıcı hesapları için WHM düzeyinde zorunlu kılındığından emin olun.

Kontrol Paneli Erişimi İçin Tarayıcı Güvenliği

• Her zaman HTTPS kilidini ve sertifikanın Ortak Adının alan adınızla eşleştiğini doğrulayın. Kontrol panelinizde geçerli bir SSL Sertifikası, güvenilmeyen ağlarda kimlik bilgisi ele geçirilmesini önler.
• VPN olmadan genel Wi-Fi üzerinden kontrol panellerine giriş yapmaktan kaçının.
• Uzantılardan oturum belirteci sızıntısını önlemek için yönetimsel girişlerde özel bir tarayıcı profili veya gizli tarama oturumu kullanın.

Çevrimiçi Hesaplara ve E-posta Hizmetlerine Giriş Yapma

Web tabanlı hizmetler için — e-posta platformları, bulut kontrol panelleri, faturalama portalları — kimlik doğrulama akışı standartlaştırılmıştır ancak güvenlik etkileri önemli ölçüde farklılık gösterir.

Standart Web Giriş Akışı

1. Hizmetin giriş sayfasına gidin (yer imlerine ekleyin — giriş sayfalarına e-postayla gelen bağlantıları asla takip etmeyin)
2. Kullanıcı adınızı, e-posta adresinizi veya hesap tanımlayıcınızı girin
3. Parolanızı girin
4. Herhangi bir 2FA zorluğunu tamamlayın (TOTP, donanım anahtarı veya SMS — azalan güvenlik sırasına göre)

E-posta Hosting hizmetleri kullanan kuruluşlar için, webmail erişiminin (Roundcube, Horde, SquirrelMail) yalnızca HTTPS üzerinden sunulduğundan ve hesapların sunucu düzeyinde güçlü parola politikalarını uyguladığından emin olun.

Parola Hijyeni: “Güçlü” Gerçekte Ne Anlama Gelir

Parola yöneticisi tarafından oluşturulan, rastgele 20 karakterlik bir dize, insan tarafından hatırlanabilir herhangi bir paroladan kategorik olarak daha güçlüdür. NIST SP 800-63B yönergeleri (2024’te güncellendi) açıkça şunları önermektedir:

• Karmaşıklık yerine uzunluk: 20 karakterlik rastgele bir parola ifadesi, karmaşık ama kısa parolaları dakikalar içinde kıran kaba kuvvet saldırılarını engeller
• Şüpheli bir ihlal olmadıkça zorunlu periyodik rotasyon yok — zorla rotasyon öngörülebilir kalıplara yol açar (`Password1!` → `Password2!`)
• İhlal veritabanlarına karşı kontrol edin: HaveIBeenPwned gibi hizmetler milyarlarca ele geçirilmiş parolanın listelerini tutar; API’lerini veya ihlal izleme özelliğine sahip bir parola yöneticisini kullanın

Yaygın Giriş Hataları ve Nasıl Teşhis Edilir

SSH Bağlantısı Reddedildi

`ssh: connect to host 203.0.113.45 port 22: Connection refused`

Teşhis yolu:

1. `sshd`’nin çalıştığını doğrulayın: `systemctl status sshd`
2. Güvenlik duvarı kurallarını kontrol edin: `ufw status` veya `iptables -L -n | grep 22`
3. Doğru portu onaylayın — sunucu standart dışı bir SSH portu kullanıyor olabilir
4. `fail2ban` veya `sshguard`’nin tekrarlanan başarısız denemelerden sonra IP’nizi yasaklayıp yasaklamadığını kontrol edin: `fail2ban-client status sshd`

İzin Reddedildi (Genel Anahtar)

`Permission denied (publickey).`

Yaygın nedenler:

• Yanlış anahtar belirtilmiş — hangi anahtarın sunulduğunu görmek için ayrıntılı çıktı için `ssh -v` kullanın
• `~/.ssh/authorized_keys` üzerinde yanlış izinler (`600` olmalı) veya `~/.ssh/` dizini (`700` olmalı)
• `authorized_keys` dosyası, kopyala-yapıştır sırasında satır kaydırma bozulmasından dolayı anahtarı birden fazla satırda içeriyor
• `sshd_config`’de `AuthorizedKeysFile` varsayılan dışı bir yola işaret ediyor

Hesap Kilitleme

Tekrarlanan başarısız girişler birden fazla katmanda kilitleme mekanizmalarını tetikler: uygulama düzeyi (cPanel, Plesk), işletim sistemi düzeyi (PAM’ın `pam_faillock`’si) ve güvenlik duvarı düzeyi (`fail2ban`). IP engelini kaldırmak için hosting sağlayıcınızın desteğiyle iletişime geçin veya konsol/KVM erişiminiz varsa IP’nizi doğrudan engelini kaldırın:

“`bash

fail2ban-client set sshd unbanip YOUR_IP_ADDRESS

“`

Süresi Dolmuş veya İptal Edilmiş SSH Anahtarı

SSH anahtarlarının varsayılan olarak yerleşik bir son kullanma tarihi yoktur, ancak `authorized_keys`’dan kaldırılarak fiilen iptal edilebilirler. Anahtarınız aniden çalışmayı durdurursa:

• Genel anahtarın sunucudaki `~/.ssh/authorized_keys` dosyasında hâlâ mevcut olduğunu doğrulayın
• Sunucunun `sshd_config`’ının `AllowUsers` veya `AllowGroups`’ı kısıtlamak için güncellenip güncellenmediğini kontrol edin
• Anahtarın otomatik bir gizli yönetim sistemi (Vault, AWS Secrets Manager) tarafından döndürülmediğini onaylayın

Sunucu Girişi İçin Güvenlik Sertleştirme Kontrol Listesi

Bu önlemleri yönettiğiniz her sunucuya uygulayın:

• Root SSH girişini devre dışı bırakın (`PermitRootLogin no` veya `prohibit-password`)
• SSH anahtarlarını dağıttıktan sonra parola kimlik doğrulamasını devre dışı bırakın
• Otomatik tarayıcı gürültüsünü azaltmak için varsayılan SSH portunu değiştirin (gizlilik yoluyla güvenlik, gerçek sertleştirmenin yerini tutmaz)
• SSH ve kontrol paneli giriş uç noktaları için agresif eşiklerle `fail2ban` dağıtın
• Tüm web tabanlı kontrol panellerinde 2FA’yı zorunlu kılın
• Eski çalışanlara veya hizmet dışı bırakılmış sistemlere ait anahtarları kaldırmak için `authorized_keys`’ı düzenli olarak denetleyin
• 5’ten fazla yöneticisi olan ekipler için ham anahtarlar yerine (dahili bir CA aracılığıyla) SSH sertifikaları kullanın — sertifikalar son kullanma tarihini ve iptali yerel olarak destekler
• Anormal giriş kalıpları için `/var/log/auth.log` (Debian/Ubuntu) veya `/var/log/secure` (RHEL/CentOS) izleyin
• `sshd_config`’daki `AllowUsers user@trusted_ip` veya güvenlik duvarı kurallarını kullanarak SSH erişimini IP’ye göre kısıtlayın

Hosting seçeneklerini değerlendiriyor ve tüm bu sertleştirme önlemlerini kutudan çıkar çıkmaz destekleyen bir platform istiyorsanız, ekibinizin iş akışına uyan bir arayüz bulmak için mevcut VPS Kontrol Panellerini inceleyin.

Karar Matrisi: Hangi Giriş Yöntemini Kullanmalısınız?

Pratik Temel Çıkarımlar

• Kamuya açık bir SSH sunucusunda asla parola kimlik doğrulaması kullanmayın. Port 22’ye yönelik otomatik kaba kuvvet saldırılarının hacmi, parola gücünden bağımsız olarak bunu bir risk haline getirir.
• Ed25519, yeni SSH anahtar oluşturma için mevcut en iyi uygulamadır. RSA-4096 yalnızca eski uyumluluk için kabul edilebilir.
• `~/.ssh/config` dosyası yeterince kullanılmıyor. Host takma adlarını, portları ve anahtar yollarını orada tanımlamak en yaygın SSH bağlantı hatalarını ortadan kaldırır.
• Üretim verilerini veya müşteri hesaplarını barındıran herhangi bir sunucu için kontrol panellerinde 2FA zorunludur.
• İlk bağlantıda host anahtar parmak izlerini doğrulayın. Hosting sağlayıcınız bunları kontrol panelinde yayımlamalıdır.
• 2FA için yedek kodlar çevrimdışı saklanmalıdır — yedek kodlar olmadan kimlik doğrulayıcınıza erişimi kaybetmek, sağlayıcınızla tam bir kimlik doğrulama sürecini gerektirir.
• Erişimi düzenli olarak denetleyin. Eski anahtarları kaldırın, etkin olmayan hesapları devre dışı bırakın ve giriş günlüklerini en az aylık olarak inceleyin.

Sıkça Sorulan Sorular

Uzak bir sunucuya giriş yapmanın en güvenli yolu nedir?

Ed25519 anahtarları kullanan SSH anahtar çifti kimlik doğrulaması, özel anahtarda güçlü bir parola ve `sshd_config`’da `PasswordAuthentication no` ile birleştirilmiş. Ekipler için dahili bir CA tarafından verilen SSH sertifikaları, statik anahtar çiftlerinin sahip olmadığı son kullanma tarihi ve iptal özelliklerini ekler.

Anahtarımı kopyaladığım hâlde SSH neden “İzin reddedildi (genel anahtar)” diyor?

En yaygın nedenler yanlış dosya izinleridir (`~/.ssh/` `700` olmalı, `authorized_keys` `600` olmalı), istemci tarafından yanlış anahtarın sunulması veya kopyala-yapıştırdan kaynaklanan `authorized_keys` dosyasındaki satır kaydırma bozulmasıdır. Tam olarak hangi anahtarın denendiğini ve neden reddedildiğini görmek için `ssh -vvv user@host` çalıştırın.

SSH anahtarlarını ve 2FA’yı aynı anda kullanabilir miyim?

Evet. `sshd_config`’da `AuthenticationMethods publickey,keyboard-interactive` ayarlayın ve PAM tabanlı bir TOTP modülü yapılandırın (`libpam-google-authenticator` gibi). Kullanıcının geçerli bir anahtar sunması ve ardından TOTP zorluğunu geçmesi gerekir — her iki faktör de zorunludur.

Parola kimlik doğrulamasını devre dışı bıraktıktan sonra sunucuma erişimim kilitlenirse ne yapmalıyım?

Hosting sağlayıcınızın bant dışı konsolu (KVM, IPMI veya VNC) aracılığıyla sunucuya erişin. Oradan genel anahtarınızı `authorized_keys`’a yeniden ekleyebilir, `sshd_config`’ı düzeltebilir veya erişimi yeniden kazanmak için geçici olarak parola kimlik doğrulamasını yeniden etkinleştirebilirsiniz.

SSH portuma yönelik kaba kuvvet saldırılarını nasıl önlerim?

Belirli sayıda başarısız kimlik doğrulama denemesinden sonra IP’leri yasaklamak için `fail2ban`’ı yükleyin ve yapılandırın. Ayrıca güvenlik duvarı kurallarını (`ufw allow from trusted_ip to any port 22`) kullanarak SSH erişimini bilinen IP adresleriyle kısıtlayın ve otomatik tarayıcı trafiğinin büyük çoğunluğunu ortadan kaldırmak için SSH’yi standart dışı bir porta taşımayı düşünün.