Kimlik doğrulama, bir sisteme giriş, yetkilendirme işlemini gerçekleştirme hakkına sahip olduğunuzu kanıtlamak için kullanılan bir bilgi parçasıdır. Kimlik doğrulama kanalı, kimlik doğrulama sisteminin kullanıcıya farklı yöntemlerle, faktörlerle kendini kanıtlaması, tanıtması talebi olarak da düşünülebilinir. Genel olarak parolalar ve güvenlik anahtarları, kimlik doğrulama faktörlerine verilebilecek genel örneklerdir.

SSH, varsayılan olarak kimlik doğrulama için şifre tekniğini kullanmaktadır ve birçok SSH güvenlik sağlamlaştırma dökümanı şifre tekniğini kullanmak yerine SSH anahtarı kullanım tekniğini önerir. Bununla birlikte, bu genel olarak tek faktördür, katmandır, seviyedir. Herhangi bir kişi sizin ssh anahtarlarınızı ele geçirirse ve siz tek seviyeli ssh anahtar tekniğini kullanıyorsanız bu durumda ilgili kişi sizin diğer sunucularınızıda kolaylıkla ele geçirebilir.

Bu dokümanda, çok faktörlü (multi-factor) kimlik doğrulamasının kurulumunu anlatacağız. Çok Faktörlü kimlik doğrulama (MFA), kimlik doğrulaması yapmak veya oturum açmak için birden çok sayıda faktöre ihtiyaç duyulmasıdır. Farklı faktör tipleri aşağıdaki şekilde örneklendirilebilinir:

  1. Bildiğiniz bir kelime, şifre veya güvenlik sorusu
  2. Sahip olduğunuz bir şey, kimlik doğrulayıcı uygulaması veya güvenlik simgesi
  3. Vücudunuza ait bir bölüm, parmak iziniz veya sesiniz olabilir

Google kimlik doğrulayıcı gibi bir OATH-TOTP(Open Authentication Time-Based One-Time Password) uygulaması ortak bir faktördür. OATH-TOTP, bir kerelik kullanım parolası üreten ve her 30 saniyede bir ilgili parolayı yenileyen bir protokoldür.

Bu dokümanda, bir SSH key’ ine ek olarak OATH-TOTP uygulaması kullanılarak SSH kimlik doğrulamasını nasıl etkinleştirileceğini anlatacağız. Sunucuya SSH ile giriş yapmak, iki kanal arasında iki faktör gerektirdiğinden yalnızca şifre veya SSH key ile login olmaktan daha yüksek seviyeli güvenlik sağlamaktadır. Ayrıca, MFA için bazı ek kullanım örnekleri ve bazı yararlı ipuçları ve püf noktaları üzerinde de duracağız.

Gereksinimler

Öncelikle Multi-Factor SSH kimlik doğrulaması ayarlarına geçmeden önce CloudEOS‘ a kayıt olarak bir adet CentOS 7 sunucunuzu oluşturmalısınız.

Kuruluma başlamadan önce CentOS sunucular için güvenlik açısından sudo yetkilerine sahip bir kullanıcı oluşturmanızı tavsiye ediyoruz.

Yeni Kullanıcı Ekleme

Sisteme size verilen şifre ve root kullanıcısı ile giriş yaptıktan sonra

$ adduser yenikullanici

ile kullanıcı oluşturmuş oluyoruz.

$ passwd yenikullanici
$ usermod -aG wheel yenikullanici

komutu ile de oluşturduğumuz kullanıcıya sudo yetkilerini vermiş olduk. Şimdi Multi-Factor SSH yapılandırma adımlarına bu oluşturduğumuz sudo haklı kullanıcı ile devam edeceğiz.

Bu oluşturmuş olduğumuz sudo haklı kullanıcıya ek olarak Google Kimlik doğrulaması gibi bir OATH-TOTP uygulmasının yüklü olduğu akıllı telefon veya tabletiniz olmalıdır.

Google’s PAM Kurulumu

Bu adımda, Google’s PAM kurulum ve yapılandırılmasını anlatacağız.

Pluggable Kimlik Doğrulama Modülü anlamına gelen PAM, Linux sistemlerinde bir kullanıcının kimliğini doğrulamak için kullanılan kimlik doğrulama altyapısıdır. Google bir OATH-TOTP uygulaması yapmasıyla beraber, TOTP’ ler üreten ve Google kimlik doğrulama veya Authy gibi herhangi bir OATH-TOTP uygulaması ile tamamen uyumlu bir PAM de yapmıştır.

