Aynı bilgisayarda iş, kişisel proje ve farklı sunucular için birkaç SSH anahtarı bulunabilir. Bağlantı beklediğiniz anahtar yerine başka kimlikleri denediğinde, sunucudaki parolayı değiştirmek sorunu açıklamaz. Kullanıcı adı, bağlantı profili ve anahtar seçimi birlikte incelenmelidir. Temel koruma adımları için VDS güvenlik rehberi tamamlayıcıdır; burada sunucu politikasını gevşetmeden istemciyi daraltıyoruz.
Hangi hesabın hangi anahtarı kullandığını yazın
Sunucu adı, oturum açacağınız kullanıcı ve o kullanıcı için yetkilendirilmiş açık anahtarın parmak izini not edin. Anahtar dosyasının adı tek başına kimlik kanıtı değildir; aynı adla farklı dosyalar olabilir. Özel anahtarın içeriğini panoya veya destek mesajına koymayın. Açık ve özel anahtar ayrımını ekip içinde netleştirmek yanlış dosya gönderimini önler.
İstemci yapılandırması ne söylüyor?
OpenSSH istemci yapılandırma belgesi, IdentityFile ile anahtar dosyasını ve IdentitiesOnly ile sunulacak kimliklerin sınırlandırılmasını açıklar. Örneğin ssh -o IdentitiesOnly=yes -i anahtar_dosyasi [email protected] yalnız yetkili olduğunuz hedef için kontrollü bir denemedir. Bu örnek dosya oluşturmaz; gerçek anahtar yolunuzu ve kullanıcıyı siz belirlemelisiniz. Host kimlik uyarısı varsa önce onu doğrulayın.
Anahtar seçimini test etmeden önce mevcut bağlantı profilinin bir kopyasını saklayın. Yalnız bu sunucuya ait eşleştirmeyi değiştirin; genel yıldız kuralı bütün bağlantıları etkileyebilir. Bir kurumsal anahtar yöneticisi veya donanım anahtarı kullanılıyorsa kendi kendinize devre dışı bırakmak yerine kurumun yöntemini izleyin. Aynı hedefe bağlanan başka uygulamanın farklı SSH istemcisi kullanabileceğini de kaydedin.
İstemci ve sunucu tarafını karıştırmayın
Doğru anahtarın sunulması erişimin kesin verileceğini göstermez. Kullanıcıya yetki tanınmamış, açık anahtar farklı hesaba eklenmiş veya ek doğrulama gerekli olabilir. SSH iki faktörlü doğrulama devredeyse anahtarın ardından başka adım beklenmesi tek başına hata değildir. Geçici çözüm diye parola girişini herkese açmayın, dosya izinlerini topluca gevşetmeyin veya başarısız deneme sınırlarını kaldırmayın.
SFTP uygulamasını da aynı bilgilerle kontrol edin
Terminal çalışıyor, dosya aktarım uygulaması bağlanmıyorsa kullanıcı, port ve anahtar seçiminin aynı olduğunu karşılaştırın. FTP ve SFTP bağlantı rehberi protokol karışıklığını ayırır. Anahtar dosyasını yanlış uygulamaya taşımadan önce desteklenen biçimi üretici belgesinden doğrulayın. VDS kapasitesi artırmak istemcinin yanlış kimlik göndermesini düzeltmez.
Destek kaydında yalnız hata metni, hedef kullanıcı, istemci adı ve gizli bilgileri çıkarılmış bağlantı seçeneği bulunmalıdır. Ayrıntılı hata ayıklama çıktısı sistem adları ve yollar içerebilir; herkese açık paylaşmayın. Sorun çözüldüğünde hangi anahtarın hangi sistem için kullanılacağını güvenli envantere eklemek sonraki karışıklıkları azaltır.
Ekipte anahtar değişikliği yapıldıysa eski ve yeni kimliğin hangi kullanıcıya ait olduğunu açıkça belgeleyin. Aynı dosya adını kullanan yeni anahtarı sessizce eskisinin üzerine yazmak diğer bağlantıları bozabilir. Önce yetkili hesabı ve değişiklik kapsamını doğrulayın; anahtar yenileme ile sunucu host kimliği değişikliğinin ayrı işlemler olduğunu işletim notunda da belirtin.
Sıkça Sorulan Sorular
Özel anahtarımı destek ekibine göndermeli miyim?
Hayır. Gerekirse yalnız açık anahtar veya parmak izi güvenli yöntemle paylaşılır; özel anahtar paylaşılmaz.
IdentitiesOnly sunucunun güvenliğini düşürür mü?
Bu istemcinin hangi kimlikleri sunacağını sınırlar; sunucudaki kimlik doğrulama politikasını kapatmaz.
Doğru anahtar varsa kullanıcı adı önemsiz mi?
Hayır. Açık anahtarın yetkilendirildiği hesapla bağlanmanız gerekir.
Bütün anahtarları silerek deneyeyim mi?
Hayır. Önce belirli bağlantı için anahtar seçimini daraltın; diğer sistemlere erişimi bozacak toplu silme yapmayın.