SSH به صورت پیش‌فرض از کلمه عبور برای تأیید ورود استفاده می‌کند. این در حالی است که در بیشتر دستورالعمل‌های ارتقای امنیت SSH استفاده از کلید SSH برای این منظور توصیه می‌شود. با این وجود، کلید SSH با اینکه یک فاکتور بسیار امن‌تر است، باز هم یک مرحله تأییدیه ورودی SSH محسوب می‌شود. کانال امنیتی ایجاد شده از طریق ترمینال کامپیوتر شماست که داده‌ها را با یک تونل رمزنگاری‌شده به سیستم ریموت می‌فرستند. امّا همانند پسوردها، این کلیدها نیز توسط هکرها می‌توانند سرقت شوند و شخص حمله‌کننده با این قطعه کوچک داده می‌تواند کنترل سیستم ریموت شما را به دست گیرد.

در این ‌آموزش، از یک تأیید چندمرحله برای مقابله با این موضوع استفاده خواهیم کرد. تأیید چند مرحله‌ای (MFA) یا دو مرحله‌ای (2FA) به بیشتر از یک فاکتور برای تأیید ورود نیاز دارد. به این معنا که یک مهاجم باید از چند مرحله برای ورود به سیستم عبور کند. انواع مختلفی از فاکتورها برای این منظور مورد استفاده قرار می‌گیرند.

چیزهایی که خودتان از ‌آن اطلاع دارید؛ مانند کلمه عبور یا سؤال امنیتی.
داشته‌های کاربر؛ مانند یک برنامه تأیید کننده یا توکن امنیتی.
هویت کاربر؛ مانند اثر انگشت یا صدا.

یکی از فاکتورهای رایج برای این منظور برنامه OATH-TOTP همانند رمزساز گوگل است. کلمه عبور یک‌بار مصرف با تأیید آزاد مبتنی بر بازه زمانی که به اختصار OATH-TOTP نامیده می‌شود، یک پروتکل متن‌باز است که رمز یک‌بار مصرف تولید می‌کند. این رمز یک‌بار مصرف معمولاً یک کد ۶ رقمی است که هر ۳۰ ثانیه تجدید می‌شود.

در این مطلب به سراغ نحوه فعال‌سازی اپ OATH-TOTP در تأیید ورودی SSH می‌رویم که این موضوع، علاوه بر استفاده از کلید SSH خواهد بود. وارد شدن به سرور با استفاده از SSH نیاز به دو فاکتور از طریق دو کانال مجزا خواهد داشت و بنابراین، امنیتی بیشتری نسبت به حالت استفاده از پسورد یا کلید SSH تأمین می‌شود. همچنین به برخی کاربردهای خاص MFA و برخی ترفندهای مفید در این زمینه خواهیم پرداخت.

پیش‌نیازها

برای دنبال‌کردن مراحل این آموزش به موارد زیر احتیاج خواهید داشت:

یک سرور CentOS 8 با کاربر غیر روت و دسترسی sudo و کلید SSH.
یک گوشی هوشمند یا تبلت که در آن یک برنامه OATH-TOTP مانند رمزساز گوگل نصب شده باشد. البته به جای این مورد می‌توانید از برنامه خط فرمان لینوکس با نام oathtool برای تولید کد OATH-TOTP استفاده کنید. این برنامه در بسیاری از توزیع‌های لینوکس در دسترس است.

اگر واقعاً می‌خواهید اتصال SSH امنی داشته باشید، در اینجا به برخی اقدامات بسیار خوب در این زمینه اشاره می‌کنیم. از جمله ایجاد لیست سفید کاربران، لغو ورود کاربران روت و تغییر پورت دسترسی SSH.

گام ۱) نصب PAM گوگل

در این مرحله نصب و تنظیمات برنامه PAM گوگل را انجام می‌دهیم.

PAM که مخفف عبارت «ماژول تأییدیه جدا شدنی» است، یک زیرساخت تأیید ورودی است که در سیستم‌های لینوکس استفاده می‌شود. گوگل پس از ساخت یک برنامه OATH-TOTP، یک برنامه PAM نیز تولید کرده که با هر نوع از برنامه‌‌های OATH-TOTP سازگار است.

ابتدا بسته EPEL را در لینوکس اضافه می‌کنیم.


yum search epel

در صورتی که منابع شما حاوی بسته EPEL باشند، خروجی زیر را مشاهده خواهید کرد.


===== Name Matched: epel =====

