SSH ile şifresiz hesaplara tutarlı ve güvenli bir yaklaşım


13

Bazı durumlarda şifresiz sunucuları sevdiğimi itiraf etmeliyim. Tipik bir sunucu, fiziksel erişimi olan herkese açıktır. Bu nedenle bazı durumlarda fiziksel olarak kilitlemek ve o zamandan beri herhangi bir fiziksel erişime güvenmek pratiktir .

Temel konseptler

Teorik olarak, böyle bir sunucuya fiziksel olarak ulaştığımda, sadece rootgiriş olarak yazarak şifre olmadan yönetim görevlerini yerine getirebilmeliyim ve bir şifre istenmemeliyim. Aynı durum kullanıcı hesapları için de geçerli olabilir, ancak bunlara fiziksel olarak gerçekten erişilmez. Bu nedenle (zaman zaman) yerel erişim için sistem şifresi gerekmez.

Sunucuya yönetim veya kullanıcı hesabı için uzaktan erişirken, her zaman bir SSH özel anahtarı kullanmayı beklerim. Yeni oluşturulmuş bir hesap için bir SSH anahtarı ayarlamak çok kolaydır ve bu nedenle (düzenli) uzaktan erişim için sistem şifresi gerekmez.

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

Sonuç olarak, teoride, bu gibi kullanım durumları için herhangi bir sistem şifresi kullanmayacağız. Yani soru şu, sistemi ve kullanıcı hesaplarını tutarlı ve güvenli bir şekilde gerçekleştirmek için nasıl yapılandıracağız.

Yerel erişim ayrıntıları

Kök hesaba parola olmadan yerel olarak erişilmesini nasıl sağlayabiliriz? Sanırım kullanabilirsiniz sanmıyorum passwd -do kök erişimi çok keyfi yapacak ve bir unpriviliged kullanıcı verebileceğinden geçiş yanlış olan ücretsiz köküne. Giriş yapmamızı passwd -lengellediği için kullanamayız .

Yerel erişimin yalnızca yerel klavyeyi kullanarak erişim ile ilgili olduğunu unutmayın. Bu nedenle, geçerli bir çözüm , herhangi bir kullanıcının geçiş yapmasına izin vermemelidir ( suveya ister kullansın sudo).

Uzaktan erişim ayrıntıları

Yakın zamana kadar yukarıdaki çözüm işe yarayacaktı, ancak şimdi SSH kilitli kullanıcı hesaplarını kontrol etmeye başladı. Muhtemelen passwd -daynı nedenlerle kullanamayız . Ne passwd -uişe yarayacağından şikayet ettiği için kullanamayız passwd -d.

Bu bölüm için kukla parola içeren bir geçici çözüm var.

user=...

echo -ne "$user:`pwgen 16`\n" | chpasswd

SSH'de kilitli hesap kontrolünü tamamen kapatmak da mümkün olabilir, ancak kilitli hesapların desteğini korumak ve sadece kilidini açabilmek daha güzel olurdu.

Son notlar

İlgilendiğim şey, root hesabına yerel olarak ve root dahil tüm hesaplara herhangi bir şifre olmadan uzaktan giriş yapmanıza izin veren bir çözümdür. Öte yandan, bir çözüm, özellikle uzak kullanıcıların kök hesaba veya diğer kullanıcıların hesabına erişmesine izin vermeyerek, açık bir şekilde açıklanan yollar dışında güvenliği etkilememelidir. Çözüm, güvenlik sorunlarına dolaylı yol açmayacak şekilde yeterince sağlam olmalıdır.

Kabul edilen ve verilen bir cevap, münferit araçların ayrıntılı konfigürasyonunu tanımlayabilir veya tanımlamayabilir, ancak belirtilen hedeflere ulaşmak için kilit noktaları içermelidir. Bu muhtemelen gibi araçlarla geleneksel kullanımı yoluyla çözülemez olduğunu Not passwd, ssh, su, sudove benzeri.

İlk cevapları okuduktan sonra daha fazla fikir

Sadece bir fikir - yerel kök erişimi, giriş işlemleri yerine kök kabukları başlatılarak elde edilebilir. Ancak yine de ortak anahtar kimlik doğrulamasını değil, yalnızca şifre kimlik doğrulamasını kilitlemek gerekir.


Parola olmadan yerel erişim için özelleştirilmiş bir PAM yapılandırması kullanın ve sudo ve SSH oturum açma işlemleri için de aynısını yapın.
0xC0000022L

