Linux ssh: kullanıcıya özel anahtara okuma hakları vermeden ortak anahtar kimlik doğrulamasına izin ver

Linux sunucumda oturum açan kullanıcılar, varsayılan bir hesapla belirli bir uzak makineye ssh yapabilmelidir. Uzak makinedeki kimlik doğrulama genel anahtarı kullanır, bu nedenle sunucuda ilgili özel anahtar kullanılabilir.

Sunucu kullanıcılarının özel anahtarı okuyabilmesini istemiyorum. Temel olarak, sunucuya erişebilmeleri, ssh'ın doğru olmasına izin verir ve sunucudan kaldırılmaları da uzak makineyle bağlantıya izin vermemelidir.

Kullanıcıların özel anahtara okuma erişimi vermeden ssh bağlantısı açmasına nasıl izin verebilirim?

Şimdiye kadar düşüncelerim: Açıkçası ssh yürütülebilir özel anahtarı okuyabilmelidir, bu yüzden bu hakkı olan sunucu üzerinde başka bir kullanıcı altında çalışması gerekir. Ssh bağlantısı kurulduktan sonra, komutları girip uzak makineyle etkileşime girebilmesi için kullanıcıya "iletebilirim".

• Bu iyi bir yaklaşım mı?
• İleriyi nasıl uygulamalıyım?
• Kullanıcı bağlantıyı nasıl başlatabilir (yani ssh'nin anahtar üzerinde okuma hakları olan kullanıcı tarafından yürütülmesi)?
• Güvenlik boşluğu var mı? - kullanıcılar ssh'ı başka bir kullanıcı olarak yürütebilirlerse, diğer kullanıcıların yapabileceği her şeyi yapabilirler (özel anahtarı okumak dahil)?

Var olan sebeplerden biri budur sudo. Kullanıcılarınızın yalnızca önceden yetkilendirilmiş komut satırı seçenekleriyle tek bir komut çalıştırmasına izin verin ve en belirgin engeller çözülür. Örneğin

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

sudogrubun tüm üyelerinin usersssh komutunu çalıştırdıklarında kendi parolalarını (veya some_uid hesabının parolasını) girmeden user_uid olarak çalıştıracak şekilde ayarlar :

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

NOPASSWD:Uzak ana bilgisayarda oturum açmadan önce kullanıcıların kendi şifrelerini girmeye zorlama seçeneğini kaldırın .
Muhtemelen bir takma ad veya sarıcı komut dosyası kullanıcılarınız için kolaylık olarak ayarlayın, çünkü sudodoğru argümanları kullanma konusunda oldukça seçici.

Bu, ana bilgisayar tabanlı kimlik doğrulaması için iyi bir kullanım durumu gibi görünüyor. Bu, SSH'nin kimlik doğrulaması için yerel makinede (bu durumda sunucunuz) tek bir kullanıcının anahtarını kullanmadığı bir kimlik doğrulama yöntemidir ; bunun yerine, ana bilgisayarın özel anahtarını kullanır; bu anahtar, depolanan /etc/ssh/ve yalnızca tarafından okunabilen özel anahtarı kullanır root.

Bunu ayarlamak .shostsiçin, uzak makinede, kullanıcıların giriş yapmasını istediğiniz kullanıcının giriş dizininde (değil ~/.ssh) adlı bir dosya oluşturmanız gerekir . Dosyanın içeriği olmalıdır

server-hostname +

Burada server-hostnamesunucunuzun adı ve +"herhangi bir kullanıcı" anlamına gelen joker karakter olarak kullanılan gerçek bir artı işaretidir.

Ayrıca uzak makinenin sunucunun ana makine anahtarını doğrulayabildiğinden emin olmanız gerekir; bu, sunucunun ana makine anahtarının uzak makinede /etc/ssh/ssh_known_hostsveya ~/.ssh/known_hostsuzak makinede listelenmesi gerektiği anlamına gelir . Bu durumda değilse, uzak makinede oturum açıp çalıştırarak ayarlayabilirsiniz.

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

Bu adımları ayarladıktan sonra, başka bir şeye ihtiyacınız yoksa, sunucudaki özel anahtarı tamamen silebilirsiniz. (Bunu yaparsanız, her zaman yalnızca tarafından okunabilecek bir rootşey olarak ayarlayabilirsiniz .)

Ayrıca, belirli kullanıcıların uzak makineye erişmesine izin verme veya reddetme gibi işlemleri kolayca yapabilirsiniz. Ayrıntılar için sshve sayfalarına hosts.equivbakın.

Bu kurulumla ilgili bir sorun, uzak makinede oturum açan kullanıcıların değiştirebilmesidir .shosts. Uzak makineye farklı bir kullanıcı olarak giriş yapmalarına izin verecek hiçbir şey yoktur, ancak kendi veya başkalarının uzak makineye erişimini kesebilirler. Bu bir endişe ise, .shostssadece yazılabilir bir rootşey yapabilir veya bunun işe yarayıp yaramadığından emin değilim, ama deneyebilir ve görebilirsiniz. ( sudoBir kullanıcı her zaman silebildiğinden, olduğu gibi diğer yöntemler de aynı riske maruz kalır ~/.ssh/authorized_keys.)