epel-release.noarch : Extra Packages for Enterprise Linux repository configuration

حالا باید بسته epel-release را به منظور فعال‌سازی منبع EPEL نصب کنید.


sudo yum install epel-release

اگر بسته epel-release را ندارید، می‌توانید اطلاعات منبع را به صورت دستی نصب کنید.


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

سپس برنامه PAM را نصب می‌کنیم. در صورتی که برای اولین بار از منبع استفاده می‌کنید، از شما خواسته می‌شود که دریافت کلید EPEL را تأیید کنید. پس از تأیید این موضوع، در دفعات بعدی این پیغام برایتان ظاهر نمی‌شود.


sudo yum install google-authenticator qrencode-libs

با نصب PAM، یک برنامه هلپر نیز در کنار آن نصب می‌کنیم که کلید TOTP را برای کاربر موردنظر تولید خواهد کرد. این کلید برای هر کدام از کاربران ساخته می‌شود که با سیستم ارتباطی نخواهد داشت. به این معنا که هر کدام از کاربران که می خواهند از برنامه تأیید TOTP استفاده کنند، نیاز به ورود و اجرای برنامه هلپر برای دریافت کلید مخصوص به خودشان دارند. امکان اجرای ساده و فعال‌سازی آن برای هر شخصی وجود ندارد و در عین حال، با برخی ترفندها می‌توان MFA را برای تعداد بیشتری از کاربران تنظیم کرد.

برای شروع نصب این برنامه از دو فرمان زیر استفاده کنید.


google-authenticator -s ~/.ssh/google_authenticator

معمولاً تنها چیزی که احتیاج دارید، اجرای فرمان google-authenticator بدون هیچ‌گونه آرگومان خاصی است. امّا درنظر بگیرید که SELinux به ابزار SSH اجازه نمی‌دهد که فایل‌های خارج از دایرکتوری .ssh را در پوشه خانگی دستکاری کند. چنین چیزی از تأییدیه ورودی SSH جلوگیری خواهد کرد.

SELinux ابزار قدرتمندی است که از سیستم شما در مقابل حملات احتمالی محافظت می‌کند و ارزش آن را دارد که در حالت Enforcing اجرا شود. بر این اساس، خاموش کردن SELinux اصلاً توصیه نمی‌شود. به جای آن، می‌توانید موقعیت پیش‌فرض فایل google_authenticator را به دایرکتوری ~/.ssh انتقال دهید.

بعد از اجرای فرمان، با برخی پرسش‌ها روبرو خواهید شد. اولین پرسش، در مورد مبنای زمانی توکن‌های ورودی است.


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

این PAM به شما امکان داشتن توکن‌های با مبنای زمانی را می‌دهد. استفاده از توکن‌های دوره‌ای به این معناست که کد در مقطعی خاص اجرا می‌شود و پس از هر بار استفاده قطع می‌گردد و دارای محدودیت زمانی مشخص است. برنامه‌هایی مانند رمزساز گوگل بر این اساس کار می‌کنند و بنابراین این موضوع را با حرف y تأیید می‌کنیم.

پس از پاسخ به این سؤال، یک خروج طولانی در صفحه نمایش داده می‌شود؛ از جمله یک بارکد QR. با استفاده از برنامه موبایل خود این کد QR را اسکن کنید و یا به صورت دستی کلید امنیتی را وارد کنید. اگر کد QR برای اسکن‌کردن بسیار بزرگ بود، می‌توانید از آدرس اینترنتی بالای آن برای دریافت نسخه کوچکتر استفاده کنید. پس از اضافه‌کردن این کد، یک رمز ۶ رقمی را بر روی برنامه مشاهده خواهید کرد که هر ۳۰ ثانیه یک‌بار تغییر می‌کند.

نکته: به خاطر داشته باشید که حتماً کد رمز، کد تأیید و کدهای اولیه اضطراری را در یک جای امن، مانند یک برنامه password manager نگهداری کنید. در صورتی که نتوانید به سیستم دسترسی پیدا کنید و مثلاً نتوانید به برنامه TOTP وارد شوید، کدهای اولیه اضطراری تنها راه نجات شما خواهند بود.

بررسی پرسش‌های بعدی

پرسش‌های بعدی در مورد نحوه عملکرد PAM خواهند بود. در اینجا، آنها را یک به یک بررسی می‌کنیم.


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