Yanıtlar:


5

Madde işaretleri olarak çözüm önereceğim gereksinimler:

  1. Parolasız kök konsol girişi
  2. Önceden yetkilendirilmiş kullanıcılardan şifresiz kök uzaktan oturum açma
  3. Önceden yetkilendirilmiş kullanıcılardan belirli hesaplar için şifresiz uzaktan oturum açma
  4. Önceden yetkilendirilmiş kullanıcılardan herhangi bir hesap için şifresiz uzaktan oturum açma

Aşağıdaki örnekler Debian'a dayanmaktadır, çünkü burada test için aldığım şey budur. Ancak, prensiplerin herhangi bir dağılıma (veya aslında PAM tabanlı * ix türevine) uygulanamamasının bir nedenini göremiyorum.

Parolasız kök konsol girişi

Sanırım buna yaklaşma şeklim PAM ve /etc/securettykonfigürasyon dosyasını kullanmak olacaktır.

Bir ön koşul olarak, "yeterince güvenli" bir kök parola ayarlanmalıdır. Bu, konsolda oturum açmak için gerekli değildir, ancak kaba kuvvet kırma girişimlerini gerçekçi yapmak için vardır. Hesap aksi halde tamamen normal bir kök hesaptır.

In /etc/pam.d/loginben kimlik doğrulaması için hatlar (bu anahtar kelime ile başlayan aşağıdaki standart set var auth):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

Başvurulan common-authiçerme dosyası aşağıdaki ilgili satırları içerir:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

common-authDosya talimatını PAM bir "UNIX giriş" başarılı olursa bir kural (inkar) atlamak için. Genellikle bu bir eşleşme anlamına gelir /etc/shadow.

auth ... pam_securetty.soÇizgi belirtilen Tty cihazlarda dışında kök bağlantıları önlemek üzere yapılandırılmıştır /etc/securetty. (Bu dosya zaten tüm konsol cihazlarını içeriyor.)

Bu authsatırı biraz değiştirerek , belirtilen tty cihazından şifre olmadan kök oturum açmaya izin veren bir kural tanımlamak mümkündür /etc/securetty. success=okParametre böylece tadil edilmesi gerekmektedir oksayısına göre değiştirilir authbaşarılı bir uyumu durumunda atlanmasına hatları. Burada gösterilen durumda, bu sayı çizgiye 3atlar auth ... pam_permit.so:

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

Önceden yetkilendirilmiş kullanıcılardan şifresiz kök uzaktan oturum açma

Bu, kök authorized_keysdosyaya eklenen yetkili kullanıcılar için ssh anahtarlarının doğrudan dahil edilmesidir .

Önceden yetkilendirilmiş kullanıcılardan belirli hesaplar için şifresiz uzaktan oturum açma

Bu, uygun ve karşılık gelen kullanıcı .ssh/authorized_keysdosyasına eklenen yetkili kullanıcılar için ssh anahtarlarının doğrudan dahil edilmesidir . (Tipik uzak kullanıcı chris yerel kullanıcı chris senaryosuna şifresiz giriş yapmak istiyor .)

Hesaplar oluşturulduktan sonra varsayılan kilitli durumda kalabilir (yani yalnızca !parola alanında /etc/shadow) ancak SSH anahtarı tabanlı oturum açmaya izin verebilir . Bu, anahtarı yeni kullanıcının .ssh/authorized_keysdosyasına yerleştirmek için root gerektirir . Bu kadar açık olmayan şey, bu yaklaşımın sadece belirlendiğinde mevcut UsePAM Yesolmasıdır /etc/ssh/sshd_config. PAM !, "şifre için hesap kilitlendi, ancak diğer erişim yöntemlerine izin verilebilir" ve !..."hesap kilitlendi. Periyot" olarak farklılaşır . ( UsePAM NoAyarlanmışsa, OpenSSH, !kilitli bir hesabı temsil etmek için parola alanını başlatmanın herhangi bir varlığını dikkate alır.)

Önceden yetkilendirilmiş kullanıcılardan herhangi bir hesap için şifresiz uzaktan oturum açma

Bu tesisi isteyip istemediğiniz tamamen açık değildi. Yani, bazı yetkili kullanıcılar herhangi bir yerel hesaba herhangi bir şifre olmadan giriş yapabilirler.