İlk olarak sunucumuza eğer ekli değil ise EPEL kaynak deposunu ekleyeceğiz.

$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Sonra PAM kurulumunu yapacağız. Kaynak deposunu ilk kez kullanıyorsanız, EPEL key’ in sisteme eklenmesi için onayınız istenebilir. İlgili key dosyası sisteme yüklendikten sonra sizden tekrardan bir onay istenmeyecektir.

$ sudo yum install google-authenticator

PAM yüklendiğinde, ikinci bir faktör eklemek istediğiniz kullanıcı için bir TOTP key oluşturmak için PAM ile birlikte gelen bir yardımcı uygulamayı kullanacağız. Bu key, sistem genelinde değil, kullanıcı bazında oluşturulur. Bu, bir TOTP auth uygulaması kullanmak isteyen her kullanıcının giriş yapması ve kendi anahtarını elde etmek için ilgili yardımcı uygulamayı çalıştırması gerektiği anlamına gelmektedir ve bunu herkes için etkinleştirmek için tek sefer çalıştırmanız yeterli olmayacaktır.

Başlatma uygulamasını çalıştıralım.

$ google-authenticator

Yukarıdaki komutu çalıştırdıktan sonra birkaç soru ile karşılaşacaksınız. Bunlardan ilki, kimlik doğrulama token’ larının zaman esaslı olması gerekliliği ile ilgilidir.

Do you want authentication tokens to be time-based (y/n) y

PAM, zaman tabanlı veya sequential tabanlı token’ lara izin vermektedir. Sequential tabanlı token kullanımında, kod belirli bir noktadan başlar ve her kullanımdan sonra bu arttırılır. Zaman tabanlı token kullanımında, belirli bir süre geçtikten sonra kodun rastgele değiştiği anlamına gelmektedir. Google kimlik doğrulama gibi uygulamaların beklediği gibi biz de zaman tabanlı üzerinde çalışacağız ve bu yüzden ilgili soruya y olarak cevap veriyoruz.

Bu soruyu cevapladıktan sonra, ekranımıza bir QR kodu da gelmektedir. Bu noktada QR kodunu taramak veya secret key’ i manuel olarak taramak için telefonunuzdaki kimlik doğrulama uygulamanızı (Google Authenticator Uygulaması) kullanabilirsiniz. QR kodu, tarama için çok büyük ise, daha küçük bir görselini elde etmek için QR kodunun üstündeki URL’yi kullanabilirsiniz. Eklendikten sonra, uygulamanızda her 30 saniyede bir değişen altı basamaklı bir kod göreceksiniz.

Sonraki sorular, PAM’ in nasıl işleyeceği üzerine olacaktır. Bunları tek tek aşağıda değerlendireceğiz.

Do you want me to update your "/home/tolga/.google_authenticator" file (y/n) y

Bu key ve seçenekleri “.google_authenticator” dosyasına yazmaktadır. Hayır derseniz, program kapanır ve hiçbir şey çalışmaz, yani kimlik doğrulayıcı çalışmaz.

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

Burada evet cevabı vererek, kodun kullanılmasından hemen sonra geçerliliğini yitirmesini sağlayarak tekrarlanan saldırılardan korunmuş olacaksınız. Bu , bir saldırganın yeni kullandığınız bir kodu yakalamasını ve onunla giriş yapmasını önlemektedir.

By default, tokens are good for 30 seconds. In order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). 
Do you want to do so? (y/n) n

Burada evet cevabı, dört dakikalık bir pencerede 8 geçerli koda izin vermektedir. Hayır cevabıyla, 1:30 dakika süren pencerede 3 geçerli kodla sınırlayabilirsiniz. 1:30 dakika penceresiyle ilgili sorun görmediğiniz sürece hayır cevabı daha güvenli bir seçim olacaktır.

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Deneme sınırlaması, uzaktaki bir saldırganın engellenmeden, bloklanmadan önce belirli bir sayıda giriş denemesi yapması anlamına gelmektedir. Daha önce deneme limitleri ile direkt olarak SSH Servisini sınırlandırmadıysanız, şimdi bunu yapmak büyük bir önem taşımaktadır ve tavsiye edilmektedir.

Artık Google’ ın PAM’ i kuruldu ve yapılandırıldı, bir sonraki adımda SSH’ ı TOTP key’ i kullanacak şekilde yapılandıracağız. SSH’ a PAM hakkında bilgi vermemiz ve ardından SSH’ ı kullanması için SSH yapılandırmasını tamamlamamız gerekemtedir.