در اینجا کلید و گزینه‌های موردنیاز در فایل google_authenticator نوشته می‌شوند. اگر با حرف n آن را تأیید نکنید، برنامه متوقف شده و چیزی در فایل نوشته نمی‌شود. به این معنا که برنامه تأیید کننده عمل نخواهد کرد.


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

با پاسخ مثبت به این سؤال، از حملات ناشی از تکرار استفاده از هر کد پس از انقضا در برنامه جلوگیری خواهید کرد. در این حالت، شخص مهاجم نمی‌‌تواند کدی را که به تازگی دریافت شده، برای تأییدیه ورودی SSH به کار ببرد.


By default, a new token is generated every 30 seconds by the mobile app.

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. This allows for a

time skew of up to 30 seconds between authentication server and client. If you

experience problems with poor time synchronization, you can increase the window

from its default size of 3 permitted codes (one previous code, the current

code, the next code) to 17 permitted codes (the 8 previous codes, the current

code, and the 8 next codes). This will permit for a time skew of up to 4 minutes

between client and server.

Do you want to do so? (y/n) n

جواب مثبت به این سؤال، امکان داشتن حداکثر ۱۷ کد مورد تأیید را در یک بازه زمانی ۴ دقیقه‌ای می‌دهد. در غیر این صورت و با زدن حرف n، تنها ۳ کد در عرض یک و نیم دقیقه در دسترس قرار می‌گیرند. در صورتی که با این بازه زمانی مشکلی ندارید، پاسخ no گزینه امن‌تری برایتان خواهد بود. در صورتی که بعداً تشخیص دادید که به بازه زمانی بیشتری نیاز دارید، می‌توانید این موضوع را در دایرکتوری خانگی و فایل .google_authenticator تغییر دهید.


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

محدودیت نرخ یا Rate limiting به معنای این است که یک مهاجم خارجی می‌تواند تنها چند حدس برای کد ورودی داشته باشد و باید یک دوره زمانی برای تلاش دوباره منتظر بماند. اگر قبلاً این تنظیم را برای SSH انجام نداده‌اید، اکنون می‌تواند از نظر امنیتی بسیار مفید واقع شود.

وقتی این مرحله را تکمیل کردید، در صورت تمایل به پشتیبان‌گیری از کلید رمزتان، می توانید فایل ~/.ssh/google-authenticator در موقعیت مناسب کپی نمایید. سپس می‌توانید آن را در سیستم‌های دیگر و یا نصب‌های دیگر برنامه به کار بگیرید. امّا به خاطر داشته باشید که استفاده از کلید یکسان در چند سیستم باعث می‌شود که کار مهاجمان در دسترسی به سرور راحت‌تر شود. در هر صورت، باید ارزیابی مناسبی از میزان ریسک این کار در مقابل داشتن توکن متفاوت برای هر سیستم و مدیریت این توکن‌ها داشته باشید.

نکته: اگر از فولدر خانگی رمزنگاری‌شده استفاده می‌کنید که موضوعی خارج از بحث آموزشی در این مطلب است، احتمالاً نیاز به ذخیره فایل ~./google-authenticator در دایرکتوری‌ای خارج از فولدر خانگی دارید. پروژه README در گیت‌هاب جزئیات بیشتری در این رابطه ارائه کرده است.

از آنجایی که فایل تنظیمات را در یک موقعیت غیراستاندارد ذخیره کرده‌ایم، باید کانتکس SELinux را بر اساس موقعیت جدیدش بازیابی کنیم.

برای این منظور، فرمان زیر را تایپ کنید.


restorecon -Rv ~/.ssh/

با انجام این دو تغییر، در حال حاضر برنامه Google Authenticator PAM را نصب و تنظیم کرده‌ایم. مرحله بعدی، تنظیم SSH برای استفاده از کلید TOTP است. باید به SSH برنامه PAM را معرفی کنیم و سپس تنظیمات استفاده آن را انجام دهیم.

گام ۲) تنظیم OpenSSH برای استفاده از MFA/2FA

تغییرات در SSH را از طریق SSH انجام می‌دهیم و در نتیجه، حفظ اتصال اولیه SSH برایمان اهمیت خواهد داشت. یک اتصال ثانویه SSH برای انجام تست باز می‌کنیم. چنین کاری باعث می‌شود که در صورت وجود اشتباه در تنظیمات SSH، دسترسی به سرور قطع نشود. پس از اطمینان از روند انجام کار، می‌توانید به‌راحتی هر اتصال دیگری را قطع کنید. نکته احتیاطی دیگر، ایجاد یک نسخه پشتیبان از فایل‌های سیستمی است تا در صورت وقوع خطا در ویرایش، به این نسخه برگردید و دوباره کار را شروع کنید.