Bu senaryoyu test edemiyorum ancak bunun birden fazla authorized_keysdosyanın tanımlanmasına izin veren OpenSSH 5.9 veya daha yeni bir sürümle gerçekleştirilebileceğine inanıyorum /etc/ssh/sshd_config. Yapılandırma dosyasını, adlı ikinci bir dosyayı içerecek şekilde düzenleyin /etc/ssh/authorized_keys. Seçtiğiniz yetkili kullanıcıların ortak anahtarlarını bu dosyaya ekleyin, böylece izinler köke aittir ve yalnızca kök tarafından yazma erişimine sahip olur (0644).


# 1'i daha dikkatli bir şekilde incelemem ve test etmem gerekecek. Hala yapılandırılmış (güçlü) bir şifre gerektirmesine rağmen çok ilginç görünüyor. # 3 günümüzde yeni oluşturulan bir kullanıcı SSH girişinden de varsayılan olarak kilitlendiğinden tamamlanmamıştır. Gerçekten 4. nokta için sormadım ama yine de çok ilginç görünüyor ve aslında böyle bir yöntem için bir kullanım olabilir.
Pavel Šimerda

Kök için güçlü bir parola gerekir ancak asla kullanılmaz. # 3'ü nasıl uygulayacağınızı bildiğinizi varsaydım; daha fazla ayrıntıya ihtiyacınız varsa bana bildirin. (Debian) sistemlerde, .ssh/authorized_keysdosyanın ilgili ortak anahtarı içermesi koşuluyla, henüz bir parolası tanımlanmamış yeni bir hesaba giriş yapmak mümkündür . Bu yardımcı olur mu?
roaima

Ben Debian gördüğünüz davranış kurtarmak için güzel ve standart bir yol ihtiyacım olduğunu düşünüyorum, yani yeni oluşturulan bir hesap sadece şifre kimlik doğrulaması için değil, ortak anahtar bir için kilitli.
Pavel Šimerda

Önceki yorumumda ssh ifadesini onaylamak için oluşturduğum test kullanıcısı hesabı için !, parola alanında bir tane görüyorum /etc/shadow. Man sayfasına göre bu, hiçbir parolanın eşleşemeyeceği geçerli bir hesabı gösterir.
roaima

1
Bu ilginç, en azından o kadar da belirgin değil , teşekkürler.
Pavel Šimerda

1

Ssh anahtarları ve tam NOPASSWDerişim ile gerçek (root olmayan) kullanıcı hesapları istediğiniz gibi görünüyor sudo(bu, çoğu Linux dağıtımında varsayılan olarak mevcuttur ve manuel olarak yüklenmesi önemsizdir). Her kullanıcı hesabı için (uzaktan çalışmaz) boş parolalara sahip olabilirsiniz, ardından kullanıcı çalışır sudo -sveya ~/.bash_profileyalnızca bu komutu içerir.

sudo

Her kullanıcıyı sudoUNIX grubuna ekleyin (örneğin usermod -a -G sudo USERNAME, eski sistemlerin bunu yapmanın daha az sezgisel yolları olsa da, en kötü durum /etc/groupsdoğrudan düzenlersiniz ).

Gelen /etc/sudoersveya /etc/sudoers.d/local, böyle bir hat istiyorum:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

Otomatik kök erişimi istiyorsanız, bunu kullanıcının profiline ekleyin. İçin basholurdu, ~/.bash_profile:

sudo -s

Bu, kimlerin oturum açtığını görmenizi ( whoveya denemenizi last) sağlar ve günlükleri bırakır /var/log/auth.log.

Parolasız giriş

Çok daha eski sistemlerde, karmayı düzenleyebilir /etc/passwd(veya biraz daha eski sistemlerde /etc/shadow) ve hash'ı kaldırabilirsiniz, böylece örneğin bob:$1$salt$hash:12345:0:99999:7:::sadece olur bob::12345:0:99999:7:::. Tek ihtiyacınız olan buydu. Modern sistemler bundan hoşlanmaz. Bunu yapmanın başka yolları da vardır, ancak doğruladığım yol aşağıdaki gibidir (kaynak: Leo's Random Stuff ) :

/etc/shadowGerçek bilgiler içeren bir hesap açın ve gözlemleyin. Bu, dolar işareti ( $) ile sınırlandırılmış üç öğeyi içerecektir . Bunlar hash mekanizmasını, sonra tuz , sonra hash'ı temsil eder . Tuzu not edin, ardından çalıştırın:

openssl passwd -1 -salt SALT

