نام (NAME)

sshd - دیمن کارساز OpenSSH

خلاصه دستور (SYNOPSIS)

sshd [-46DdeGiqTtV] [-C connection_spec] [-c host_certificate_file] [-E log_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-o option] [-p port] [-u len]

توضیحات (DESCRIPTION)

sshd (OpenSSH Daemon) دیمن و کارساز برنامه ssh(1) است. این برنامه ارتباطات رمزنگاری‌شده امنی را میان دو میزبان غیرقابل‌اعتماد بر روی یک شبکه ناامن برقرار می‌سازد.

sshd به اتصالات دریافتی از سوی کلاینت‌ها گوش فرا می‌دهد. این سرویس معمولاً هنگام بوت سیستم از /etc/rc راه‌اندازی می‌شود. برای هر اتصال ورودی، یک دیمن جدید منشعب می‌کند (fork). دیمن‌های منشعب‌شده، تبادل کلید، رمزنگاری، احراز هویت، اجرای دستورات و تبادل داده‌ها را مدیریت می‌کنند.

sshd می‌تواند با استفاده از گزینه‌های خط فرمان یا یک فایل پیکربندی (به‌طور پیش‌فرض sshd_config(5)) پیکربندی شود؛ گزینه‌های خط فرمان مقادیر مشخص‌شده در فایل پیکربندی را بازنویسی می‌کنند. sshd هنگامی که سیگنال قطع ارتباط، SIGHUP ، را دریافت می‌کند، با اجرای مجدد خود با نام و گزینه‌هایی که با آن‌ها آغاز شده بود (مانند /usr/sbin/sshd) ، فایل پیکربندی‌اش را بازخوانی می‌نماید.

گزینه‌ها به شرح زیر هستند:

-4

sshd را وادار می‌کند تنها از نشانی‌های IPv4 استفاده کند.

-6

sshd را وادار می‌کند تنها از نشانی‌های IPv6 استفاده کند.

-C connection_spec

پارامترهای اتصال را برای استفاده در حالت آزمایشی گسترش‌یافته -T مشخص می‌کند. در صورت تعیین، هرگونه دستورالعمل Match در فایل پیکربندی که قابل اعمال باشد، پیش از نوشتن پیکربندی در خروجی استاندارد اعمال خواهد شد. پارامترهای اتصال به‌صورت جفت‌های keyword=value ارائه می‌شوند و می‌توان آن‌ها را به هر ترتیبی، چه با چندین گزینه -C و چه به‌صورت یک فهرست جداشده با کاما تعیین کرد. کلمات کلیدی عبارتند از “addr”, “user”, “host”, “laddr”, “lport” و “rdomain” که به ترتیب متناظر با نشانی مبدأ، کاربر، نام میزبان مبدأ اعتبارسنجی‌شده (resolved)، نشانی محلی، شماره پورت محلی و دامنه مسیریابی (routing domain) هستند. علاوه بر این، پرچم “invalid-user” (که آرگومان مقداری دریافت نمی‌کند) را می‌توان برای شبیه‌سازی اتصال از سوی یک نام کاربری ناشناخته مشخص کرد.

-c host_certificate_file

مسیری را به یک فایل گواهی برای شناسایی sshd در طول تبادل کلید مشخص می‌کند. فایل گواهی باید با فایل کلید میزبانی که با استفاده از گزینه -h یا دستورالعمل پیکربندی HostKey تعیین شده است، مطابقت داشته باشد.

-D

هنگامی که این گزینه مشخص شود، sshd از ترمینال جدا نمی‌شود (detach نمی‌کند) و به یک دیمن پس‌زمینه تبدیل نمی‌گردد. این قابلیت امکان نظارت آسان بر sshd را فراهم می‌سازد.

-d

حالت اشکال‌زدایی (Debug). کارساز خروجی پرجزئیات اشکال‌زدایی را به خطای استاندارد ارسال می‌کند و خود را در پس‌زمینه قرار نمی‌دهد. همچنین کارساز منشعب نخواهد شد (fork(2)) و تنها یک اتصال را پردازش می‌کند. این گزینه فقط برای اشکال‌زدایی کارساز در نظر گرفته شده است. استفاده چندباره از گزینه -d سطح اشکال‌زدایی را افزایش می‌دهد. حداکثر مقدار 3 است.

-E log_file

افزودن لاگ‌های اشکال‌زدایی به log_file به جای لاگ سیستم.

-e

نوشتن لاگ‌های اشکال‌زدایی در خطای استاندارد به جای لاگ سیستم.

-f config_file

نام فایل پیکربندی را مشخص می‌کند. پیش‌فرض /etc/ssh/sshd_config است. در صورت نبود فایل پیکربندی، sshd از اجرا خودداری می‌کند.

-G

تجزیه و چاپ فایل پیکربندی. اعتبار فایل پیکربندی را بررسی می‌کند، پیکربندی مؤثر را در خروجی استاندارد چاپ کرده و سپس خارج می‌شود. در صورت تمایل، قواعد Match را می‌توان با تعیین پارامترهای اتصال با استفاده از یک یا چند گزینه -C اعمال کرد.

-g login_grace_time

مهلت زمانی (grace time) برای احراز هویت کلاینت‌ها را تعیین می‌کند (پیش‌فرض 120 ثانیه). اگر کلاینت نتواند ظرف این مدت زمان کاربر را احراز هویت کند، کارساز ارتباط را قطع کرده و خارج می‌شود. مقدار صفر به معنی نبود محدودیت زمانی است.