برای شروع به کار، از فایل تنظیمات sshd تنظیمات بگیرید و سپس آن را ویرایش کنید. در اینجا از ویرایشگر متنی nano استفاده می‌کنیم که البته به صورت پیش‌فرض در لینوکس CentOS نصب نشده است. می‌توانید با فرمان sudo yum install nano آن را نصب کنید و یا از ویرایشگر متن دلخواه دیگری استفاده کنید.

از فایل پشتیبان‌گیری کرده و آن را باز کنید.


sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak

sudo nano /etc/pam.d/sshd

خط زیر را به انتهای فایل اضافه کنید.


auth       required     pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator

nullok

auth       required     pam_permit.so

به دلیل اینکه فایل google_authenticator config را در یک موقعیت غیر استاندارد قرار داده‌ایم، باید مسیر این فایل تنظیمات را برای PAM مشخص کنیم. گزینه secret به برنامه PAM موقعیت فایل تنظیمات را اطلاع می‌دهد.

واژه nullok در انتهای خط نیز برای PAM مشخص می‌کند که این روش ورودی به صورت اختیاری است. در نتیجه، کاربران می‌توانند همچنان بدون توکن OATH-TOTP، با کلید SSH خودشان وارد شوند. وقتی تمام کاربران به توکن OATH-TOTP دسترسی پیدا کردند، می‌توانید nullok را از این خط حذف کنید و روش MFA را به گزینه‌ای همیشگی تبدیل نمایید.

خط دوم با pam_permit.so در صورت نداشتن توکن MFA برای تأییدیه ورودی SSH ضروری است. هر کدام از روش‌ها برای ورود نیاز به پاسخ SUCCESS دارد. اگر کاربری با گزینه nullok از ابزار تأیید چند مرحله‌ای استفاده نکرد، پیغامی مبنی بر نادیده گرفتن برای کاربر به کار برده می‌شود. بنابراین اگر خط اول نادیده گرفته شده، خط بعدی با pam_permit.so پیغام SUCCESS را نمایش خواهد داد و به کاربر اجازه ورود می‌دهد.

حالا باید فایل را ذخیره کرده و ببندید.

سپس SSH را برای پشتیبانی از این نوع تأییدیه ورودی تنظیم کنیم.

ابتدا از فایل تنظیمات SSH پشتیبان گرفته و آن را برای ویرایش باز کنید.


sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sudo nano /etc/ssh/sshd_config

در این فایل به سراغ خطی بگردید که با ChallengeResponseAuthentication آغاز شود. خط no را با اضافه کردن علامت هشتگ به کامنت تبدیل کنید و برعکس این کار را با خط yes انجام دهید. در نتیجه، فایل شما به صورت زیر خواهد بود.


. . .

# Change to no to disable s/key passwords

ChallengeResponseAuthentication yes

#ChallengeResponseAuthentication no

. . .

فایل را ذخیره کرده و از آن خارج شوید. سپس SSH را دوباره راه‌اندازی کنید تا تنظیمات جدید اِعمال شوند. به خاطر داشته باشید که راه‌اندازی دوباره سرویس sshd موجب از دست رفتن اتصال‌های باز کنونی نمی‌شود. بنابراین، حتماً با فرمان زیر از ریسک قفل‌شدن دسترسی‌تان جلوگیری کنید.


sudo systemctl restart sshd.service

برای آزمایش کارآیی اقداماتی که تاکنون انجام داده‌ایم، یک پنجره ترمینال دیگر باز کنید و سعی کنید از طریق SSH وارد شوید. حتماً اتصال کنونی SSH را به صورت باز نگه دارید و یک اتصال دیگر را امتحان کنید. در غیر این صورت ممکن است در مقطعی دسترسی شما قفل شود و سپس به کنسول وب برای بازگشت به سرور احتیاج خواهید داشت.

نکته: اگر قبلاً یک کلید SSH ایجاد کرده‌اید و در حال استفاده از آن هستید، مشاهده می‌کنید که نیاز به تایپ کلمه عبور یا کد تأییدیه MFA ندارید. این موضوع به این دلیل است که یک کلید SSH به صورت پیش‌فرض تمام گزینه‌های دیگر تأیید را تحت پوشش قرار می‌دهد. در غیر این صورت، پیغامی مبنی بر ورود پسورد یا کد تأییدیه برایتان نمایش داده خواهد شد.