OpenSSH Yapılandırılması

SSH üzerinde SSH değişiklikleri yapacağımızdan dolayı ilk SSH bağlantısının hiçbir zaman kapanmaması önemlidir. Bu yüzden ikinci bir SSH oturumunu testlerimimiz yapmak için kullanacağız. Bu, SSH yapılandırmamız da herhangi bir hata olması durumunda kendimizi sunucuyu kilitlememizi önlemek için gereklidir. Her şey olması gerektiği gibi çalıştığını gördükten sonra, mevcut oturumları güvenle kapatabiliriz.

İlk olarak PAM, sshd yapılandırma dosyasında bazı düzenlemeler yapacağız.

$ sudo nano /etc/pam.d/sshd

Aşağıdaki satırı dosyanın altına ekleyelim.

...
# Used with polkit to reauthorize users in remote sessions
-session optional pam_reauthorize.so prepare
auth required pam_google_authenticator.so nullok

Son satırın sonundaki nullok sözcüğü bu kimlik doğrulama yönteminin isteğe bağlı olduğunu PAM’a bildirmektedir. Bu, OATH-TOTP token’ ı olmayan kullanıcıların hala SSH anahtarını kullanarak oturum açmalarına izin verdiği anlamına gelmektedir. Tüm kullanıcıların bir OATH-TOTP token’ ı olduğunda, MFA’ yı zorunlu hale getirmek için nullok’ ı bu satırdan kaldırabilirsiniz.

Dosyayı kaydederek çıkalım.

Şimdi SSH’ ı bu tür bir kimlik doğrulamayı destekleyecek şekilde yapılandıracağız. Değişiklikleri yapacağımız SSH yapılandırma dosyasını açalım.

$ sudo nano /etc/ssh/sshd_config
...
# Change to no to disable s/key passwords
ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no
...

Yukarıdaki değişiklikleri yapıp sonrasında dosyayı kaydederek çıkalım.

Değişikliklerin algılanması için SSH servisini yeniden başlatacağız. Sshd servisini yeniden başlatmak, açık bağlantıları kapatmaz, bu nedenle bu komutla kendi kendinizi kilitleme riski ile karşılaşmazsınız.

$ sudo systemctl restart sshd.service

Her şeyin şimdiye kadar çalıştığını test etmemiz için başka bir terminal açacağız ve SSH üzerinden giriş yapmayı deneyeceğiz. Daha önce bir SSH key oluşturduysanız ve bunu kullanıyorsanız, kullanıcının şifresi veya MFA doğrulama kodunu girmenizin gerekmediğini fark edeceksiniz. Bunun nedeni, bir SSH key’ i varsayılan olarak tüm diğer kimlik doğrulama seçeneklerini geçersiz kılmasıdır.

Şimdiye kadar yaptığımız işlemin yapılmasını istiyorsanız, açık SSH oturumunuz da “~/.ssh/”‘e gitmeli ve “authorized_keys” dosyasını geçici olarak yeniden adlandırmalısınız ve yeni bir oturum açarak, şifreniz ve doğrulama kodunuz ile oturum açmalısınız.

$ cd ~/.ssh
$ mv authorized_keys authorized_keys.bak

TOTP token’ ınızın çalıştığını doğruladıktan sonra “authorized_keys.bak” dosyasını yeniden adlandıralım.

$ mv authorized_keys.bak authorized_keys

SSH’ ın MFA’ dan Haberdar Edilmesi

Sshd yapılandırma dosyasını tekrar açalım.

$ sudo nano /etc/ssh/sshd_config

Dosyanın alt kısmına aşağıdaki satırı ekleyelim. Bu hangi kimlik doğrulama yöntemlerinin gerekli olduğunu SSH’ a bildirecektir.

...
###
ClientAliveInterval 120
ClientAliveCountMax 2
AuthenticationMethods publickey,password publickey,keyboard-interactive

Dosyayı kaydederek çıkalım.

Şimdi PAM sshd yapılandırma dosyasını açalım.

$ sudo nano /etc/pam.d/sshd

Dosyanın üst kısımlarında “auth substack password-auth” satırını bulalım. Satırdaki ilk karakter olarak bir “#” karakteri ekleyerek yorum satırı haline getirelim.

...
#auth substack password-auth
...

Dosyayı kaydederek çıkalım ve SSH servisini yeniden başlatalım.

$ sudo systemctl restart sshd.service

