Genel anahtar ssh yetkilendirmesi için hesabın kilidini aç, ancak şifre yetkilendirmesi için hesabın kilidini nasıl açarım?


32

Hesap kilitli olduğundan ssh giriş yapmama izin vermiyor. Sunucumda kullanıcının ssh üzerinden genel anahtar yetkilendirmesi için kilidini açmak istiyorum, ancak şifreli oturum açmayı etkinleştirmeyin.

Denedim:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

Kimlik doğrulama günlüğü girişleri:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

Eğer gereken (IMHO) için bunu tüm tüm sshd için yapıyor zaman ... kullanıcıları basit bir yapılandırma
Skaperen

passwd -ukötü bir fikir. Giles'in aşağıdaki cevabını görün.
Peter Jenkins

Yanıtlar:


15

Hesabın kilidini açın ve kullanıcıya @Skaperen’in önerdiği gibi karmaşık bir şifre verin.

Düzenleyin /etc/ssh/sshd_configve sahip olduğunuzdan emin olun:

PasswordAuthentication no

Satırın ( #başlangıçta) yorumlanmadığından emin olun ve dosyayı kaydedin. Son olarak, sshdservisi yeniden başlatın .

Bunu yapmadan önce, genel anahtar kimlik doğrulamanızın önce çalıştığından emin olun.

Bunu yalnızca bir (veya az sayıda) kullanıcı için yapmanız gerekiyorsa, PasswordAuthenticationetkin bırakın ve kullanın Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Dosyanın altına, bir sonraki Matchkomuta veya EOF'ye kadar geçerli olacak şekilde yerleştirin .

Ayrıca Match Group <group name>bir olumsuzlama kullanabilirsinizMatch User !bloggs

Yorumlarda bahsettiğiniz gibi, bunu tersine çevirerek yapılandırmanın ana kısmında Parola Doğrulama'nın devre dışı bırakılmasını ve Matchbirkaç kullanıcı için etkinleştirmek üzere ifadelerin kullanılmasını sağlayabilirsiniz:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

Miro'nun bir kullanım parolasını devre dışı bırakmak istediği izlenimini edindim . ama benim önceki
yorumumu

@Skaperen - haklı olabilirsin. Cevabımı biraz değiştirdim.
GarethTheRed

Bu Matchsözdizimi iyi görünüyor, ama tersini deneyeceğim. (Çok az miktarda) kullanıcı için parola girişini etkinleştirin.
kravemir

@Miro - Bu iyi bir fikir, gelecek referans için cevabımı ekledim.
GarethTheRed

37

Ne yaparsanız yapın, hesabınızı passwd -uboş bir şifre alanıyla bırakılan bir durumda bırakmayın : bu şifre girmeden oturum açmanıza izin verir (SSH dışında, çünkü SSH bunu reddeder).

Şifreye sahip olmamak için hesabınızı değiştirin, ancak kilidi açın. Şifre veritabanındaki şifre karma herhangi bir dizenin karma değilse, bir hesabın şifresi yoktur. Geleneksel olarak, bunun için *veya gibi bir karakterlik bir dize !kullanılır.

Kilitli hesaplar ayrıca şifre alanında, herhangi bir dizenin karması olmamasına neden olan özel bir işaretleyici kullanır. İşaretçi sisteme bağlıdır. Linux'ta passwdkomut !, başında bir işaret koyarak kilitli şifreleri işaretler ve OpenSSH, alana başlarsa hesabı kilitli olarak değerlendirir !. Diğer Unix varyantları benzer fakat aynı mekanizmaları kullanma eğilimindedir, bu nedenle parola veritabanınızın heterojen bir ağ arasında paylaşılıp paylaşılmadığına dikkat edin.

Linux'ta, SSH erişimine izin verirken bir hesaba parola tabanlı erişimi devre dışı bırakabilirsiniz (diğer bazı kimlik doğrulama yöntemleriyle, genellikle bir anahtar çifti ile).

usermod -p '*' username

Kullanıcı, şifreyi tekrar şifreyle değiştiremez, çünkü geçerli bir şifre girmelerini gerektirir.

İsterseniz, hesabın parolası olup olmadığına bakılmaksızın SSH'yi parola doğrulamasını reddedecek şekilde yapılandırabilirsiniz. Yine de SSH'nin hesabın kilitlenmesini göz önünde bulundurmaması için düzenleme yapmanız gerekir; bu nedenle, örneğin Linux'ta !parola alanından kaldırmanız gerekir (ancak alanı boş bırakmayın - *yukarıda açıklandığı gibi ayarlayın ). SSH için parola doğrulamayı devre dışı bırakmak için, veya PasswordAuthenticationyönergelerini (sisteminizde hangisi varsa) ekleyin. Bu yönergenin yalnızca belirli bir kullanıcı için geçerli olmasını sağlamak için bir blok kullanın ; bloklar görünmelidir/etc/sshd_config/etc/ssh/sshd_configMatchMatch

…
Match User username
    PasswordAuthentication no

6
Teşekkürler - usermod -p '*' usernamebir cazibe çalıştı!
Homme Zwaagstra

1
OpenSSHd, kilitli kullanıcıların (örneğin, !ön ekli şifre karma ) UsePAM yes, ayarlanmışsa başka bir kimlik doğrulama yöntemiyle oturum açmasına izin verir sshd_config. Bu muhtemelen çoğu dağıtımda varsayılandır (örneğin, Fedora'da).
maxschlepzig

1
Bu yüzden, PAM olmadan gömülü bir sistem var '*'vs '!'ayrım süper yararlıdır.
jpkotta

8

Şifreleri etkinleştirmeniz veya ayarlamanız gerekmez ve zaten güçlü anahtarlar kullanıyorsanız, gerçekten yapmamalısınız. Hesabınızı (sudo şifresi -l kullanıcı adı) mevcut bir oturumdan tekrar kilitleyin ve SSH yapılandırmanızı düzeltin.

Bunun olmasının nedeni, muhtemelen varsayılan SSH arka plan programı ayarlarından birini düzenlediğiniz içindir (/ etc / ssh / sshd_config dosyasında).

Bunu / etc / ssh / sshd_config dosyasında değiştirin ve SSH'yi yeniden başlatın:

UsePAM yes

Genel olarak, PAM'yi devre dışı bırakmak için gerçekten iyi bir nedeniniz yoksa, etkin durumda kalmanızı öneririm; SSH içerisinde PAM'ı etkinleştirmek, bir şifre kaldırılmış olsa bile hala giriş yapmanızı sağlar. Ne yaparsanız yapın, boş bir şifre veya benzeri bir şey ayarlamayın ... şifre alanını kilitlemek, hesabınızın tamamını kilitlemek anlamına gelmez.

SSH ile uğraşırken hızlı ipucu: SSH yapılandırmanızda değişiklik yaparken başka bir oturumu açık tutun (başka bir pencerede) ve ardından hala giriş yapabileceğinizi test edin; yanlışlıkla erişiminizi keserseniz, düzeltmek için geçerli oturumunuzu kullanın.

(Feragatname: SSH anahtar yönetim yazılımı sağlayan Userify'de çalışıyorum.)


0

CentOS 7'de bu problemi yaşadım. Debian merkezli düzenli bir Linux kullanıcısıyım, bu yüzden sudan çıkmış bir balıktım. Sunucuların bazılarında çalıştığını ve sadece birinde çalışmadığını fark ettim. Audit.log yararlı hiçbir şey söylemedi ve secure.log da hiçbir şey vermedi. Tek gerçek farkın, çalışanlar ile çalışmayanlar arasındaki dosya ve dizinlerdeki bazı güvenlik bağlamındaki farklılıklar olduğunu buldum. Güvenliği al

sudo ls -laZ <user-home>/.ssh

dizininin (sshd_config üzerinde çok fazla varsayılan olduğunu farz ediyorum).

Bazılarını ssh_home_tve user_home_tniteliklerini görmelisin . Yoksa, chconeksik özellikleri eklemek için komutu kullanın.

Örneğin

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Benim durumumda, benim şüphem, kullanıcının standart olmayan bir şekilde yaratılmış olmasıdır. Evi bir rehberdi /var/lib.

Daha fazla bilgi için: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/


-2

hesabın kilidini açın ve şifreyi rasgele bir dizeyle değiştirin

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.