در گام بعدی، برای فعالسازی کلید SSH به عنوان یک فاکتور و کد تأییدیه برای فاکتور ثانویه، باید برای SSH مشخص کنیم که دیگر از کلید SSH برای پوشش سایر روش‌های تأییدیه استفاده نکند.

گام ۳) آگاه‌سازی SSH نسبت به MFA

دوباره فایل تنظیمات sshd را باز کنید.


sudo nano /etc/ssh/sshd_config

خط زیر را در انتهای فایل اضافه کنید. در اینجا به SSH گفته می‌شود که کدام روش تأییدیه ورودی SSH موردنیاز خواهد بود. یعنی یک کلید SSH و یک پسورد یا کد تأییدیه ( و یا هر سه) مورد نیاز هستند.


. . .

AuthenticationMethods publickey,password publickey,keyboard-interactive

حالا فایل را ذخیره کرده و ببندید.

سپس فایل تنظیمات PAM sshd را دوباره باز کنید.


sudo nano /etc/pam.d/sshd

در بالای فایل، خط auth substack password-auth را باز کنید. این خط را با اضافه کردن علامت هشتگ به کامنت تبدیل کنید. در نتیجه، PAM پسورد را درخواست نخواهد کرد.


. . .

#auth       substack     password-auth

. . .

فایل را ذخیره کرده و ببندید. سپس SSH را دوباره راه‌اندازی کنید.


sudo systemctl restart sshd.service

حالا سعی کنید با یک ترمینال دیگر وارد سرور شوید. برخلاف دفعه قبلی، این بار SSH از شما درخواست وارد کردن کد تأییدیه را می‌دهد. پس از وارد کردن این کد، وارد سرور خواهید شد. با اینکه نشانه‌ای از کاربرد کلید SSH نمی‌بینید، ولی در تأییدیه ورودی SSH از دو فاکتور استفاده شده است. اگر می‌خواهید این موضوع را بررسی کنید، گزینه -v را بعد از فرمان SSH اضافه کنید.

نمونه خروجی


. . .

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /Users/sammy/.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:

در انتهای خروجی، مشاهده می‌کنید که SSH از کلیدهای شما استفاده کرده و سپس کد تأیید را از شما درخواست کرده است. حال می‌توانید با یک کلید SSH و پسورد یک‌بار مصرف وارد شوید. اگر می‌خواهید سیستم را ملزم به استفاده از سه روش تأیید کنید، می‌توانید مرحله بعدی را دنبال نمایید.

حالا به‌درستی فاکتور ثانویه را برای ورود به سرور از طریق SSH اضافه کرده‌اید. کار اصلی موردنظر این آموزش در اینجا به اتمام می‌رسد. آنچه در ادامه می‌آید، برخی ترفندها و دستورالعمل‌ها برای بازیابی، کارآیی خودکار و مواردی از این قبیل است.

گام ۴) اضافه کردن فاکتور سوم تأییدیه ورودی SSH (اختیاری)

در گام ۳، روش‌های تأیید شده را در فایل sshd_config لیست کردیم.

کلید عمومی (کلید SSH)
کلید عمومی پسورد (کلمه عبور)
تعامل کیبورد (کد تأییدیه)

امّا درنظر بگیرید که با گزینه‌هایی که تاکنون داشته‌ایم، تنها امکان استفاده از یک کلید SSH و یک کد تأیید را داده‌اند. اگر می خواهید هر سه فاکتور (کلید SSH، پسورد و کد تأیید) را در کنار هم داشته باشید، یک تغییر سریع برای این منظور نیاز دارید.

فایل تنظیمات PAM sshd را باز کنید.


sudo nano /etc/pam.d/sshd

خطی را که اخیراً با هشتگ به کامنت تبدیل کردید، یعنی #auth substack password-auth را پیدا کنید و هشتگ آن را بردارید. فایل ذخیره کرده و ببندید. حالا دوباره، SSH را اجرا کنید.


sudo systemctl restart sshd.service

در نتیجه، PAM علاوه بر کلید SSH و کد تأیید، کلمه عبور را نیز از شما درخواست خواهد کرد. حالا از چیزی که می‌دانیم (پسورد) و دو نوع مختلف از چیزهایی که داریم ( کد تأیید و کلید SSH) از دو کانال مجزا (کامپیوتر و گوشی هوشمند) برای تأیید ورودی استفاده می‌شود.