Şimdi sunucuya farklı bir oturum ile tekrar giriş yapmayı deneyelim. Geçen seferkinin aksine, SSH doğrulama kodunuz bu sefer istenecektir. Kodu girdikten sonra giriş yapmış olacağız. SSH anahtarının kullanıldığına dair herhangi bir belirti görmeseniz de, oturum açma girişimimizde iki faktör kullanıldı. Bunu doğrulamak isterseniz, SSH komutundan sonra -v (ayrıntılı bilgi için) ekleyebilirsiniz.

...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/yenikullanici/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:

Çıktının sonuna doğru, SSH’ ın SSH key’ ini nerede kullandığını ve doğrulama kodunu sorduğunu göreceksiniz. Artık bir SSH key’ i ve bir kerelik bir şifre ile SSH üzerinden oturum açabileceksiniz. Eğer üç kimlik doğrulama türünün tümünü uygulamak istiyorsanız, bir sonraki adımı takip edebilirsiniz.

Üçüncü Bir Faktör Ekleme (İsteğe Bağlı)

bir önceki adımda, onaylanmış kimlik doğrulama türlerini sshd_config dosyasında listeledik.

  • publickey (SSH key – SSH anahtarı)
  • password publickey (password – şifre)
  • keyboard-interactive (verification code – doğrulama kodu)

Şimdiye kadar seçtiğimiz seçeneklerle üç farklı faktör listelenmesine rağmen, yalnızca SSH key ve doğrulama koduna izin verilmişti. Üç faktörün hepsini (SSH key, şifre ve doğrulama kodu) kullanmak isterseniz, hızlı bir değişiklik ile üçünü de etkinleştirebilirsiniz.

PAM sshd yapılandırma dosyasına giriş yapalım.

$ sudo nano /etc/pam.d/sshd

Daha önce yorum satırı haline getirdiğimiz “#auth substack password-auth” satırını bulalım ve # karakterini kaldırarak yorum satırından kurtaralım. Dosyayı kaydederek çıkalım. Şimdi SSH servisini yeniden başlatalım.

$ sudo systemctl restart sshd.service

PAM, opsiyon yetkili alt anahtar password-auth özelliğini etkinleştirerek, bir SSH key denetimi ve daha önce çalıştığımız şekilde bir doğrulama kodu ile bir şifre isteyecektir. Artık bildiğimiz bir şeyi (şifre) ve sahip olduğumuz iki farklı şeyi (SSH key ve doğrulama kodu) iki farklı kanal üzerinden kullanabiliriz.

Şu ana kadar, bu dokümanda, bir SSH key ve zaman tabanlı bir seferlik bir şifreyle MFA’ yı nasıl etkinleştireceğimiz açıklandı. İhtiyacınız olan kullanım bu ise buraya kadar olan kısımda bırakabilirsiniz. Bununla birlikte, çok faktörlü kimlik doğrulama için tek yol bu değildir. Aşağıda, çok faktörlü kimlik doğrulama için PAM modülünü kullanmanın birkaç ilave yolu; iyileşme, otomatik kullanım ve daha fazlası için bazı ipuçları bulunmaktadır.

Erişimi Kurtarma

Güçlendirdiğiniz ve güvence altına aldığınız herhangi bir sistemde olduğu gibi, bu güvenliği yönetmek sizin sorumluluğunuzda olacaktır. Bu durumda, SSH key’ inizi veya TOTP secret key’ inizi kaybetmemek ve TOTP uygulamanıza erişebildiğinizden emin olmanız gerekmektedir. Ancak, bazen aksilikler olabilir ve girmeniz gereken key’ lerin veya uygulamaların denetimini kaybedebilirsiniz.

SSH Key’ in veya TOTP Secret Key’ in Kaybedilmesi

SSH key’ inizi veya TOTP secret key’ inizi kaybederseniz, kurtarma birkaç adıma bölünebilir. Birincisi, doğrulama kodunu bilmeden geri dönmesi ve ikincisi, gizli anahtarı bulmak ya da onu normal MFA oturumu açmak için yeniden üretmektir.

Sudo hakları olan bir kullanıcıya ihtiyacınız bulunmaktadır. Bu kullanıcı için MFA etkinleştirmediğinizden ve yalnızca bir SSH key kullandığınızdan emin olmalısınız. Siz veya başka bir kullanıcı, secret key’ ini kaybedip giriş yapamazsa, administrative kullanıcısı oturum açabilir ve sudo haklı herhangi bir kullanıcının key’ ini kurtarmasına veya yeniden oluşturmasına yardımcı olabilir.