-h host_key_file

فایلی را مشخص می‌کند که کلید میزبان از آن خوانده می‌شود. اگر sshd با کاربر ریشه (root) اجرا نشود، این گزینه باید مشخص گردد (زیرا فایل‌های معمول کلید میزبان معمولاً فقط برای کاربر ریشه قابل خواندن هستند). پیش‌فرض عبارت است از /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key, /etc/ssh/ssh_host_mldsa44_ed25519_key و /etc/ssh/ssh_host_rsa_key. داشتن چند فایل کلید میزبان برای الگوریتم‌های مختلف کلید میزبان امکان‌پذیر است.

-i

مشخص می‌کند که sshd از طریق inetd(8) در حال اجرا است.

-o option

می‌تواند برای ارائه گزینه‌ها در قالبی که در فایل پیکربندی استفاده می‌شود به کار رود. این قابلیت برای مشخص کردن گزینه‌هایی که سوییچ خط فرمان جداگانه‌ای ندارند مفید است. برای جزئیات کامل گزینه‌ها و مقادیر آن‌ها، به sshd_config(5) مراجعه کنید.

-p port

پورتی را که کارساز برای دریافت اتصالات به آن گوش می‌دهد مشخص می‌کند (پیش‌فرض 22). تعیین چندین گزینه پورت مجاز است. پورت‌های مشخص‌شده در فایل پیکربندی با گزینه Port در صورت تعیین پورت در خط فرمان نادیده گرفته می‌شوند. پورت‌های مشخص‌شده با گزینه ListenAddress بر پورت‌های خط فرمان تقدم دارند.

-q

حالت ساکت (Quiet). هیچ پیامی به لاگ سیستم ارسال نمی‌شود. به‌طور معمول آغاز، احراز هویت و پایان هر اتصال لاگ می‌شود.

-T

حالت آزمایشی گسترش‌یافته (Extended test mode). اعتبار فایل پیکربندی را بررسی می‌کند، پیکربندی مؤثر را در خروجی استاندارد چاپ کرده و سپس خارج می‌شود. در صورت تمایل، قواعد Match را می‌توان با تعیین پارامترهای اتصال با یک یا چند گزینه -C اعمال کرد. این ویژگی مشابه گزینه -G است، با این تفاوت که آزمون‌های اضافی انجام‌شده توسط پرچم -t را نیز شامل می‌شود.

-t

حالت آزمایشی (Test mode). تنها اعتبار فایل پیکربندی و سلامت کلیدها را بررسی می‌کند. این گزینه برای به‌روزرسانی مطمئن sshd مفید است، زیرا ممکن است گزینه‌های پیکربندی تغییر کنند.

-u len

این گزینه برای تعیین اندازه فیلدی در ساختار utmp به کار می‌رود که نام میزبان دوردست را نگهداری می‌کند. اگر نام میزبان به دست آمده طولانی‌تر از len باشد، مقدار ده‌دهی نقطه‌دار (dotted decimal) به جای آن استفاده خواهد شد. این قابلیت اجازه می‌دهد میزبان‌هایی با نام‌های بسیار طولانی که از اندازه این فیلد سرریز می‌کنند، همچنان به‌طور یکتا شناسایی شوند. مشخص کردن -u0 نشان می‌دهد که تنها نشانی‌های ده‌دهی نقطه‌دار باید در فایل utmp قرار گیرند. همچنین می‌توان از -u0 برای جلوگیری از ارسال درخواست‌های DNS توسط sshd استفاده کرد، مگر اینکه سازوکار احراز هویت یا پیکربندی به آن نیاز داشته باشد. سازوکارهای احراز هویتی که ممکن است به DNS نیاز داشته باشند شامل HostbasedAuthentication و استفاده از گزینه from="pattern-list" در یک فایل کلید است. گزینه‌های پیکربندی که به DNS نیاز دارند شامل استفاده از الگوی USER@HOST در AllowUsers یا DenyUsers می‌باشد.

-V

نمایش شماره نسخه و خروج.

احراز هویت (AUTHENTICATION)

دیمن کارساز OpenSSH تنها از پروتکل SSH نسخه ۲ پشتیبانی می‌کند. هر میزبان دارای یک کلید اختصاصی است که برای شناسایی آن میزبان استفاده می‌شود. هرگاه کلاینتی متصل شود، دیمن با کلید عمومی میزبان خود پاسخ می‌دهد. کلاینت کلید میزبان را با پایگاه داده خود مقایسه می‌کند تا تأیید کند که تغییر نکرده است. رازداری پیشرو (Forward secrecy) از طریق توافق کلید دیفی-هلمن (Diffie-Hellman) تأمین می‌شود. این توافق کلید منجر به یک کلید نشست اشتراکی می‌گردد. بقیه نشست با استفاده از یک رمز متقارن رمزنگاری می‌شود. کلاینت الگوریتم رمزنگاری مورد استفاده را از میان الگوریتم‌های ارائه‌شده توسط کارساز انتخاب می‌کند. علاوه بر این، یکپارچگی نشست از طریق یک کد اصالت‌سنجی پیام رمزنگاری‌شده (MAC) تأمین می‌شود.