گام ۵) بازیابی دسترسی به تأیید چندمرحله‌ای گوگل (اختیاری)

همانند هر سیستم دیگری که در آن اقدام امنیتی انجام می‌دهید، مسئول مدیریت امنیت آن نیز خواهید بود. به این معنا که نباید کلید SSH، یا کلید رمز TOTP را از دست بدهید و حتماً بتوانید به برنامه TOTP دسترسی داشته باشید. با این وجود، گاهی اوقات ممکن است شرایط از کنترل شما خارج شود و نتوانید از کلیدها و برنامه‌های موردنیاز برای تأیید ورودی استفاده کنید.

عدم دسترسی به کلید رمز

اگر کلید رمز TOTP را از دست بدهید، روند بازیابی می‌تواند به چند مرحله تقسیم شود. اولین مرحله، بازگشت بدون دانستن کد تأییدیه و دومی، پیدا کردن کلید رمز یا بازتولید آن برای ورود MFA به صورت عادی است. چنین چیزی ممکن است در مواقعی رخ بدهد که شما گوشی نو بخرید و کلیدهای رمز را به برنامه جدید رمزساز انتقال نداده باشید.

شما دو گزینه برای بازگشت در اختیار دارید.

دسترسی کنسولی (لوکال/ غیر SSH) به سیستم (معمولاً فیزیکی با ابزاری مانند iDrac)
استفاده از یک کاربر متفاوت که تأییدیه ورودی MFA برایش فعال نباشد.

گزینه دوم، روش نامطمئن‌تری محسوب می‌شود؛ چرا که هدف از استفاده از MFA ارتقای امنیت تمام ارتباط‌های ssh است. ولی اگر دسترسی‌تان را به برنامه رمزساز MFA از دست بدهید، امنیت سیستم زیر سؤال می‌رود.

به محض وارد شدن به سیستم، دو راه برای دریافت رمز TOTP وجود دارند:

بازیابی کلید کنونی
ایجاد یک کلید جدید

در دایرکتوری خانگی هر کدام از کاربران، کلید رمز و تنظیمات رمزساز گوگل در فایل ~/.ssh/google-authenticator ذخیره شده‌اند. اولین خط در این فایل، یک کلید رمز است. روش سریع برای دریافت کلید، اجرای فرمان زیر خواهد بود. پس از دریافت این کد، آن را به صورت دستی در برنامه TOTP تایپ کنید.


head -n 1 /home/sammy/.ssh/google_authenticator

وقتی کلید کنونی را بازیابی کردید، می‌توانید یا آن را به صورت دستی در برنامه رمزساز وارد کنید و یا با وارد جزئیات در آدرس اینترنتی زیر یک بارکد QR از گوگل دریافت کرده و آن را اسکن نمایید. در اینجا باید کلمه کاربری، عنوان هاست و کلید رمز را از فایل google-authenticator را وارد کرده و همین‌طور هر اسمی برای ‘entry-name-in-auth-app’ انتخاب نمایید تا به راحتی این کلید را نسبت به توکن TOTP تشخیص دهید.


https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/username@hostname%3Fsecret%3D16-char-secret%26issuer%3Dentry-name-in-auth-app

اگر به هر دلیلی امکان استفاده از کلید کنونی وجود ندارد (مثلاً نمی‌توانید به شکلی ایمن، کلید رمز را با کاربر به اشتراک بگذارید)، می‌توانید فایل ~/.ssh/google-authenticator را حذف کنید. چنین کاری باعث می‌شود که کاربر بتواند دوباره با یک فاکتور تأییدیه ورودی SSH را دریافت کند. البته با این فرض که شما واژه nullok را در فایل /etc/pam.d/sshd حذف نکرده‌اید و کاربران اجباری به استفاده از MFA ندارند.

عدم دسترسی به برنامه TOTP

اگر برای تأیید ورودی SSH نمی‌توانید به برنامه TOTP دسترسی داشته باشید تا کد تأییدیه را دریافت کنید، همچنان می‌توانید از کدهای بازیابی که اولین بار در هنگام تولید کلید رمز برایتان نمایش داده شده‌اند، استفاده کنید. البته به خاطر داشته باشید که این کدهای بازیابی تنها یک بار قابل‌استفاده هستند. این کدها را باید در مکان امنی نگهداری کنید تا وقتی به برنامه TOTP دسترسی ندارید، به کمک شما بیایند.

گام ۶) تغییر تنظیمات تأییدیه ورودی SSH (اختیاری)