(Bu, karma mekanizması olarak MD5 kullanır. Boş bir paroladır, bu yüzden aldırmamalısınız.) Parola istendiğinde enter tuşuna basın. Sondaki noktalar dahil olmak üzere bu dizeyi kaydedin ve kullanıcının bulunduğu satırdaki ilk iki noktadan sonra yapıştırın /etc/shadow(bu, birinci ve ikinci iki nokta arasındaki önceden var olan içeriğin yerini almalıdır). (Lütfen tam anlamıyla SALTtuz olarak kullanmayın !)

SSH

Sizin sshcini yapılandırma ya yaşar /etc/sshd_configya /etc/ssh/sshd_config. Doğru güvenlik için, şu satırları içermesini öneririm:

PermitRootLogin no
PermitEmptyPasswords no

Gelişmiş saldırganlara karşı daha iyi sertleştirmek için ssh yapılandırmanıza ekleyebileceğiniz ek güvenlik önlemleri için Güvenli Güvenli Kabuk yazımına bakın .

Şimdi kullanıcılar olamaz aracılığı giriş ssh(bu gerekli bir güvenlik önlemidir) boş şifreleri olması nedeniyle. Bu, yalnızca ssh tuşlarıyla oturum açabilecekleri anlamına gelir.

Her kullanıcı, istemci sistemlerinin her biri için bir ssh anahtar çifti oluşturmalıdır, örn.

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

Bu, adresinde özel anahtar ve adresinde $HOME/.ssh/id_rsagenel anahtar üretir $HOME/.ssh/id_rsa.pub. Bu kullanıcının size ortak anahtarlarını göndermesini ve bunları bu sunucunun sonuna eklemesini isteyin $HOME/.ssh/authorized_keys(her kullanıcının $HOME/.ssh700 modu olması gerektiğini unutmayın mkdir -p ~user/.ssh && chmod 700 ~user/.ssh).

Ssh anahtarları istemeyen kullanıcılar fiziksel sisteme yönlendirilebilir. Orada, boş parolaları oturum açacaktır, bu noktada passwdkabuktan yazabilir ve bir parola ayarlayabilir, böylece uzaktan erişime izin verebilirler.

(Aslında bu tekniği, bir BT departmanını çalıştırdığımda insanlara bir sistem koleksiyonuna erişim sağlamak için kullandım. Kullanıcıları ssh anahtarlarını kullanmaya zorladı ve onlara şifre vermek ~/.bash_profilezorunda kalmadım. passwdve ardından mv ~/.bash_profile.real ~/.bash_profileilk girişte yeni bir şifre belirlediler.)

Riskler

Kullanıcılarınıza tam güven duyuyorsunuz. Bir kullanıcının başka bir kullanıcının ~/.ssh/authorized_keysdosyasıyla uğraşmasını engelleyen ve böylece erişimi iptal etme ve denetleme yeteneğinizi değiştiren hiçbir şey yoktur , ancak tam root erişimi veriyorsanız bu kaçınılmazdır.

Sonuç

Her kullanıcı şimdi sudo grubunun bir üyesidir ve bir kök kabuğa tam şifresiz erişime sahiptir. Bu kullanıcıların hesapları için şifreleri yoktur ve ssh tuşlarını kullanarak uzaktan oturum açabilirler.

Çalışanlarınızdan birini kaybederseniz hesabını kaldırabilirsiniz. Çalışanlarınızın dizüstü bilgisayarlarından biri çalınırsa, o dizüstü bilgisayarın ssh anahtarını kullanıcının authorized_keysdosyasından kaldırabilirsiniz . Güvenlik ihlali varsa, kimin oturum açtığını gösteren günlükleriniz vardır.


Sudo ile ilgili bölüm , kullanıcıları değiştirmek değil, sadece yeni girişlerle ilgili olan soruyu özlüyor. Soruyu daha açık hale getirmek için değiştirildi. Parolasız oturum açma ile ilgili bölüm passwd -d, söz sukonusu kullanıcıyla aynı yanlış davranışı sergileyerek bu kullanıcıya parola olmadan geçiş yapılmasına izin verir . Riskler bölümü, kaldırılması sorunun en önemli noktası olan iki şeyi (diğer kullanıcıların verilerini karıştırmak ve root erişimi almak) açıklar. Bu nedenle, bireysel bölümler güzel yazılmış olsa da, bu kesinlikle soruya bir cevap değildir.
Pavel Šimerda

Kullanıcıyı ekledikten sonra kullanıcıyı kısıtlayacağınızı varsaydım.
Adam Katz
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.