Giriş yaptıktan sonra, TOTP’ nin gizli kalmasına yardımcı olmanın iki yolu bulunmaktadır.

  • Mevcut anahtarı kurtarma
  • Yeni bir anahtar oluştur

Her bir kullanıcının giriş dizininde secret key ve Google Authenticator ayarları ~/.google-kimlik doğrulayıcısına kaydedilmektedir. Bu dosyanın ilk satırı bir secret key’ dir. Google kimlik doğrulayıcı dosyasının ilk satırını (secret key) görüntüleyen aşağıdaki komutu çalıştırarak key’ i hızlıca öğrenebilirsiniz. Sonrasında bu secret key’ i manuel olarak bir TOTP uygulamasına yazmalısınız.

$ head -n 1 /home/yenikullanici/.google_authenticator

Mevcut key’ i kullanmamak için bir neden varsa (örneğin, secret key’ i etkilenen kullanıcıya güvenli bir şekilde paylaşamıyorsanız veya mevcut key ele geçirildiğinde) “~/.google-authenticator” dosyasını tamamen kaldırabilirsiniz. Bu durum, “/etc/pam.d/sshd” dosyasındaki “nullok” kaldırılarak MFA uygulamasını zorlamadığınızı varsayarak kullanıcının tek bir faktörü kullanarak tekrar oturum açmasına izin verecektir. Daha sonra yeni bir key oluşturmak için google kimlik doğrulayıcısı çalıştırabilirsiniz.

TOTP Uygulamasına Erişim Kaybı

Sunucunuzda oturum açmanız gerekmektedir, ancak doğrulama kodunuzu almak için TOTP uygulamanıza erişemiyorsanız, secret key’ inizi ilk oluştururken görüntülediğiniz kurtarma kodlarını kullanarak giriş yapmaya devam edebilirsiniz. Bu kurtarma kodlarının bir kerelik kullanımı olduğunu unutmamalısınız. Bir kez oturum açmak için kullanıldığında, tekrar doğrulama kodu olarak kullanılamazlar.

Kimlik Doğrulama Ayarlarını Değiştirme

Başlangıç ​​yapılandırmasından sonra MFA ayarlarınızı değiştirmek isterseniz, güncellenmiş ayarlarla yeni bir yapılandırma oluşturmak yerine “~/.google-authenticator” dosyasını düzenleyebilirsiniz. Bu dosya aşağıdaki şekilde düzenlenmiştir:

<secret key>
<options>
<recovery codes>

Bu dosyada ayarlanan seçeneklerin, option bölümünde bir satırı vardır; ilk kurulum sırasında belirli bir seçeneğe “no” cevabını verdiyseniz, ilgili satır dosya dışında kalacaktır.

Bu dosyada yapabileceğiniz değişiklikler şunlardır:

Zamana dayalı kodlar yerine sequential kodları etkinleştirmek için “TOTP_AUTH” satırını “HOTP_COUNTER 1” olarak değiştirmelisiniz.

Tek bir kodun birden fazla kullanımına izin vermek için “DISALLOW_REUSE” satırını kaldırmalısınız.

Kod sona erdirme penceresini 4 dakikaya uzatmak için “WINDOW_SIZE 17.

Birden fazla başarısız oturum açmayı devre dışı bırakmak (deneme sınırlaması) için “RATE_LIMIT 3 30” satırını kaldırmalısınız.

Hız sınırlamasının eşiğini değiştirmek için, “RATE_LIMIT 3 30” satırı bulun ve sayıları ayarlamalısınız. Orjinaldeki “3” belirli bir süre boyunca yapılan denemelerin sayısını ve “30” süreyi saniye cinsinden gösterir.

Kurtarma kodlarını devre dışı bırakmak için, dosyanın altındaki beş 8 basamaklı kodu kaldırmalısınız.

MFA’yı Bazı Hesaplar için Önleme

Tek bir kullanıcının veya birkaç servis hesabının (kullanıcılar tarafından kullanılmayan hesapların) MFA etkin olmadan SSH erişimine ihtiyaç duyduğu bir durum olabilir. Örneğin, bazı FTP istemcileri gibi SSH kullanan bazı uygulamalar MFA’yı desteklemeyebilirler. Bir uygulamanın doğrulama kodunu talep etmesinin bir yolu yoksa, SSH bağlantısı bitene kadar istek çıkmaza girebilir.