برای تغییر در تنظیمات اولیه MFA، می‌توانید فایل ~/.ssh/google-authenticator را ویرایش کنید. قالب این فایل به شکل زیر است.


<secret key>

<options>

<recovery codes>

گزینه‌های تنظیم‌شده در این فایل دارای خط مخصوص به خود در بخش options هستند. اگر در طول نصب اولیه، برای یک گزینه خاص، پاسخ “no” را انتخاب کرده‌اید، خط مربوط به آن از فایل حذف شده است. به عبارت دیگر، این فایل تنها حاوی گزینه‌های فعال خواهد بود. اگر هم گزینه‌ای در آن وجود ندارد، به صورت پیش‌فرض غیرفعال شده است.

در اینجا به برخی از تغییراتی که می‌توانید در این فایل انجام دهید، اشاره می‌کنیم.

برای فعال کردن کدهای متوالی، به جای کدهای مبتنی بر دوره زمانی، خط TOTP_AUTH را به HOTP_COUNTER 1 تغییر دهید.
برای امکان استفاده چندگانه از یک کد، خط DISALLOW_REUSE را حذف کنید.
برای گسترش دوره زمانی انقضای کد به ۴ دقیقه، خط WINDOW_SIZE 17 را اضافه نمایید.
برای غیرفعال‌کردن حالت تلاش‌ ورود ناموفق، خط RATE_LIMIT 3 30 را حذف کنید.
برای تغییر آستانه تلاش‌های ناموفق ورودی، خط RATE_LIMIT 3 30 را پیدا کرده و اعداد آن را اصلاح کنید. عدد ۳ در عبارت اولیه به معنای تعداد تلاش‌ها در یک دوره زمانی و ۳۰ نیز نشان‌دهنده این دوره زمانی به ثانیه است.
برای غیرفعال‌کردن کدهای بازیابی، پنج کد ۸ رقمی موجود در قسمت پایین را حذف کنید.

گام ۷) صرف‌نظر از تأیید ورودی MFA برای برخی حساب‌های کاربری (اختیاری)

گاهی اوقات ممکن است که برای یک کاربر خاص یا برخی کاربران خدماتی (مثلاً کاربری‌هایی که توسط اپلیکیشن‌ها استفاده می‌شوند) نیاز به تأییدیه ورودی SSH بدون MFA داشته باشید. به عنوان نمونه، برخی اپلیکیشن‌ها که از SSH استفاده می‌کنند، از جمله کلاینت‌های FTP ممکن است از MFA پشتیبانی نکنند. اگر اپلیکیشن راهی برای درخواست کد تأییدیه نداشته باشد، این درخواست در حالت معلق باقی می‌مانند تا زمان اتصال SSH به پایان برسد.

تا زمانی که تنظیمات چند گزینه را در /etc/pam.d/sshd به‌درستی انجام داده باشید، می‌توانید فاکتور‌های تأییدیه ورودی SSH را بر اساس هر کاربر مدیریت کنید.

برای تنظیم MFA برای برخی حساب‌های کاربری و کلید SSH برای دیگر کاربران، حتماً دقت کنید که تنظیمات زیر در /etc/pam.d/sshd فعال باشند.


#%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

در اینجا auth substack password-auth به این دلیل به صورت کامنت درآمده تا پسوردها غیرفعال باشند. در حالتی که MFA برای برخی حساب‌های کاربری غیرفعال باشد، MFA نمی‌تواند اجباری باشد. بنابراین، باید گزینه nullok را در خط آخر به همین شکل رها کرد.

پس از انجام این تنظیم، برنامه رمزساز گوگل را تنها برای کاربرانی اجرا کنید که به MFA نیاز دارند. کاربرانی که تنها از کلیدهای SSH استفاده می‌کنند، نیازی به انجام این کار نخواهند داشت.

گام ۸) تنظیم خودکار با ابزارهای مدیریت تنظیمات (اختیاری)

بسیاری از مدیران سیستم از ابزارهای مدیریت تنظیمات مانند Puppet، Chef یا Ansible استفاده می‌کنند. اگر قصد دارید که از سیستمی مانند در زمان ساخت یک حساب کاربری جدید و تنظیم کلید رمز بهره ببرید، یک راه ساده برای این منظور وجود دارد.