در نهایت، کارساز و کلاینت وارد یک گفتگوی احراز هویت می‌شوند. کلاینت تلاش می‌کند با استفاده از احراز هویت مبتنی بر میزبان (host-based)، احراز هویت با کلید عمومی (public key)، احراز هویت چالش-پاسخ (challenge-response) یا احراز هویت با گذرواژه، هویت خود را اثبات کند.

صرف‌نظر از نوع احراز هویت، حساب کاربری بررسی می‌شود تا اطمینان حاصل شود که قابل دسترسی است. یک حساب کاربری در صورتی که قفل شده باشد، در DenyUsers فهرست شده باشد، یا گروه آن در DenyGroups آمده باشد، قابل دسترسی نیست. تعریف یک حساب قفل‌شده به سیستم وابسته است. برخی پلتفرم‌ها پایگاه داده حساب کاربری مختص به خود را دارند (مانند AIX) و برخی فیلد passwd را تغییر می‌دهند (مانند ‘*LK*’ در Solaris و UnixWare، ‘*’ در HP-UX، حاوی ‘Nologin’ در Tru64، یک ‘*LOCKED*’ در ابتدا در FreeBSD و یک ‘!’ در ابتدای فیلد در بیشتر توزیع‌های لینوکس). اگر لازم باشد احراز هویت گذرواژه‌ای برای یک حساب غیرفعال شود در حالی که احراز هویت کلید عمومی همچنان مجاز باشد، فیلد passwd باید روی مقداری به جز این مقادیر تنظیم شود (مانند ‘NP’ یا ‘*NP*’ ).

اگر کلاینت با موفقیت احراز هویت شود، گفتگویی برای آماده‌سازی نشست آغاز می‌گردد. در این زمان کلاینت ممکن است مواردی مانند تخصیص شبه‌ترمینال (pseudo-tty)، هدایت اتصالات X11، هدایت اتصالات TCP یا هدایت اتصال کارگزار احراز هویت (agent) را از طریق کانال امن درخواست کند.

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

هنگامی که برنامه کاربر خاتمه یابد و تمام اتصالات هدایت‌شده X11 و سایر اتصالات بسته شوند، کارساز وضعیت خروج دستور را به کلاینت ارسال می‌کند و هر دو طرف خارج می‌شوند.

فرآیند ورود (LOGIN PROCESS)

هنگامی که کاربری با موفقیت وارد سیستم می‌شود، sshd کارهای زیر را انجام می‌دهد:

1. اگر ورود روی یک tty باشد و هیچ دستوری مشخص نشده باشد، زمان آخرین ورود و محتوای /etc/motd را چاپ می‌کند (مگر اینکه در فایل پیکربندی یا توسط ~/.hushlogin از آن جلوگیری شده باشد؛ بخش فایل‌ها (FILES) را ببینید).
2. اگر ورود روی یک tty باشد، زمان ورود را ثبت می‌کند.
3. فایل /etc/nologin را بررسی می‌کند؛ در صورت وجود، محتوای آن را چاپ کرده و خارج می‌شود (مگر برای کاربر ریشه).
4. سطح دسترسی خود را تغییر می‌دهد تا با امتیازات کاربر عادی اجرا شود.
5. محیط پایه (environment) را برپا می‌سازد.
6. فایل ~/.ssh/environment را در صورت وجود و مجاز بودن کاربران به تغییر محیط خود، می‌خواند. گزینه PermitUserEnvironment را در sshd_config(5) ببینید.
7. به دایرکتوری خانگی کاربر تغییر مسیر می‌دهد.
8. اگر ~/.ssh/rc وجود داشته باشد و گزینه PermitUserRC در sshd_config(5) تنظیم شده باشد، آن را اجرا می‌کند؛ در غیر این صورت اگر /etc/ssh/sshrc وجود داشته باشد، آن را اجرا می‌نماید؛ در غیر این صورت xauth(1) را اجرا می‌کند. به فایل‌های “rc” پروتکل احراز هویت X11 و کوکی در ورودی استاندارد داده می‌شود. بخش SSHRC را در ادامه ببینید.
9. پوسته یا دستور کاربر را اجرا می‌کند. تمامی دستورات تحت پوسته ورود کاربر طبق آنچه در پایگاه داده گذرواژه سیستم مشخص شده است اجرا می‌شوند.

SSHRC

اگر فایل ~/.ssh/rc وجود داشته باشد، sh(1) آن را پس از خواندن فایل‌های محیطی اما پیش از راه‌اندازی پوسته یا دستور کاربر اجرا می‌کند. این اسکریپت نباید هیچ خروجی در stdout تولید کند؛ به جای آن باید از stderr استفاده شود. اگر هدایت اتصالات X11 فعال باشد، این اسکریپت جفت "proto cookie" را در ورودی استاندارد خود دریافت خواهد کرد (و DISPLAY را در متغیرهای محیطی خود خواهد داشت). این اسکریپت باید xauth(1) را فراخوانی کند زیرا sshd به‌طور خودکار xauth را برای افزودن کوکی‌های X11 اجرا نخواهد کرد.

هدف اصلی این فایل اجرای هرگونه روال اولیه‌ای است که ممکن است پیش از در دسترس قرار گرفتن دایرکتوری خانگی کاربر مورد نیاز باشد؛ سیستم AFS نمونه بارزی از چنین محیطی است.

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