“/etc/pam.d/sshd” dosyasındaki birkaç seçenek doğru olarak ayarlandığında, hangi faktörlerin kullanıcı bazında kullanıldığını kontrol edebilirsiniz.

Bazı hesaplar ve SSH key diğerleri için MFA’ e izin vermek için “/etc/pam.d/sshd” dosyasındaki şu ayarların etkin olduğundan emin olmalısınız.

#%PAM-1.0
auth required pam_sepermit.so
#auth substack password-auth

...

# Used with polkit to reauthorize users in remote sessions
-session optional pam_reauthorize.so prepare
auth required pam_google_authenticator.so nullok

Burada, şifrelerin devre dışı bırakılması gerektiğinden “auth substack password-auth” yorum satırı bırakılmıştır. Bazı hesaplarda MFA devre dışı olmasından dolayı MFA zorlanamaz, bu yüzden satır sonuna “nullok” seçeneği bırakılmıştır.

Bu yapılandırmayı ayarladıktan sonra, google-authenticator’ u MFA’ya gereksinim duyan kullanıcılar olarak çalıştırmanız yeterlidir ve yalnızca SSH anahtarlarının kullanılacağı kullanıcılar için çalıştırmamalısınız.

Kurulumu Yapılandırma Yönetimi ile Otomatikleştirme

Birçok sistem yöneticisi, sistemlerini yönetmek için Puppet, Chef veya Ansible gibi yapılandırma, otomasyon araçlarını kullanmaktadırlar. Böyle bir sistemi yeni bir kullanıcının hesabı oluşturulurken kurmak için kullanmak istiyorsanız bunu yapmanın bir yolu bulunmaktadır.

google-authenticator, tüm seçenekleri tek bir etkileşimli olmayan komut ile ayarlamak için komut satırı anahtarlarını desteklemektedir. Tüm seçenekleri görmek için, “google-authenticator –help” yazabilirsiniz.

$ google-authenticator -t -d -f -r 3 -R 30 -W

Bu, manuel cevapladığımız tüm soruları yanıtlar, bir dosyaya kaydeder ve ardından secret key, QR kodu ve kurtarma kodlarını çıkarmaktadır. (Eğer -q eklerseniz, çıktı olmayacaktır.) Bu komutu otomatik olarak kullanmak isterseniz, gizli anahtarı ve / veya kurtarma kodlarını yakaladığınızdan ve bunları kullanıcıya sunduğunuzdan emin olmalısınız.

MFA’yı Tüm Kullanıcılar için Zorlama

Eğer ilk girişte her bir kullanıcı için MFA kullanımını zorunlu tutmak isterseniz bunu yapmak gayet kolaydır. Bunun için kullanıcılar için genel bir “.google-authenticator” dosyasını kullanabilirsiniz, bu dosyaların içinde genel değerler olmalıdır ve kullanıcılara özel içinde herhangi bir veri olmamalıdır.

Bunu yapmak için, yapılandırma dosyası ilk oluşturulduktan sonra, kullanıcıların ilgili dosyasını home dizininine kopyalaması ve izinlerini uygun kullanıcıya değiştirmesi gerekmektedir. Ayrıca, dosyayı “/etc/skel/” dosyasına kopyalayabilirsiniz, böylece dosya oluşturulduğunda otomatik olarak yeni bir kullanıcının home dizinine kopyalayabilirsiniz.

Bir kullanıcının secret key’ inin oluşturulmasını zorlamak için kullanılan bir başka yöntem, bash komut dosyalarını kullanmaktır:

  1. Bir TOTP token’ ı oluşturur,
  2. Onlara Google Şifrematik uygulamasını indirmesini ve verilen QR kodunu taramasını ister,
  3. .google-authenticator dosyasının zaten olup olmadığını kontrol ettikten sonra onlar için google kimlik doğrulama uygulamasını çalıştırır.

Bir kullanıcı oturum açtığında komut dosyasının çalıştığından emin olmak için onu .bash_login olarak adlandırabilir ve home dizininin kök dizinine yerleştirebilirsiniz.

Bu dokümanda, makalede yazan komutları, çözümleri uygulamak tamamen kullanıcının kendi sorumluluğunda ve insiyatifin de olan bir konudur, mevcut komutların uygulanması ile doğabilecek, oluşabilecek her türlü sorumluluk ve sonuçlar kullanıcının kendisine aittir, CloudEOS’ un bu konuda herhangi bir sorumluluğu bulunmamaktadır.