برنامه رمزساز گوگل از سوئیچ‌های خط فرمان برای تنظیم تمام گزینه‌ها در یک خط فرمان استفاده می‌کند. برای مشاهده تمام گزینه‌های در دسترسی، می‌توانید فرمان google-authenticator –help را تایپ کنید. در پایین فرمانی را می‌بینید که همه موارد اشاره شده در گام ۱ را تنظیم می‌کند.


google-authenticator -t -d -f -r 3 -R 30 -w 3 -s ~/.ssh/google_authenticator

توضیح گزینه‌ها

گزینه‌هایی که در بالا به آنها اشاره شد از قرار زیرند:

-t => شمارنده واحد زمانی

-d => عدم امکان استفاده دوباره از توکن

-f => اجبار به نوشتن تنظیمات در فایل بدون اطلاع‌رسانی به کاربر

-r => تعداد تلاش‌ها برای وارد کردن کد صحیح

-R => مدت زمان به ثانیه که کاربر می‌تواند برای وارد کردن کد صحیح اقدام کند

-w => تعداد کدهایی که در هر زمان در دسترس هستند (دوره زمانی یک و نیم تا ۴ دقیقه)

-s => مسیر فایل تأییدیه ورودی که باید ذخیره شود

تمام اینها به سؤالاتی که قبلاً به صورت دستی وارد می‌کردیم، پاسخ می‌دهد، آن را در یک فایل ذخیره می‌کند و سپس در خروجی، کلید رمز، بارکد QR و کدهای بازیابی را ارائه می‌دهد. البته در صورتی که از گزینه -q استفاده کنید، هیچ‌گونه خروجی‌ای مشاهده نخواهید کرد. اگر این فرمان را به صورت خودکار استفاده می‌کنید، حتماً کلید رمز و یا کدهای بازیابی را دریافت کرده و در دسترس کاربر قرار دهید. همچنین به خاطر داشته باشید که حالت بازیابی خودکار SELinux را در دایرکتوری .ssh داشته باشید.

گام ۹) اجبار MFA برای تأییدیه ورودی SSH تمام کاربران (اختیاری)

اگر قصد دارید که MFA را برای تأیید ورود تمام کاربران اجباری کنید و این موضوع را حتی در اولین ورود کاربر داشته باشید، یک روش ساده و آسان برای این منظور وجود دارد. شما به‌راحتی می‌توانید از فایل google-authenticator برای هر کدام از کاربران استفاده کنید و در این حالت، هیچ‌گونه داده مختص کاربر در فایل ذخیره نخواهد شد.

برای این منظور، پس از ایجاد فایل تنظیمات اولیه، یک کاربر با دسترسی‌های لازم باید فایل را به دایرکتوری .ssh در مسیر خانگی هر کدام از کاربران کپی کند و مجوّزهای لازم را برای آنها تنظیم نماید. همچنین می‌توانید فایل را به آدرس /etc/skel/ کپی کنید تا به صورت اتوماتیک در هنگام ساخت کاربر جدید، وارد دایرکتوری خانگی این کاربر شود.

هشدار

چنین چیزی می‌تواند یک ریسک امنیتی به همراه داشته باشد؛ چرا که تمام کاربران از یک فاکتور ثانویه مشترک استفاده می‌کنند. به این معنا که اگر این فاکتور جایی درز پیدا کند، هر کاربر تنها یک فاکتور برای تأییدیه ورودی SSH در اختیار خواهد داشت. این نکته را حتماً در هنگام استفاده از این روش درنظر داشته باشید.

روش دیگر برای اجبار به تولید کلید رمز هر کاربر، استفاده از یک bash اسکریپت خواهد بود. این اسکریپت باید کارهای زیر را انجام دهد:

ساخت یک توکن TOTP
اطلاع به کاربر برای دریافت برنامه رمزساز گوگل و اسکن بارکد QR که نمایش داده می‌شود.
اجرای اپلیکیشن google-authenticator بعد از بررسی وجود فایل google-authenticator برای کاربران.

برای اطمینان از اجرای اسکریپت در هنگام ورود یک کاربر، می توانید نام آن را .bash_login قرار دهید و آن را در دایرکتوری روت خانگی کاربران بگذارید.

جمع‌بندی

در این ‌آموزش، دو فاکتور (یک کلید SSH در کنار توکن MFA) از طریق دو کانال مختلف (کامپیوتر و موبایل) برای تأییدیه ورودی SSH به سرور اضافه کردیم. در نتیجه، ورود ناشناس و غیرقانونی به سرور از طریق SSH بسیار مشکل خواهد شد و سطح امنیت سیستم شما بسیار بالا خواهد رفت.