if read proto cookie && [ -n "$DISPLAY" ]; then
	if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
		# X11UseLocalhost=yes
		echo add unix:`echo $DISPLAY |
		    cut -c11-` $proto $cookie
	else
		# X11UseLocalhost=no
		echo add $DISPLAY $proto $cookie
	fi | xauth -q -
fi

اگر این فایل وجود نداشته باشد، /etc/ssh/sshrc اجرا می‌شود، و در صورتی که آن هم وجود نداشته باشد، از xauth برای افزودن کوکی استفاده خواهد شد.

قالب فایل AUTHORIZED_KEYS (AUTHORIZED_KEYS FILE FORMAT)

دستورالعمل AuthorizedKeysFile فایل‌های حاوی کلیدهای عمومی برای احراز هویت با کلید عمومی را مشخص می‌کند؛ اگر این گزینه مشخص نشود، پیش‌فرض ~/.ssh/authorized_keys و ~/.ssh/authorized_keys2 است. هر خط از فایل حاوی یک کلید است (خطوط خالی و خطوطی که با ‘#’ آغاز می‌شوند به عنوان یادداشت نادیده گرفته می‌شوند). کلیدهای عمومی از فیلدهای زیر تشکیل شده‌اند که با فاصله از هم جدا می‌شوند: گزینه‌ها (options)، نوع کلید (keytype)، کلید کدگذاری‌شده با base64، و توضیح (comment). فیلد گزینه‌ها اختیاری است. انواع کلیدهای پشتیبانی‌شده عبارتند از:

• sk-ecdsa-sha2-nistp256@openssh.com
• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521
• sk-ssh-ed25519@openssh.com
• ssh-ed25519
• ssh-mldsa44-ed25519@openssh.com
• ssh-rsa

فیلد توضیح (comment) برای کاربرد خاصی استفاده نمی‌شود (اما ممکن است برای شناسایی کلید توسط کاربر مفید باشد).

توجه داشته باشید که خطوط این فایل ممکن است چند صد بایت طول داشته باشند (به دلیل اندازه کلید کدگذاری‌شده) تا سقف ۸ کیلوبایت، که اجازه استفاده از کلیدهای RSA تا ۱۶ کیلوبیت را می‌دهد. بهتر است آن‌ها را دستی تایپ نکنید؛ به جای آن، فایل‌های id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub, id_ed25519_sk.pub, id_mldsa44_ed25519 یا id_rsa.pub را کپی کرده و ویرایش نمایید.

sshd حداقل اندازه مدول کلید RSA را ۱۰۲۴ بیت تعیین می‌کند.

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

agent-forwarding

هدایت کارگزار احراز هویت را که قبلاً توسط گزینه restrict غیرفعال شده بود، فعال می‌کند.

cert-authority

مشخص می‌کند که کلید فهرست‌شده یک مرجع صدور گواهی (CA) است که برای اعتبارسنجی گواهی‌های امضاشده جهت احراز هویت کاربر معتبر شناخته می‌شود.

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

command="command"

مشخص می‌کند که هرگاه از این کلید برای احراز هویت استفاده شود، این دستور اجرا گردد. دستور ارائه‌شده توسط کاربر (در صورت وجود) نادیده گرفته می‌شود. اگر کلاینت درخواست pty کند، دستور روی یک pty اجرا می‌شود؛ در غیر این صورت بدون tty اجرا خواهد شد. اگر یک کانال ۸ بیتی بدون تغییر (8-bit clean) مورد نیاز باشد، نباید درخواست pty شود یا باید no-pty مشخص گردد. می‌توان با علامت بک‌اسلش یک گیومه را در دستور قرار داد.

این گزینه می‌تواند برای محدود کردن برخی کلیدهای عمومی به انجام یک عملیات خاص مفید باشد. به عنوان مثال، کلیدی که تنها اجازه پشتیبان‌گیری از راه دور را می‌دهد و نه هیچ کار دیگری. توجه داشته باشید که کلاینت ممکن است هدایت TCP و/یا X11 را درخواست کند، مگر اینکه صراحتاً منع شده باشند، مثلاً با استفاده از گزینه کلید restrict.

دستوری که در ابتدا توسط کلاینت ارائه شده بود در متغیر محیطی SSH_ORIGINAL_COMMAND در دسترس است. توجه داشته باشید که این گزینه برای اجرای پوسته، دستور یا زیرسیستم اعمال می‌شود. همچنین توجه داشته باشید که این دستور ممکن است توسط دستورالعمل ForceCommand در sshd_config(5) جایگزین گردد.

اگر دستوری مشخص شده باشد و یک دستور اجباری (forced-command) درون گواهی مورد استفاده برای احراز هویت نیز گنجانده شده باشد، گواهی تنها در صورتی پذیرفته می‌شود که هر دو دستور کاملاً یکسان باشند.

environment="NAME=value"

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

expiry-time="timespec"

زمانی را مشخص می‌کند که پس از آن، کلید دیگر پذیرفته نخواهد شد. زمان را می‌توان به صورت تاریخ YYYYMMDD[Z] یا زمان YYYYMMDDHHMM[SS][Z] مشخص کرد. تاریخ‌ها و زمان‌ها در منطقه زمانی سیستم تفسیر می‌شوند، مگر اینکه با حرف Z پایان یابند که در این صورت در منطقه زمانی UTC تفسیر خواهند شد.

from="pattern-list"

مشخص می‌کند که علاوه بر احراز هویت با کلید عمومی، نام رسمی میزبان دوردست یا نشانی IP آن نیز باید در فهرست الگوهای جداشده با کاما وجود داشته باشد. برای اطلاعات بیشتر درباره الگوها به بخش PATTERNS در ssh_config(5) مراجعه کنید.

علاوه بر تطبیق نویسه‌های عام که می‌تواند روی نام‌های میزبان یا نشانی‌ها اعمال شود، یک بند from می‌تواند نشانی‌های IP را با استفاده از نشانه‌گذاری CIDR (نشانی/طول ماسک) تطبیق دهد.

هدف این گزینه افزایش اختیاری امنیت است: احراز هویت با کلید عمومی به خودی خود به شبکه یا کارسازهای نام یا هیچ چیز دیگری (به جز خود کلید) اعتماد نمی‌کند؛ اما اگر کسی به نحوی کلید را برباید، آن کلید به نفوذگر اجازه می‌دهد از هر نقطه دنیا وارد شود. این گزینه اضافی استفاده از کلید سرقت‌شده را دشوارتر می‌سازد (علاوه بر کلید، کارسازهای نام و/یا مسیریاب‌ها نیز باید به خطر بیفتند).

no-agent-forwarding

هدایت کارگزار احراز هویت را در هنگام استفاده از این کلید برای احراز هویت ممنوع می‌کند.

no-port-forwarding

هدایت اتصالات TCP را در هنگام استفاده از این کلید برای احراز هویت ممنوع می‌سازد. هرگونه درخواست فوروارد پورت توسط کلاینت با خطا مواجه خواهد شد. از این گزینه می‌توان به عنوان مثال همراه با گزینه command استفاده کرد.

no-pty

از تخصیص tty جلوگیری می‌کند (درخواست برای تخصیص pty رد خواهد شد).

no-user-rc

اجرای ~/.ssh/rc را غیرفعال می‌کند.

no-X11-forwarding

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

permitlisten="[host:]port"

هدایت پورت از راه دور را با گزینه -R دستور ssh(1) محدود می‌کند به گونه‌ای که تنها بتواند روی میزبان مشخص‌شده (اختیاری) و پورت معین گوش فرا دهد. نشانی‌های IPv6 را می‌توان با محصور کردن در براکت مشخص کرد. می‌توان چندین گزینه permitlisten را به‌صورت جداشده با کاما اعمال کرد. نام‌های میزبان می‌توانند شامل نویسه‌های عام باشند، همان‌گونه که در بخش PATTERNS در ssh_config(5) آمده است. مشخص کردن پورت به صورت * با هر پورتی تطابق دارد. توجه داشته باشید که تنظیمات GatewayPorts ممکن است نشانی‌های شنود را بیشتر محدود کند. توجه داشته باشید که ssh(1) در صورتی که میزبان شنود هنگام درخواست هدایت مشخص نشده باشد، نام میزبان “localhost” را ارسال می‌کند، و با این نام متفاوت از نشانی‌های صریح لوکال‌هاست “127.0.0.1” و “::1” برخورد می‌شود.

permitopen="host:port"

هدایت پورت محلی را با گزینه -L دستور ssh(1) محدود می‌کند تا تنها بتواند به میزبان و پورت مشخص‌شده متصل شود. نشانی‌های IPv6 را می‌توان با قرار دادن در براکت مشخص کرد. می‌توان چندین گزینه permitopen را به‌صورت جداشده با کاما اعمال کرد. هیچ تطبیق الگویی یا جستجوی نامی روی نام‌های میزبان مشخص‌شده انجام نمی‌شود؛ آن‌ها باید نام‌های میزبان و/یا نشانی‌های واقعی باشند. مشخص کردن پورت به صورت * با هر پورتی تطابق دارد.

port-forwarding

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

principals="principals"

روی یک خط cert-authority ، هویت‌های مجاز (principals) برای احراز هویت با گواهی را به صورت فهرستی جداشده با کاما مشخص می‌کند. حداقل یکی از نام‌های این فهرست باید در فهرست هویت‌های گواهی وجود داشته باشد تا گواهی پذیرفته شود. این گزینه برای کلیدهایی که با گزینه cert-authority به عنوان امضاکنندگان گواهی معتبر علامت‌گذاری نشده‌اند، نادیده گرفته می‌شود.

pty

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

no-touch-required

نیاز به اثبات حضور کاربر (لمس فیزیکی) را برای امضاهای ایجادشده با این کلید الزامی نمی‌داند. این گزینه تنها برای الگوریتم‌های احرازکننده FIDO شامل ecdsa-sk و ed25519-sk معنا دارد.

verify-required

الزام می‌کند که امضاهای ایجادشده با استفاده از این کلید تصدیق کنند که کاربر تأیید هویت شده است، مثلاً از طریق PIN. این گزینه تنها برای الگوریتم‌های احرازکننده FIDO شامل ecdsa-sk و ed25519-sk معنا دارد.

restrict

تمام محدودیت‌ها را فعال می‌کند، یعنی هدایت پورت، کارگزار و X11 را غیرفعال می‌سازد و همچنین تخصیص PTY و اجرای ~/.ssh/rc را ممنوع می‌کند. اگر در آینده قابلیت محدودیت دیگری به فایل‌های authorized_keys اضافه شود، در این مجموعه گنجانده خواهد شد.

tunnel="n"

استفاده از یک دستگاه tun(4) را روی کارساز اجبار می‌کند. بدون این گزینه، در صورتی که کلاینت درخواست تونل کند، دستگاه بعدی در دسترس استفاده خواهد شد.

user-rc

اجرای ~/.ssh/rc را که قبلاً توسط گزینه restrict غیرفعال شده بود، مجاز می‌سازد.

X11-forwarding

هدایت X11 را که قبلاً توسط گزینه restrict غیرفعال شده بود، مجاز می‌سازد.

نمونه‌ای از یک فایل authorized_keys:

# Comments are allowed at start of line. Blank lines are allowed.
# Plain key, no restrictions
ssh-rsa ...
# Forced command, disable PTY and all forwarding
restrict,command="dump /home" ssh-rsa ...
# Restriction of ssh -L forwarding destinations
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ...
# Restriction of ssh -R forwarding listeners
permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa ...
# Configuration for tunnel forwarding
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ...
# Override of restriction to allow PTY allocation
restrict,pty,command="nethack" ssh-rsa ...
# Allow FIDO key without requiring touch
no-touch-required sk-ecdsa-sha2-nistp256@openssh.com ...
# Require user-verification (e.g. PIN or biometric) for FIDO key
verify-required sk-ecdsa-sha2-nistp256@openssh.com ...
# Trust CA key, allow touch-less FIDO if requested in certificate
cert-authority,no-touch-required,principals="user_a" ssh-rsa ...

قالب فایل SSH_KNOWN_HOSTS (SSH_KNOWN_HOSTS FILE FORMAT)

فایل‌های /etc/ssh/ssh_known_hosts و ~/.ssh/known_hosts شامل کلیدهای عمومی میزبان برای تمام میزبان‌های شناخته‌شده هستند. فایل سراسری باید توسط مدیر سیستم تهیه شود (اختیاری است)، و فایل مختص هر کاربر به‌طور خودکار نگهداری می‌شود: هرگاه کاربر به میزبانی ناشناخته متصل شود، کلید آن به فایل کاربر افزوده می‌گردد.

هر خط در این فایل‌ها شامل فیلدهای زیر است: نشانگر (اختیاری)، نام‌های میزبان (hostnames)، نوع کلید (keytype)، کلید کدگذاری‌شده با base64، و توضیح (comment). این فیلدها با فاصله از یکدیگر جدا می‌شوند.

نشانگر (marker) اختیاری است، اما در صورت وجود باید یکی از مقادیر “@cert-authority” برای نشان دادن اینکه خط حاوی یک کلید مرجع صدور گواهی (CA) است، یا “@revoked” برای نشان دادن اینکه کلید موجود در خط باطل شده و هرگز نباید پذیرفته شود، باشد. تنها یک نشانگر باید در یک خط کلید استفاده شود.

نام‌های میزبان (hostnames) فهرستی از الگوهای جداشده با کاما است (‘*’ و ‘?’ به عنوان نویسه‌های عام عمل می‌کنند)؛ هر الگو به نوبه خود با نام میزبان تطبیق داده می‌شود. هنگامی که sshd در حال احراز هویت یک کلاینت است، مانند هنگام استفاده از HostbasedAuthentication ، این نام همان نام رسمی میزبان کلاینت خواهد بود. هنگامی که ssh(1) در حال احراز هویت یک کارساز است، این نام، نام میزبان ارائه‌شده توسط کاربر، مقدار گزینه HostkeyAlias در ssh(1) (در صورت تعیین)، یا نام رسمی میزبان کارساز در صورت استفاده از گزینه CanonicalizeHostname در ssh(1) خواهد بود.

یک الگو همچنین می‌تواند با یک علامت ‘!’ آغاز شود تا نشان‌دهنده نقیض (negation) باشد: اگر نام میزبان با یک الگوی نقیض مطابقت داشته باشد، (توسط آن خط) پذیرفته نخواهد شد، حتی اگر با الگوی دیگری در همان خط تطابق داشته باشد. یک نام میزبان یا نشانی می‌تواند به صورت اختیاری درون براکت‌های ‘[’ و ‘]’ قرار گیرد و به دنبال آن یک ‘:’ و شماره پورت غیر استاندارد بیاید.

به عنوان روشی جایگزین، نام‌های میزبان را می‌توان به صورت درهم‌سازی‌شده (هش‌شده) ذخیره کرد تا در صورت افشای محتوای فایل، نام‌ها و نشانی‌های میزبان پنهان بمانند. نام‌های میزبان درهم‌سازی‌شده با نویسه ‘|’ آغاز می‌شوند. تنها یک نام میزبان درهم‌سازی‌شده می‌تواند در یک خط قرار گیرد و هیچ‌یک از عملگرهای نقیض یا نویسه‌های عام بالا برای آن قابل اعمال نیستند.

نوع کلید و کلید کدگذاری‌شده با base64 مستقیماً از کلید میزبان گرفته می‌شوند؛ می‌توان آن‌ها را برای مثال از /etc/ssh/ssh_host_rsa_key.pub به دست آورد. فیلد اختیاری توضیح تا انتهای خط ادامه دارد و پردازش نمی‌شود.

خطوطی که با ‘#’ آغاز می‌شوند و خطوط خالی به عنوان یادداشت نادیده گرفته می‌شوند.

هنگام انجام احراز هویت میزبان، در صورتی که هر خط مطابقی کلید مناسب را داشته باشد، احراز هویت پذیرفته می‌شود؛ چه کلیدی که تطابق دقیق دارد و چه در حالتی که کارساز گواهی برای احراز هویت ارائه داده باشد، کلید مرجع صدور گواهی که آن گواهی را امضا کرده است. برای اینکه یک کلید به عنوان مرجع صدور گواهی مورد اعتماد قرار گیرد، باید از نشانگر “@cert-authority” که در بالا شرح داده شد استفاده کند.

فایل میزبان‌های شناخته‌شده همچنین امکانی را برای علامت‌گذاری کلیدها به عنوان باطل‌شده (revoked) فراهم می‌کند، برای مثال زمانی که مشخص شود کلید خصوصی مرتبط با آن به سرقت رفته است. کلیدهای باطل‌شده با درج نشانگر “@revoked” در ابتدای خط کلید مشخص می‌شوند، و هرگز برای احراز هویت یا به عنوان مراجع صدور گواهی پذیرفته نمی‌شوند، بلکه هنگام مواجهه با آن‌ها، هشداری توسط ssh(1) تولید می‌شود.

داشتن چندین خط یا کلیدهای میزبان مختلف برای نام‌های یکسان مجاز (اما غیرتوصیه‌شده) است. این وضعیت ناگزیر زمانی رخ می‌دهد که اشکال کوتاه نام‌های میزبان از دامنه‌های مختلف در فایل قرار گیرند. این احتمال وجود دارد که فایل‌ها شامل اطلاعات متناقض باشند؛ در صورتی که اطلاعات معتبر از هر یک از فایل‌ها یافت شود، احراز هویت پذیرفته خواهد شد.

توجه داشته باشید که خطوط این فایل‌ها معمولاً صدها نویسه طول دارند و قطعاً نباید کلیدهای میزبان را با دست تایپ کنید. بلکه آن‌ها را با یک اسکریپت، ssh-keyscan(1) یا با برداشتن فایل‌هایی مانند /etc/ssh/ssh_host_rsa_key.pub و افزودن نام‌های میزبان در ابتدای آن ایجاد کنید. دستور ssh-keygen(1) همچنین امکانات ویرایش خودکار اولیه‌ای را برای ~/.ssh/known_hosts فراهم می‌کند، از جمله حذف میزبان‌های منطبق با یک نام میزبان و تبدیل تمامی نام‌های میزبان به نمایش درهم‌سازی‌شده (هش‌شده) آن‌ها.

نمونه‌ای از یک فایل ssh_known_hosts:

# Comments allowed at start of line
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
# A hashed hostname
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234.....=
# A revoked key
@revoked * ssh-rsa AAAAB5W...
# A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...

فایل‌ها (FILES)

~/.hushlogin

این فایل برای جلوگیری از چاپ زمان آخرین ورود و محتوای /etc/motd به کار می‌رود، در صورتی که به ترتیب گزینه‌های PrintLastLog و PrintMotd فعال باشند. این فایل مانع از چاپ اعلان مشخص‌شده توسط Banner نمی‌شود.

~/.rhosts

این فایل برای احراز هویت مبتنی بر میزبان به کار می‌رود (برای اطلاعات بیشتر به ssh(1) مراجعه کنید). در برخی سیستم‌ها اگر دایرکتوری خانگی کاربر روی یک پارتیشن NFS قرار داشته باشد، ممکن است این فایل نیاز به دسترسی خواندن همگانی (world-readable) داشته باشد، زیرا sshd آن را با کاربر ریشه می‌خواند. علاوه بر این، این فایل باید در مالکیت کاربر باشد و مجوز نوشتن برای هیچ‌کس دیگری نداشته باشد. مجوز توصیه‌شده برای بیشتر سیستم‌ها، خواندن/نوشتن برای کاربر و غیرقابل‌دسترسی برای دیگران است.

~/.shosts

این فایل دقیقاً به همان روش .rhosts به کار می‌رود، اما امکان احراز هویت مبتنی بر میزبان را بدون اجازه ورود با rlogin/rsh فراهم می‌سازد.

~/.ssh/

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

~/.ssh/authorized_keys

کلیدهای عمومی را فهرست می‌کند (ECDSA, Ed25519, RSA) که می‌توان از آن‌ها برای ورود به عنوان این کاربر استفاده کرد. قالب این فایل در بالا شرح داده شد. محتوای این فایل حساسیت بالایی ندارد، اما مجوزهای توصیه‌شده خواندن/نوشتن برای کاربر و عدم دسترسی دیگران است.

اگر این فایل، دایرکتوری ~/.ssh یا دایرکتوری خانگی کاربر برای سایر کاربران قابل نوشتن باشند، آن‌گاه فایل می‌تواند توسط کاربران غیرمجاز تغییر یافته یا جایگزین شود. در این حالت، sshd اجازه استفاده از آن را نخواهد داد مگر اینکه گزینه StrictModes روی “no” تنظیم شده باشد.

~/.ssh/environment

این فایل در هنگام ورود به سیستم در محیط کاربر خوانده می‌شود (در صورت وجود). این فایل تنها می‌تواند شامل خطوط خالی، خطوط یادداشت (که با ‘#’ آغاز می‌شوند)، و خطوط انتساب به شکل name=value باشد. این فایل باید تنها توسط کاربر قابل نوشتن باشد؛ نیازی به قابل خواندن بودن برای دیگران ندارد. پردازش متغیرهای محیطی به‌طور پیش‌فرض غیرفعال است و از طریق گزینه PermitUserEnvironment کنترل می‌شود.

~/.ssh/known_hosts

شامل فهرستی از کلیدهای میزبان برای تمام میزبان‌هایی است که کاربر به آن‌ها وارد شده و در فهرست سراسری کلیدهای شناخته‌شده وجود ندارند. قالب این فایل در بالا شرح داده شد. این فایل باید تنها توسط ریشه یا مالک قابل نوشتن باشد و می‌تواند (اما لازم نیست) برای همگان قابل خواندن باشد.

~/.ssh/rc

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

/etc/hosts.equiv

این فایل برای احراز هویت مبتنی بر میزبان است (به ssh(1) مراجعه کنید). این فایل تنها باید توسط ریشه قابل نوشتن باشد.

/etc/ssh/moduli

شامل گروه‌های دیفی-هلمن مورد استفاده برای روش تبادل کلید "Diffie-Hellman Group Exchange" است. قالب این فایل در moduli(5) شرح داده شده است. اگر هیچ گروه قابل استفاده‌ای در این فایل یافت نشود، از گروه‌های ثابت داخلی استفاده خواهد شد.

/etc/motd

به motd(5) مراجعه کنید.

/etc/nologin

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

/etc/ssh/shosts.equiv

این فایل دقیقاً به همان روش hosts.equiv استفاده می‌شود، اما امکان احراز هویت مبتنی بر میزبان را بدون اجازه ورود با rlogin/rsh فراهم می‌سازد.

/etc/ssh/ssh_host_ecdsa_key

 

/etc/ssh/ssh_host_ed25519_key

 

/etc/ssh/ssh_host_mldsa44_ed25519_key

 

/etc/ssh/ssh_host_rsa_key

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

/etc/ssh/ssh_host_ecdsa_key.pub

 

/etc/ssh/ssh_host_ed25519_key.pub

 

/etc/ssh/ssh_host_mldsa44_ed25519_key.pub

 

/etc/ssh/ssh_host_rsa_key.pub

این فایل‌ها شامل بخش‌های عمومی کلیدهای میزبان هستند. این فایل‌ها باید برای همگان قابل خواندن باشند اما تنها توسط کاربر ریشه قابل نوشتن باشند. محتوای آن‌ها باید با بخش‌های خصوصی مربوطه مطابقت داشته باشد. این فایل‌ها عملاً برای کارکرد مستقیم استفاده نمی‌شوند؛ آن‌ها صرفاً برای راحتی کاربر ارائه شده‌اند تا محتوایشان در فایل‌های میزبان‌های شناخته‌شده کپی شود. این فایل‌ها با استفاده از ssh-keygen(1) ایجاد می‌شوند.

/etc/ssh/ssh_known_hosts

فهرست سراسری سیستم از کلیدهای شناخته‌شده میزبان. این فایل باید توسط مدیر سیستم تهیه شود تا شامل کلیدهای عمومی میزبان تمام دستگاه‌های سازمان باشد. قالب این فایل در بالا شرح داده شد. این فایل باید تنها توسط ریشه یا مالک قابل نوشتن باشد و باید برای همگان قابل خواندن باشد.

/etc/ssh/sshd_config

شامل داده‌های پیکربندی برای sshd است. قالب فایل و گزینه‌های پیکربندی در sshd_config(5) توضیح داده شده‌اند.

/etc/ssh/sshrc

مشابه ~/.ssh/rc ، می‌توان از آن برای تعیین روال‌های اولیه‌سازی زمان ورود به صورت سراسری برای یک دستگاه خاص استفاده کرد. این فایل تنها باید توسط کاربر ریشه قابل نوشتن باشد و باید برای همگان قابل خواندن باشد.

/usr/share/empty.sshd

دایرکتوری chroot(2) مورد استفاده توسط sshd در طول جداسازی امتیازات (privilege separation) در مرحله پیش از احراز هویت. این دایرکتوری نباید شامل هیچ فایلی باشد، مالکیت آن باید متعلق به ریشه باشد و نباید برای گروه یا همگان قابل نوشتن باشد.

/run/sshd.pid

شامل شناسه فرآیند (PID) مربوط به sshd گوش‌فرادهنده به اتصالات است (اگر چندین دیمن به‌طور همزمان برای پورت‌های مختلف در حال اجرا باشند، این فایل حاوی شناسه فرآیند آخرین دیمن راه‌اندازی‌شده خواهد بود). محتوای این فایل حساس نیست؛ می‌تواند برای همگان قابل خواندن باشد.

همچنین ببینید (SEE ALSO)

scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), chroot(2), login.conf(5), moduli(5), sshd_config(5), inetd(8), sftp-server(8)

نویسندگان (AUTHORS)

پروژه OpenSSH مشتق‌شده از نسخه اولیه و آزاد ssh 1.2.12 توسط Tatu Ylonen است. افراد Aaron Campbell، Bob Beck، Markus Friedl، Niels Provos، Theo de Raadt و Dug Song باگ‌های فراوانی را برطرف نموده، امکانات جدیدتر را افزودند و OpenSSH را خلق کردند. Markus Friedl در پشتیبانی از پروتکل SSH نسخه‌های 1.5 و 2.0 مشارکت نمود. Niels Provos و Markus Friedl پشتیبانی از جداسازی امتیازات (privilege separation) را پیاده‌سازی کردند.