SSH anahtar tabanlı kimlik doğrulaması: known_hosts vs yetkili_ anahtarlar

Linux'ta ssh anahtarlarını kurma hakkında bir şeyler okudum ve bazı sorularım var. Yanlışsam düzelt…

Diyelim ki tr-lgto sunucusu ssh kullanarak tr-mdm sunucusuna bağlanmak istiyor. Bunun gerçek tr-mdm olduğundan emin olmak istiyorsak known_hosts, tr-mdm'de bir çift anahtar üretiriz ve genel anahtarı tr-lgto'ya ekleriz. Eğer tr-mdm gerçek tr-lgto olup olmadığını kontrol etmek isterse, tr-lgto bir keypair oluşturmalı ve genel anahtarı tr-mdm'ye eklemelidir authorized_keys.

Soru 1 : Bilinen_hosts dosyasında kullanıcı alanı yok , sadece IP adresleri ve ana bilgisayar adları var. tr-mdm'de ​​her biri kendi .sshklasörü olan çok sayıda kullanıcı olabilir . Her bir known_hostsdosyaya ortak anahtar eklemeli miyiz ?

Soru 2 : ssh-keyscan -t rsa tr-mdmtr-mdm'nin genel anahtarını döndüreceğini buldum . Bu anahtarın hangi kullanıcıya ait olduğunu nasıl bilebilirim? Ayrıca, genel anahtar, /root/.ssh/bu komutun döndürdüğünden farklıdır. Bu nasıl olabilir?

Sunucu makinesinin kimlik doğrulamasını istemci makineye ve kullanıcının kimlik doğrulamasını sunucu makineye karıştırıyorsunuz.

Sunucu kimlik doğrulaması

SSH bağlantısı kurulurken gerçekleşen ilk şeylerden biri, sunucunun ortak anahtarını istemciye göndermesi ve müşteriye ( özel anahtar şifrelemesi sayesinde ) ilişkili özel anahtarı bildiğini ispatlamasıdır . Bu, sunucunun kimliğini doğrular: protokolün bu kısmı başarılı olursa, istemci, sunucunun onun rolünü yaptığını bilir.

Müşteri, sunucunun bilinen bir sunucu olup olmadığını kontrol edebilir ve bazı hileli sunucunun doğru olanı seçmeye çalışmasını önleyebilir. SSH, sunucunun meşruiyetini doğrulamak için yalnızca basit bir mekanizma sağlar: ~/.ssh/known_hostsistemci makinedeki dosyada zaten bağlı olduğunuz sunucuları hatırlar (ayrıca sistem genelinde bir dosya da vardır /etc/ssh/known_hosts). Bir sunucuya ilk kez bağlandığınızda, sunucu tarafından sunulan genel anahtarın gerçekten bağlanmak istediğiniz sunucunun genel anahtarı olduğunu kontrol etmeniz gerekir. Bağlanmak üzere olduğunuz sunucunun genel anahtarına sahipseniz ~/.ssh/known_hosts, istemciye manuel olarak ekleyebilirsiniz .

Herhangi bir gizli veri göndermeden önce sunucuyu doğrulamak gerekir. Özellikle, kullanıcı doğrulama bir şifre içeriyorsa, şifre doğrulanmamış bir sunucuya gönderilmemelidir.

Kullanıcı doğrulama

Sunucu, yalnızca bir kullanıcının bu hesaba erişme hakkına sahip olduğunu kanıtlayabiliyorsa oturum açmasına izin verir. Sunucunun konfigürasyonuna ve kullanıcının seçimine bağlı olarak, kullanıcı çeşitli kimlik bilgilerinden birini sunabilir (aşağıdaki liste ayrıntılı değildir).

• Kullanıcı, giriş yapmaya çalıştığı hesap için şifreyi sunabilir; Sunucu daha sonra parolanın doğru olduğunu onaylar.
• Kullanıcı bir ortak anahtar sunabilir ve bu ortak anahtarla ilişkilendirilmiş özel anahtara sahip olduğunu kanıtlayabilir. Bu, sunucunun kimliğini doğrulamak için kullanılanla aynı yöntemdir, ancak şimdi kullanıcı kimliğini kanıtlamaya çalışıyor ve sunucu bunları doğrulıyor. Kullanıcı özel anahtarı ve ortak anahtarın hesabın yetki listesinde olduğunu ( ~/.ssh/authorized_keyssunucuda) bildiğini kanıtlarsa, oturum açma girişimi kabul edilir .
• Başka bir yöntem türü de, kullanıcının istemci makinesine kimliğini doğrulama çalışmasının bir bölümünü devretmeyi içerir. Bu, birçok makine aynı hesapları paylaştığında, işletmeler gibi kontrollü ortamlarda olur. Sunucu, istemci makinesini, tam tersi şekilde kullanılan aynı mekanizma ile doğrular, daha sonra kullanıcının kimliğini doğrulamak için müşteriye güvenir.

Arkadaşlarım bana cevabı verdi. Varsayılan olarak, tuş bir kullanıcıyı değil bir makineyi tanımlar. Böylece tuşlar / etc / ssh / içinde saklanır. Bu yüzden /root/.ssh de kayıtlı olandan farklı bir anahtar aldım.