تنظیم کلید SSH در اوبونتو شامل ساخت جفت‌کلید روی رایانهٔ مدیر، نصب کلید عمومی برای حساب مقصد و آزمون اتصال است. کلید خصوصی نزد شما می‌ماند. این راهنما برای سروری است که از قبل مسیر مدیریتی مجاز دارد؛ افزودن کلید نباید بهانهٔ فعال کردن ورود ناامن یا حذف روش بازیابی باشد.
پیش‌نیاز تنظیم کلید SSH در اوبونتو
یک حساب مقصد مشخص، دسترسی مدیریتی موجود و کنسول بازیابی داشته باشید. تا پایان آزمون، نشست قبلی را باز نگه دارید. username و server.example.com در نمونه‌ها جای نام کاربر و نشانی واقعی سرورند. دستورهای ساخت کلید روی رایانهٔ شما اجرا می‌شوند، نه سرور مقصد.
۱. ساخت جفت‌کلید مشخص
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_hostnegarطبق راهنمای ssh-keygen، می‌توان نوع و مسیر کلید را صریحاً انتخاب کرد؛ به پیش‌فرض نسخهٔ نرم‌افزار تکیه نکنید. اگر فایل قبلاً وجود دارد، آن را بازنویسی نکنید و نام دیگری برگزینید. برای حفاظت از کلید خصوصی، عبارت عبور مناسب تنظیم کنید.
فایل بدون پسوند، کلید خصوصی و فایل دارای .pub، کلید عمومی است. عبارت عبور کلید با رمز حساب سرور تفاوت دارد. در محیط دارای الزام سازگاری خاص یا FIPS، الگوریتم را طبق سیاست همان محیط انتخاب کنید؛ Ed25519 را برای همهٔ پیکربندی‌ها مجاز فرض نکنید.
۲. بررسی هویت سرور
در اولین اتصال، اثر انگشت کلید میزبان نمایش داده می‌شود. قبل از قبول، آن را با اطلاعات دریافت‌شده از کنسول معتبر یا مدیر سرور تطبیق دهید. برای کلید Ed25519 میزبان، مدیر می‌تواند از کنسول این فرمان را اجرا کند:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubمرجع SSH روش بررسی کلید میزبان را توضیح می‌دهد. ناشناخته بودن میزبان به معنی معتبر بودن آن نیست. اگر اثر انگشت قبلی تغییر کرده، ابتدا نصب مجدد، تغییر سرور یا احتمال اتصال اشتباه را بررسی کنید.
۳. نصب فقط کلید عمومی
روی کلاینت دارای ssh-copy-id، از مسیر ورود مجاز موجود استفاده کنید:
ssh-copy-id -i ~/.ssh/id_ed25519_hostnegar.pub username@server.example.comاگر پورت سفارشی دارید، گزینهٔ p و همان پورت را اضافه کنید. ssh-copy-id کلید عمومی مشخص‌شده را برای حساب مقصد نصب می‌کند. نبود این ابزار در بعضی کلاینت‌ها طبیعی است.
در روش دستی، از کنسول یا نشست مجاز همان حساب، پوشهٔ .ssh را با مجوز ۷۰۰ آماده کنید و خط کامل فایل .pub را به انتهای ~/.ssh/authorized_keys اضافه کنید. کلیدهای قبلی را حذف نکنید. مجوز فایل را ۶۰۰ و مالک آن را همان حساب مقصد نگه دارید. هنگام کار با root، علامت ~ به خانهٔ root اشاره می‌کند؛ مسیر حساب دیگر را اشتباه نگیرید.
۴. آزمون واقعی ورود با کلید
ssh -i ~/.ssh/id_ed25519_hostnegar -o IdentitiesOnly=yes -o PreferredAuthentications=publickey username@server.example.comاین آزمون را در پنجره‌ای تازه اجرا کنید. ممکن است عبارت عبور کلید خصوصی خواسته شود؛ این موضوع به معنی استفاده از رمز حساب سرور نیست. پس از ورود، whoami و در صورت نیاز sudo -v را بررسی کنید.
۵. محدود کردن ورود رمزی؛ مرحلهٔ اختیاری
تنها وقتی همهٔ مدیران لازم ورود با کلید را آزموده‌اند و کنسول در دسترس است، سیاست احراز هویت را تغییر دهید. برای سرور سادهٔ بدون MFA یا keyboard-interactive موردنیاز، گزینه‌های زیر قابل بررسی‌اند:
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication noاین نمونه برای سرور دارای MFA آمادهٔ کپی نیست؛ خاموش کردن keyboard-interactive می‌تواند عامل دوم را از کار بیندازد. فایل اصلی و Includeها و قواعد Match را بررسی کنید. نخستین مقدار مؤثر بسیاری از گزینه‌ها اهمیت دارد؛ وجود یک خط در فایل، به معنی فعال بودن آن نیست.
با sudo /usr/sbin/sshd -t صحت تنظیم را بررسی کنید. سپس تنظیم مؤثر را با T و در صورت وجود Match با پارامترهای اتصال مناسب C ببینید. در اوبونتویی که واحد ssh.service فعال است، برای بارگذاری تغییر احراز هویت از sudo systemctl reload ssh.service استفاده کنید. اگر سرویس یا روش اجرا متفاوت است، همان واحد واقعی را بررسی کنید. دوباره اتصال تازه را آزمایش کنید و تا آن زمان نشست قبلی را نبندید.
رفع خطای Permission denied
نام حساب، کلید انتخاب‌شده، مجوز و مالک authorized_keys و گزارش احراز هویت سرور را بررسی کنید. برای جزئیات کلاینت می‌توان از گزینهٔ v استفاده کرد؛ خروجی را پیش از اشتراک‌گذاری از اطلاعات حساس پاک کنید. برای حل خطا، کلید خصوصی را روی سرور کپی نکنید و کنترل هویت میزبان را غیرفعال نکنید.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
