SSH(1) General Commands Manual SSH(1)

ssh — کلاینت ارتباط امن OpenSSH (برنامه ورود از راه دور)

ssh [-46AaCfGgKkMNnqsTtVvXxYyZ] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]] ssh [-Q query_option]

ssh (کلاینت SSH) برنامه‌ای برای ورود به یک ماشین راه دور و اجرای دستورات روی آن ماشین است. هدف این ابزار برقراری ارتباطات رمزگذاری‌شده و امن میان دو میزبان غیرقابل اعتماد بر روی یک شبکه ناامن است. اتصالات X11، درگاه‌های دلخواه TCP و سوکت‌های دامنه UNIX (UNIX-domain) نیز می‌توانند از طریق این کانال امن بازفرستاده شوند.

ssh به destination (مقصد) مشخص‌شده متصل شده و به آن وارد می‌شود، که مقصد می‌تواند به صورت [user@]hostname یا یک نشانی وب (URI) به شکل ssh://[user@]hostname[:port]. مشخص گردد. کاربر باید با استفاده از یکی از چندین روش موجود، هویت خود را به ماشین راه دور اثبات کند (به بخش زیر مراجعه کنید).

اگر یک command (دستور) مشخص شده باشد، به جای پوسته ورود (login shell) بر روی میزبان راه دور اجرا خواهد شد. یک خط فرمان کامل می‌تواند به عنوان command تعیین شود، یا ممکن است دارای آرگومان‌های اضافی باشد. در صورت ارائه، آرگومان‌ها پیش از ارسال به سرور جهت اجرا، با فاصله به انتهای دستور متصل می‌شوند.

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

اجبار ssh به استفاده انحصاری از نشانی‌های IPv4.
اجبار ssh به استفاده انحصاری از نشانی‌های IPv6.
فعال‌سازی بازفرستادن اتصالات از یک عامل احراز هویت مانند ssh-agent(1). این مورد را می‌توان بر اساس هر میزبان نیز در یک فایل پیکربندی مشخص کرد.

بازفرستادن عامل احراز هویت باید با احتیاط فعال شود. کاربرانی که توانایی دور زدن دسترسی‌های فایل را در میزبان راه دور دارند (برای سوکت دامنه UNIX عامل) می‌توانند از طریق اتصال بازفرستاده‌شده به عامل محلی دسترسی یابند. یک مهاجم نمی‌تواند اطلاعات کلید را از عامل به دست آورد، اما می‌تواند عملیاتی را بر روی کلیدها انجام دهد که امکان احراز هویت با استفاده از هویت‌های بارگذاری‌شده در عامل را برای او فراهم می‌کند. یک جایگزین امن‌تر می‌تواند استفاده از یک میزبان پرش (jump host) باشد (به گزینه -J مراجعه کنید).

غیرفعال‌سازی بازفرستادن اتصال عامل احراز هویت.
bind_interface
متصل شدن به نشانی bind_interface پیش از تلاش برای اتصال به میزبان مقصد. این گزینه تنها در سیستم‌هایی که دارای بیش از یک نشانی هستند کاربرد دارد.
bind_address
استفاده از bind_address در ماشین محلی به عنوان نشانی مبدا برای اتصال. تنها در سیستم‌هایی با بیش از یک نشانی کاربرد دارد.
درخواست فشرده‌سازی تمام داده‌ها (شامل ورودی استاندارد، خروجی استاندارد، خطای استاندارد، و داده‌های اتصالات بازفرستاده‌شدهٔ X11، TCP و دامنه UNIX). الگوریتم فشرده‌سازی همان مورد استفاده در gzip(1) است. فشرده‌سازی بر روی خطوط مودم و سایر اتصالات کند مطلوب است، اما در شبکه‌های پرسرعت تنها سرعت را کاهش می‌دهد. مقدار پیش‌فرض را می‌توان بر اساس هر میزبان در فایل‌های پیکربندی تعیین کرد؛ گزینه Compression را در ssh_config(5) ببینید.
cipher_spec
انتخاب مشخصه رمزگذاری جهت رمزگذاری نشست. cipher_spec فهرستی از رمزها است که با کاما از یکدیگر جدا شده و بر اساس اولویت مرتب شده‌اند. برای اطلاعات بیشتر کلیدواژه Ciphers را در ssh_config(5) ببینید.
[bind_address:]port
تعیین یک بازفرستادن پویای درگاه (“dynamic”) در سطح برنامه به صورت محلی. این قابلیت با تخصیص یک سوکت برای گوش دادن به port در سمت محلی، که به صورت اختیاری به bind_address مشخص‌شده متصل است، کار می‌کند. هر زمان اتصالی به این درگاه برقرار شود، اتصال بر روی کانال امن بازفرستاده می‌شود، و سپس پروتکل برنامه برای تعیین این که از ماشین راه دور به کجا متصل شود استفاده می‌گردد. در حال حاضر پروتکل‌های SOCKS4 و SOCKS5 پشتیبانی می‌شوند، و ssh به عنوان یک سرور SOCKS عمل خواهد کرد. تنها کاربر ریشه (root) می‌تواند درگاه‌های ممتاز را بازفرستد. بازفرستادن‌های پویای درگاه را می‌توان در فایل پیکربندی نیز مشخص کرد.

نشانی‌های IPv6 را می‌توان با قرار دادن نشانی در داخل براکت‌های چهارگوش مشخص کرد. تنها کاربر ارشد (superuser) می‌تواند درگاه‌های ممتاز را بازفرستد. به‌طور پیش‌فرض، درگاه محلی مطابق با تنظیم GatewayPorts متصل می‌شود. با این حال، می‌توان از یک bind_address صریح برای متصل کردن اتصال به یک نشانی خاص استفاده کرد. یک bind_address با مقدار “localhost” نشان می‌دهد که درگاه شنود تنها برای استفاده محلی متصل شود، در حالی که یک نشانی خالی یا ‘*’ نشان می‌دهد که درگاه باید از تمام رابط‌ها در دسترس باشد.

log_file
افزودن لاگ‌های اشکال‌زدایی به log_file به جای خطای استاندارد.
escape_char
تنظیم نویسه گریز برای نشست‌های دارای pty (پیش‌فرض: ‘~’ ). نویسه گریز تنها در ابتدای خط شناسایی می‌شود. نویسه گریز که به دنبال آن یک نقطه (‘.’) بیاید، اتصال را می‌بندد؛ به دنبال آن کنترل-Z اتصال را معلق می‌کند؛ و به دنبال آن خود نویسه، آن را یک بار ارسال می‌کند. تنظیم نویسه بر روی “none” تمام نویسه‌های گریز را غیرفعال کرده و نشست را کاملاً شفاف می‌سازد.
configfile
تعیین یک فایل پیکربندی جایگزین برای هر کاربر. اگر فایل پیکربندی در خط فرمان ارائه شود، فایل پیکربندی سراسری سیستم (/etc/ssh/ssh_config) نادیده گرفته خواهد شد. مقدار پیش‌فرض برای فایل پیکربندی کاربر ~/.ssh/config است. اگر بر روی “none” تنظیم شود، هیچ فایل پیکربندی خوانده نخواهد شد.
درخواست از ssh برای رفتن به پس‌زمینه دقیقاً پیش از اجرای دستور. این گزینه در صورتی مفید است که ssh بخواهد رمزهای عبور یا عبارت‌های عبور را درخواست کند، اما کاربر تمایل داشته باشد برنامه در پس‌زمینه قرار گیرد. این متضمن گزینه -n است. روش توصیه‌شده برای اجرای برنامه‌های X11 در یک سایت راه دور، فرمانی مانند ssh -f host xterm است.

اگر گزینه پیکربندی ExitOnForwardFailure روی “yes” تنظیم شده باشد، کلاینتی که با -f شروع به کار کرده پیش از قرار دادن خود در پس‌زمینه، منتظر می‌ماند تا تمام بازفرستادن‌های درگاه راه دور با موفقیت برقرار شوند. برای جزئیات بیشتر به توضیحات ForkAfterAuthentication در ssh_config(5) مراجعه کنید.

باعث می‌شود ssh پیکربندی خود را پس از ارزیابی بلوک‌های Host و Match چاپ کرده و خارج شود.
به میزبان‌های راه دور اجازه می‌دهد به درگاه‌های بازفرستاده‌شدهٔ محلی متصل شوند. اگر در یک اتصال چندگانه (تسهیم‌شده) استفاده شود، این گزینه باید روی فرایند اصلی (master) مشخص شود.
pkcs11
مشخص کردن کتابخانه مشترک PKCS#11 که ssh باید برای ارتباط با توکن PKCS#11 فراهم‌کننده کلیدها جهت احراز هویت کاربر استفاده کند.
identity_file
انتخاب فایلی که هویت (کلید خصوصی) برای احراز هویت با کلید عمومی از آن خوانده می‌شود. همچنین زمانی که فایل کلید خصوصی به صورت محلی وجود ندارد، می‌توانید یک فایل کلید عمومی مشخص کنید تا از کلید خصوصی مربوطه‌ای که در ssh-agent(1) بارگذاری شده است استفاده شود. پیش‌فرض شامل ~/.ssh/id_rsa ، ~/.ssh/id_ecdsa ، ~/.ssh/id_ecdsa_sk ، ~/.ssh/id_ed25519 ، ~/.ssh/id_ed25519_sk و ~/.ssh/id_mldsa44_ed25519 است. فایل‌های هویت را می‌توان بر اساس هر میزبان در فایل پیکربندی نیز مشخص کرد. امکان مشخص کردن چندین گزینه -i (و چندین هویت تعیین‌شده در فایل‌های پیکربندی) وجود دارد. اگر هیچ گواهی‌نامه‌ای به صراحت توسط دستورالعمل CertificateFile مشخص نشده باشد، ssh همچنین تلاش خواهد کرد اطلاعات گواهی‌نامه را از نام فایلی که با افزودن -cert.pub به نام‌های فایل‌های هویت به دست می‌آید بارگذاری کند.
destination
اتصال به میزبان هدف از طریق برقراری نخستین اتصال ssh به میزبان پرش (jump host) توصیف‌شده توسط destination و سپس برقراری بازفرستادن TCP به مقصد نهایی از آنجا. چندین پرش متوالی را می‌توان به صورت جداشده با کاما مشخص کرد. نشانی‌های IPv6 را می‌توان با قرار دادن در براکت‌های چهارگوش تعیین نمود. این یک میانبر برای تعیین دستورالعمل پیکربندی ProxyJump است. توجه داشته باشید که دستورالعمل‌های پیکربندی ارائه‌شده در خط فرمان عموماً بر میزبان مقصد اعمال می‌شوند و نه بر میزبان‌های پرش مشخص‌شده. از ~/.ssh/config برای تعیین پیکربندی میزبان‌های پرش استفاده کنید.
فعال‌سازی احراز هویت مبتنی بر GSSAPI و بازفرستادن (واگذاری) مدارک GSSAPI به سرور.
غیرفعال‌سازی بازفرستادن (واگذاری) مدارک GSSAPI به سرور.
[bind_address:]port:host:hostport
 
[bind_address:]port:remote_socket
 
local_socket:host:hostport
 
local_socket:remote_socket
مشخص می‌کند که اتصالات به درگاه TCP مشخص‌شده یا سوکت یونیکس در میزبان محلی (کلاینت)، باید به میزبان و درگاه داده‌شده، یا سوکت یونیکس، در سمت راه دور بازفرستاده شوند. این سازوکار با تخصیص یک سوکت برای گوش دادن به یک port (درگاه TCP) در سمت محلی (اختیاراً متصل به bind_address مشخص‌شده) یا به یک سوکت یونیکس کار می‌کند. هر زمان اتصالی به درگاه یا سوکت محلی برقرار شود، اتصال بر روی کانال امن بازفرستاده می‌شود، و اتصالی از ماشین راه دور به درگاه hostport روی میزبان host یا به سوکت یونیکس remote_socket برقرار می‌گردد.

بازفرستادن‌های درگاه را می‌توان در فایل پیکربندی نیز مشخص کرد. تنها کاربر ممتاز (superuser) می‌تواند درگاه‌های ممتاز را بازفرستد. نشانی‌های IPv6 را می‌توان با قرار دادن نشانی در براکت‌های چهارگوش مشخص کرد.

به‌طور پیش‌فرض، درگاه محلی مطابق با تنظیم GatewayPorts متصل می‌شود. با این حال، می‌توان از یک bind_address صریح برای متصل کردن اتصال به یک نشانی خاص استفاده کرد. مقدار “localhost” برای bind_address نشان می‌دهد که درگاه شنود تنها برای استفاده محلی متصل شود، در حالی که یک نشانی خالی یا ‘*’ نشان می‌دهد که درگاه باید بر روی تمام رابط‌ها در دسترس باشد.

login_name
تعیین نام کاربری برای ورود به ماشین راه دور. این مورد را می‌توان بر اساس هر میزبان در فایل پیکربندی نیز مشخص کرد.
قرار دادن کلاینت ssh در حالت “master” (اصلی) برای اشتراک‌گذاری اتصال. گزینه‌های مکرر -M کلاینت ssh را در حالت “master” قرار می‌دهند اما با الزام به تایید با استفاده از ssh-askpass(1) پیش از هر عملیاتی که وضعیت تسهیم‌سازی را تغییر دهد (مانند باز کردن یک نشست جدید). برای جزئیات بیشتر به توضیحات ControlMaster در ssh_config(5) مراجعه کنید.
mac_spec
فهرستی جداشده با کاما از الگوریتم‌های MAC (کد احراز اصالت پیام)، که به ترتیب اولویت مشخص شده‌اند. برای اطلاعات بیشتر کلیدواژه MACs را در ssh_config(5) ببینید.
دستور راه دور را اجرا نکن. این گزینه برای مواقعی که تنها قصد بازفرستادن درگاه‌ها را دارید مفید است. برای جزئیات به توضیحات SessionType در ssh_config(5) مراجعه کنید.
تغییر مسیر ورودی استاندارد از /dev/null (در واقع، جلوگیری از خواندن از stdin). هنگامی که ssh در پس‌زمینه اجرا می‌شود باید از این گزینه استفاده کرد. یک ترفند متداول استفاده از این گزینه برای اجرای برنامه‌های X11 بر روی ماشین راه دور است. برای مثال، ssh -n shadows.cs.hut.fi emacs & یک ویرایشگر emacs را روی shadows.cs.hut.fi اجرا می‌کند و اتصال X11 به‌طور خودکار از طریق یک کانال رمزگذاری‌شده بازفرستاده می‌شود. برنامه ssh در پس‌زمینه قرار خواهد گرفت. (این روش در صورتی که ssh نیاز به درخواست رمز عبور یا عبارت عبور داشته باشد کار نمی‌کند؛ همچنین گزینه -f را ببینید). برای جزئیات بیشتر به توضیحات StdinNull در ssh_config(5) مراجعه کنید.
ctl_cmd
کنترل یک فرایند اصلی (master) فعال برای تسهیم‌سازی اتصالات. هنگامی که گزینه -O مشخص می‌شود، آرگومان ctl_cmd تفسیر شده و به فرایند اصلی فرستاده می‌شود. دستورات معتبر عبارتند از: “check” (بررسی در حال اجرا بودن فرایند اصلی)، “conninfo” (گزارش اطلاعات درباره اتصال اصلی)، “channels” (گزارش اطلاعات درباره کانال‌های باز)، “forward” (درخواست بازفرستادن‌ها بدون اجرای دستور)، “cancel” (لغو بازفرستادن‌ها)، “proxy” (اتصال به یک فرایند اصلیِ تسهیم‌سازیِ در حال اجرا در حالت پروکسی)، “exit” (درخواست خروج از فرایند اصلی)، و “stop” (درخواست از فرایند اصلی برای متوقف کردن پذیرش درخواست‌های تسهیم‌سازی بیشتر).
option
می‌تواند برای ارائه گزینه‌ها در قالبی که در فایل پیکربندی استفاده می‌شود به کار رود. این گزینه برای تعیین تنظیماتی که سوئیچ جداگانه‌ای در خط فرمان ندارند مفید است. برای جزئیات کامل گزینه‌ها و مقادیر آن‌ها، ssh_config(5) را ببینید.
tag
مشخص کردن یک نام برچسب که می‌تواند برای انتخاب پیکربندی در ssh_config(5) استفاده شود. برای اطلاعات بیشتر به کلیدواژه‌های Tag و Match در ssh_config(5) مراجعه کنید.
port
درگاه برای اتصال به میزبان راه دور. این را می‌توان بر اساس هر میزبان در فایل پیکربندی مشخص کرد.
query_option
استعلام الگوریتم‌های پشتیبانی‌شده توسط یکی از ویژگی‌های زیر: cipher (رمزهای متقارن پشتیبانی‌شده)، cipher-auth (رمزهای متقارن پشتیبانی‌شده با پشتیبانی از رمزگذاری احراز هویت‌شده)، help (اصطلاحات پرس‌وجوی پشتیبانی‌شده برای استفاده با فلگ -Q)، mac (کدهای یکپارچگی پیام پشتیبانی‌شده)، kex (الگوریتم‌های تبادل کلید)، key (انواع کلید)، key-ca-sign (الگوریتم‌های معتبر امضای مرجع گواهی برای گواهی‌نامه‌ها)، key-cert (انواع کلیدهای گواهی‌نامه)، key-plain (انواع کلیدهای غیرگواهی‌نامه‌ای)، key-sig (تمام انواع کلید و الگوریتم‌های امضا)، protocol-version (نسخه‌های پشتیبانی‌شده پروتکل SSH)، و sig (الگوریتم‌های امضای پشتیبانی‌شده). همچنین، هر کلیدواژه‌ای از ssh_config(5) یا sshd_config(5) که یک فهرست الگوریتم را دریافت می‌کند، می‌تواند به عنوان نام مستعار برای query_option متناظر استفاده شود.
حالت بی‌صدا (Quiet mode). باعث فرونشاندن بیشتر پیام‌های هشدار و تشخیصی می‌شود.
[bind_address:]port:host:hostport
 
[bind_address:]port:local_socket
 
remote_socket:host:hostport
 
remote_socket:local_socket
 
[bind_address:]port
مشخص می‌کند که اتصالات به درگاه TCP تعیین‌شده یا سوکت یونیکس در میزبان راه دور (سرور)، باید به سمت محلی بازفرستاده شوند.

این قابلیت با تخصیص یک سوکت برای گوش دادن به یک port (درگاه TCP) یا به یک سوکت یونیکس در سمت راه دور کار می‌کند. هر زمان اتصالی به این درگاه یا سوکت یونیکس برقرار شود، اتصال بر روی کانال امن بازفرستاده می‌شود و اتصالی از ماشین محلی یا به مقصد صریح مشخص‌شده با درگاه hostport روی میزبان host، یا به local_socket برقرار می‌گردد؛ یا اگر هیچ مقصد صریحی تعیین نشده باشد، ssh به عنوان یک پروکسی SOCKS 4/5 عمل کرده و اتصالات را به مقاصد درخواست‌شده توسط کلاینت راه دور SOCKS بازمی‌فرستد.

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

به‌طور پیش‌فرض، سوکت‌های شنود TCP در سرور تنها به رابط loopback متصل می‌شوند. این مورد را می‌توان با تعیین یک bind_address لغو کرد. یک bind_address خالی، یا نشانی ‘*’، نشان می‌دهد که سوکت راه دور باید روی تمام رابط‌ها گوش دهد. تعیین یک bind_address راه دور تنها زمانی موفقیت‌آمیز خواهد بود که گزینه GatewayPorts سرور فعال باشد (به sshd_config(5) مراجعه کنید).

اگر آرگومان port برابر با ‘0’ باشد، درگاه شنود به صورت پویا در سرور تخصیص داده شده و در زمان اجرا به کلاینت گزارش می‌شود. هنگام استفاده همراه با -O forward، درگاه تخصیص‌یافته در خروجی استاندارد چاپ خواهد شد.

ctl_path
تعیین مکان یک سوکت کنترلی برای اشتراک‌گذاری اتصال، یا رشته “none” برای غیرفعال کردن اشتراک‌گذاری اتصال. برای جزئیات بیشتر به توضیحات ControlPath و ControlMaster در ssh_config(5) مراجعه کنید.
می‌تواند برای درخواست فراخوانی یک زیرسیستم (subsystem) در سیستم راه دور استفاده شود. زیرسیستم‌ها استفاده از SSH را به عنوان یک بستر انتقال امن برای برنامه‌های دیگر (مانند sftp(1)) تسهیل می‌کنند. زیرسیستم به عنوان دستور راه دور مشخص می‌شود. برای جزئیات بیشتر به توضیحات SessionType در ssh_config(5) مراجعه کنید.
غیرفعال‌سازی تخصیص پایانه مجازی (pseudo-terminal).
اجبار به تخصیص پایانه مجازی (pseudo-terminal). این می‌تواند برای اجرای برنامه‌های دلخواه مبتنی بر صفحه نمایش در یک ماشین راه دور استفاده شود، که می‌تواند بسیار مفید باشد، مثلاً هنگام پیاده‌سازی سرویس‌های منو. گزینه‌های مکرر -t تخصیص tty را اجبار می‌کنند، حتی اگر ssh هیچ tty محلی نداشته باشد.
نمایش شماره نسخه و خروج.
حالت پرحرف (Verbose mode). باعث می‌شود ssh پیام‌های اشکال‌زدایی درباره روند پیشرفت خود چاپ کند. این مورد در اشکال‌زدایی مشکلات اتصال، احراز هویت و پیکربندی مفید است. گزینه‌های مکرر -v میزان پرحرفی را افزایش می‌دهند. حداکثر مقدار ۳ است.
host:port
درخواست می‌کند که ورودی و خروجی استاندارد کلاینت از طریق کانال امن به host روی درگاه port بازفرستاده شود. این گزینه متضمن -N -، -T -، ExitOnForwardFailure و ClearAllForwardings است، هرچند این موارد را می‌توان در فایل پیکربندی یا با استفاده از گزینه‌های -o در خط فرمان نادیده گرفت.
local_tun[:remote_tun]
درخواست بازفرستادن دستگاه تونل با دستگاه‌های tun(4) مشخص‌شده میان کلاینت (local_tun) و سرور (remote_tun).

دستگاه‌ها ممکن است با شناسه عددی یا کلیدواژه “any” مشخص شوند، که از دستگاه تونل در دسترس بعدی استفاده می‌کند. اگر remote_tun مشخص نشده باشد، مقدار پیش‌فرض آن “any” است. همچنین دستورالعمل‌های Tunnel و TunnelDevice را در ssh_config(5) ببینید.

اگر دستورالعمل Tunnel تنظیم نشده باشد، روی حالت پیش‌فرض تونل یعنی “point-to-point” تنظیم خواهد شد. اگر حالت بازفرستادن متفاوتی برای Tunnel مورد نظر است، باید پیش از -w مشخص گردد.

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

بازفرستادن X11 باید با احتیاط فعال شود. کاربرانی که توانایی دور زدن دسترسی‌های فایل را در میزبان راه دور دارند (برای پایگاه‌داده مجوزهای X متعلق به کاربر) می‌توانند از طریق اتصال بازفرستاده‌شده به نمایشگر محلی X11 دسترسی یابند. یک مهاجم ممکن است پس از آن قادر به انجام اقداماتی چون شنود و پایش فشردن کلیدها (keystroke monitoring) باشد.

به همین دلیل، بازفرستادن X11 به‌طور پیش‌فرض مشمول محدودیت‌های افزونه امنیتی X11 SECURITY است. برای اطلاعات بیشتر به گزینه -Y از ssh و دستورالعمل ForwardX11Trusted در ssh_config(5) مراجعه کنید.

غیرفعال‌سازی بازفرستادن X11.
فعال‌سازی بازفرستادن مورد اعتماد X11 (trusted X11 forwarding). بازفرستادن‌های مورد اعتماد X11 مشمول کنترل‌های افزونه امنیتی X11 SECURITY نمی‌شوند.
ارسال اطلاعات ثبت وقایع با استفاده از ماژول سیستمی syslog(3). به‌طور پیش‌فرض این اطلاعات به stderr فرستاده می‌شود.
فهرست کردن کلیدهای عمومی که برای احراز هویت به مقصد تعیین‌شده به ترتیب اولویت امتحان می‌شوند و خروج.

ssh ممکن است علاوه بر این، داده‌های پیکربندی را از یک فایل پیکربندی ویژه کاربر و یک فایل پیکربندی سراسری سیستم به دست آورد. قالب فایل و گزینه‌های پیکربندی در ssh_config(5) شرح داده شده است.

کلاینت OpenSSH SSH از نسخه ۲ پروتکل SSH پشتیبانی می‌کند.

روش‌های موجود برای احراز هویت عبارتند از: احراز هویت مبتنی بر GSSAPI، احراز هویت مبتنی بر میزبان (host-based)، احراز هویت با کلید عمومی، احراز هویت تعاملی با صفحه‌کلید (keyboard-interactive)، و احراز هویت با گذرواژه (password). روش‌های احراز هویت به ترتیبی که در بالا مشخص شد آزمایش می‌شوند، هرچند PreferredAuthentications می‌تواند برای تغییر ترتیب پیش‌فرض استفاده شود.

احراز هویت مبتنی بر میزبان به شرح زیر عمل می‌کند: اگر ماشینی که کاربر از آن وارد می‌شود در /etc/hosts.equiv یا /etc/ssh/shosts.equiv بر روی ماشین راه دور فهرست شده باشد، کاربر غیرریشه باشد و نام‌های کاربری در هر دو طرف یکسان باشند، یا اگر فایل‌های ~/.rhosts یا ~/.shosts در دایرکتوری خانگی کاربر در ماشین راه دور موجود باشند و حاوی خطی شامل نام ماشین کلاینت و نام کاربر روی آن ماشین باشند، کاربر برای ورود مورد پذیرش قرار می‌گیرد. علاوه بر این، سرور باید قادر به تایید کلید میزبان کلاینت باشد (به توضیحات /etc/ssh/ssh_known_hosts و ~/.ssh/known_hosts در زیر مراجعه کنید) تا ورود مجاز شمرده شود. این روش احراز هویت رخنه‌های امنیتی ناشی از جعل IP، جعل DNS و جعل مسیریابی را می‌بندد. [یادداشت برای مدیر سیستم: /etc/hosts.equiv ، ~/.rhosts و پروتکل‌های rlogin/rsh به‌طور کلی ذاتاً ناامن هستند و در صورت نیاز به امنیت باید غیرفعال شوند.]

احراز هویت با کلید عمومی به شرح زیر عمل می‌کند: این طرح مبتنی بر رمزنگاری کلید عمومی است، با استفاده از سامانه‌های رمزنگاری که در آن‌ها رمزگذاری و رمزگشایی با کلیدهای جداگانه صورت می‌گیرد، و استخراج کلید رمزگشایی از روی کلید رمزگذاری غیرممکن است. ایده این است که هر کاربر یک جفت‌کلید عمومی/خصوصی برای اهداف احراز هویت می‌سازد. سرور کلید عمومی را می‌داند و تنها کاربر از کلید خصوصی مطلع است. ssh پروتکل احراز هویت با کلید عمومی را به صورت خودکار، با استفاده از یکی از الگوریتم‌های ECDSA، Ed25519 یا RSA پیاده‌سازی می‌کند.

فایل ~/.ssh/authorized_keys کلیدهای عمومی مجاز برای ورود را فهرست می‌کند. هنگامی که کاربر وارد می‌شود، برنامه ssh به سرور اعلام می‌کند که مایل است از کدام جفت‌کلید برای احراز هویت استفاده کند. کلاینت اثبات می‌کند که به کلید خصوصی دسترسی دارد و سرور بررسی می‌کند که کلید عمومی متناظر مجاز به پذیرش حساب باشد.

سرور ممکن است پس از تکمیل احراز هویت با روشی دیگر، کلاینت را از خطاهایی که مانع از موفقیت احراز هویت با کلید عمومی شده‌اند مطلع سازد. این خطاها را می‌توان با افزایش LogLevel به DEBUG یا بالاتر مشاهده کرد (مثلاً با استفاده از فلگ -v).

کاربر جفت‌کلید خود را با اجرای ssh-keygen(1) تولید می‌کند. این دستور کلید خصوصی را در ~/.ssh/id_ecdsa (برای ECDSA)، ~/.ssh/id_ecdsa_sk (برای ECDSA میزبانی‌شده روی احراز هویت‌کننده سخت‌افزاری)، ~/.ssh/id_ed25519 (برای Ed25519)، ~/.ssh/id_ed25519_sk (برای Ed25519 میزبانی‌شده روی احراز هویت‌کننده سخت‌افزاری)، ~/.ssh/id_mldsa44_ed25519 (برای MLDSA44-ED25519)، یا ~/.ssh/id_rsa (برای RSA) ذخیره می‌کند و کلید عمومی را در ~/.ssh/id_ecdsa.pub (برای ECDSA)، ~/.ssh/id_ecdsa_sk.pub (برای ECDSA میزبانی‌شده روی احراز هویت‌کننده سخت‌افزاری)، ~/.ssh/id_ed25519.pub (برای Ed25519)، ~/.ssh/id_ed25519_sk.pub (برای Ed25519 میزبانی‌شده روی احراز هویت‌کننده سخت‌افزاری)، ~/.ssh/id_mldsa44_ed25519.pub (برای MLDSA44-ED25519)، یا ~/.ssh/id_rsa.pub (برای RSA) در دایرکتوری خانگی کاربر ذخیره می‌نماید. سپس کاربر باید کلید عمومی را در ~/.ssh/authorized_keys در دایرکتوری خانگی خود در ماشین راه دور رونوشت کند. فایل authorized_keys متناظر با فایل متداول ~/.rhosts است و دارای یک کلید در هر خط است، هرچند خطوط می‌توانند بسیار طولانی باشند. پس از این، کاربر می‌تواند بدون وارد کردن گذرواژه وارد شود.

گونه‌ای دیگر از احراز هویت با کلید عمومی در قالب احراز هویت با گواهی‌نامه در دسترس است: به جای مجموعه‌ای از کلیدهای عمومی/خصوصی، از گواهی‌نامه‌های امضاشده استفاده می‌شود. این شیوه این مزیت را دارد که یک مرجع صدور گواهی‌نامه (CA) معتمد می‌تواند جایگزین تعداد زیادی از کلیدهای عمومی/خصوصی شود. برای اطلاعات بیشتر به بخش CERTIFICATES از ssh-keygen(1) مراجعه کنید.

راحت‌ترین روش برای استفاده از احراز هویت با کلید عمومی یا گواهی‌نامه می‌تواند استفاده از یک عامل احراز هویت باشد. برای اطلاعات بیشتر ssh-agent(1) و (اختیاراً) دستورالعمل AddKeysToAgent در ssh_config(5) را ببینید.

احراز هویت تعاملی با صفحه‌کلید (Keyboard-interactive) به شرح زیر کار می‌کند: سرور یک متن چالش ("challenge") دلخواه ارسال کرده و پاسخ را درخواست می‌کند، که ممکن است چند بار تکرار شود. نمونه‌هایی از احراز هویت تعاملی با صفحه‌کلید شامل احراز هویت BSD (به login.conf(5) مراجعه کنید) و PAM (در برخی سیستم‌های غیر OpenBSD) است.

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

ssh به‌طور خودکار پایگاه‌داده‌ای حاوی مشخصات شناسایی تمام میزبان‌هایی را که تا کنون با آن استفاده شده‌اند، نگهداری و بررسی می‌کند. کلیدهای میزبان در ~/.ssh/known_hosts در دایرکتوری خانگی کاربر ذخیره می‌شوند. علاوه بر این، فایل /etc/ssh/ssh_known_hosts به‌طور خودکار برای میزبان‌های شناخته‌شده بررسی می‌گردد. هر میزبان جدید به‌طور خودکار به فایل کاربر اضافه می‌شود. اگر هویت یک میزبان تغییر کند، ssh درباره این موضوع هشدار می‌دهد و احراز هویت با گذرواژه را غیرفعال می‌کند تا از حملات جعل سرور یا مرد میانی (man-in-the-middle) جلوگیری شود، که در غیر این صورت می‌توانستند برای دور زدن رمزگذاری استفاده شوند. گزینه StrictHostKeyChecking می‌تواند برای کنترل ورود به ماشین‌هایی که کلید میزبان آن‌ها ناشناخته است یا تغییر کرده، استفاده شود.

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

اگر یک نشست تعاملی درخواست شود، ssh به‌طور پیش‌فرض تنها زمانی برای نشست‌های تعاملی پایانه مجازی (pty) درخواست می‌کند که کلاینت دارای یک پایانه باشد. فلگ‌های -T و -t می‌توانند برای تغییر این رفتار استفاده شوند.

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

اگر پایانه مجازی تخصیص نیافته باشد، نشست شفاف است و می‌تواند برای انتقال مطمئن داده‌های باینری استفاده شود. در بیشتر سیستم‌ها، تنظیم نویسه گریز روی “none” نیز باعث می‌شود نشست حتی در صورت استفاده از tty شفاف باشد.

نشست زمانی پایان می‌یابد که دستور یا پوسته در ماشین راه دور خارج شود و تمام اتصالات X11 و TCP بسته شده باشند.

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

یک نویسه مدک (tilde) منفرد می‌تواند به صورت ~~ یا با دنبال کردن مدک توسط نویسه‌ای غیر از موارد شرح داده شده در زیر ارسال شود. نویسه گریز همواره باید پس از یک خط جدید بیاید تا به عنوان یک نویسه خاص تفسیر شود. نویسه گریز را می‌توان در فایل‌های پیکربندی با استفاده از دستورالعمل پیکربندی EscapeChar یا در خط فرمان با گزینه -e تغییر داد.

گریزهای پشتیبانی‌شده (با فرض مقدار پیش‌فرض ‘~’) عبارتند از:

قطع اتصال.
فرستادن ssh به پس‌زمینه.
فهرست کردن اتصالات بازفرستاده‌شده.
فرستادن ssh به پس‌زمینه هنگام خروج از سیستم، حین انتظار برای پایان یافتن اتصال بازفرستاده‌شده یا نشست‌های X11.
نمایش فهرستی از نویسه‌های گریز.
ارسال یک سیگنال BREAK به سیستم راه دور (تنها در صورتی مفید است که طرف مقابل از آن پشتیبانی کند).
باز کردن خط فرمان. در حال حاضر این مورد امکان افزودن بازفرستادن‌های درگاه را با استفاده از گزینه‌های -L -، -R و -D فراهم می‌سازد (به بالا مراجعه کنید). همچنین لغو بازفرستادن‌های موجود درگاه را امکان‌پذیر می‌کند با -KL[bind_address:]port برای محلی، -KR[bind_address:]port برای راه دور و -KD[bind_address:]port برای بازفرستادن‌های پویای درگاه. !command به کاربر اجازه می‌دهد تا در صورت فعال بودن گزینه PermitLocalCommand در ssh_config(5)، یک دستور محلی را اجرا کند. راهنمای اولیه با استفاده از گزینه -h در دسترس است.
نمایش اطلاعات درباره اتصال فعلی SSH.
درخواست کلیدگذاری مجدد (rekeying) اتصال (تنها در صورتی مفید است که طرف مقابل از آن پشتیبانی کند).
کاهش میزان پرحرفی (LogLevel) هنگامی که خطاها در stderr نوشته می‌شوند.
افزایش میزان پرحرفی (LogLevel) هنگامی که خطاها در stderr نوشته می‌شوند.

بازفرستادن اتصالات دلخواه TCP بر روی یک کانال امن را می‌توان هم در خط فرمان و هم در یک فایل پیکربندی مشخص کرد. یک کاربرد محتمل بازفرستادن TCP، اتصال امن به یک سرور ایمیل است؛ کاربرد دیگر عبور از دیوار آتش (firewall) است.

در مثال زیر، به رمزگذاری ارتباط برای یک کلاینت IRC می‌پردازیم، حتی اگر سرور IRC که به آن متصل می‌شود مستقیماً از ارتباط رمزگذاری‌شده پشتیبانی نکند. این شیوه به این صورت کار می‌کند: کاربر با استفاده از ssh به میزبان راه دور متصل می‌شود و درگاه‌های مورد استفاده برای بازفرستادن اتصال را مشخص می‌نماید. پس از آن اجرای برنامه به صورت محلی امکان‌پذیر است، و ssh اتصال به سرور راه دور را رمزگذاری و بازمی‌فرستد.

مثال زیر یک نشست IRC را از کلاینت به یک سرور IRC در “server.example.com” تونل می‌کند، با نام مستعار “pinky” به کانال “#users” می‌پوندد و از درگاه استاندارد IRC یعنی ۶۶۶۷ استفاده می‌نماید:

$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1

گزینه -f برنامه ssh را به پس‌زمینه می‌برد و دستور راه دور “sleep 10” مشخص شده است تا مدت زمانی (۱۰ ثانیه در این مثال) برای راه‌اندازی برنامه‌ای که قرار است از تونل استفاده کند در نظر گرفته شود. اگر هیچ اتصالی در مدت زمان مشخص‌شده برقرار نشود، ssh خارج خواهد شد.

اگر متغیر ForwardX11 بر روی “yes” تنظیم شده باشد (یا به شرح گزینه‌های -X -، -x و -Y در بالا مراجعه کنید) و کاربر از X11 استفاده کند (متغیر محیطی DISPLAY تنظیم شده باشد)، اتصال به نمایشگر X11 به‌طور خودکار به سمت راه دور بازفرستاده می‌شود، به گونه‌ای که هر برنامه X11 اجراشده از پوسته (یا دستور) از کانال رمزگذاری‌شده عبور می‌کند، و اتصال به سرور واقعی X از ماشین محلی برقرار می‌گردد. کاربر نباید به صورت دستی DISPLAY را تنظیم کند. بازفرستادن اتصالات X11 می‌تواند در خط فرمان یا در فایل‌های پیکربندی تنظیم شود.

مقدار DISPLAY تنظیم‌شده توسط ssh به ماشین سرور اشاره خواهد کرد، اما با یک شماره نمایشگر بزرگ‌تر از صفر. این روال عادی است، و به این دلیل رخ می‌دهد که ssh یک سرور X به صورت پروکسی (“proxy”) در ماشین سرور ایجاد می‌کند تا اتصالات را روی کانال رمزگذاری‌شده بازفرستد.

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

اگر متغیر ForwardAgent روی “yes” تنظیم شده باشد (یا شرح گزینه‌های -A و -a در بالا را ببینید) و کاربر از یک عامل احراز هویت استفاده کند، اتصال به عامل به‌طور خودکار به سمت راه دور بازفرستاده می‌شود.

هنگام اتصال به یک سرور برای نخستین بار، یک اثر انگشت از کلید عمومی سرور به کاربر ارائه می‌شود (مگر اینکه گزینه StrictHostKeyChecking غیرفعال شده باشد). اثر انگشت را می‌توان با استفاده از ssh-keygen(1) تعیین کرد:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

اگر اثر انگشت از قبل شناخته شده باشد، می‌توان آن را مطابقت داد و کلید را پذیرفت یا رد کرد. اگر فقط اثر انگشت‌های قدیمی (MD5) برای سرور در دسترس باشند، گزینه -E در ssh-keygen(1) می‌تواند برای تنزل الگوریتم اثر انگشت جهت تطبیق استفاده شود.

به دلیل دشواری مقایسه کلیدهای میزبان صرفاً با نگاه کردن به رشته‌های اثر انگشت، پشتیبانی از مقایسه چشمی و بصری کلیدهای میزبان نیز با استفاده از هنر تصادفی () وجود دارد. با تنظیم گزینه VisualHostKey روی “yes ،” یک تصویر اسکی (ASCII) کوچک در هر بار ورود به سرور نمایش داده می‌شود، چه نشست تعاملی باشد و چه نباشد. با یادگیری الگویی که یک سرور شناخته‌شده تولید می‌کند، کاربر در صورت نمایش یک الگوی کاملاً متفاوت می‌تواند به سادگی دریابد که کلید میزبان تغییر کرده است. اما از آنجا که این الگوها کاملاً غیرمبهم نیستند، الگویی که شبیه به الگوی به‌خاطرسپرده‌شده باشد تنها یک احتمال بالا از یکسان بودن کلید میزبان به دست می‌دهد، و اثبات تضمین‌شده‌ای نیست.

برای دریافت فهرستی از اثر انگشت‌ها همراه با هنر تصادفی آن‌ها برای تمام میزبان‌های شناخته‌شده، خط فرمان زیر می‌تواند استفاده شود:

$ ssh-keygen -lv -f ~/.ssh/known_hosts

اگر اثر انگشت ناشناخته باشد، یک روش جایگزین برای اعتبارسنجی در دسترس است: اثر انگشت‌های SSH تاییدشده توسط DNS. یک رکورد منبع اضافی (RR)، به نام SSHFP، به فایل منطقه (zonefile) افزوده می‌شود و کلاینت متصل‌شونده قادر است اثر انگشت را با اثر انگشت کلید ارائه‌شده تطبیق دهد.

در این مثال، ما در حال اتصال یک کلاینت به یک سرور در “host.example.com” هستیم. ابتدا باید رکوردهای منبع SSHFP به فایل منطقه برای host.example.com افزوده شوند:

$ ssh-keygen -r host.example.com.

خطوط خروجی باید به فایل منطقه اضافه شوند. برای بررسی اینکه آیا منطقه به پرس‌وجوهای اثر انگشت پاسخ می‌دهد:

$ dig -t SSHFP host.example.com

در نهایت کلاینت متصل می‌شود:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

برای اطلاعات بیشتر گزینه VerifyHostKeyDNS را در ssh_config(5) ببینید.

ssh حاوی پشتیبانی از تونل‌سازی شبکه خصوصی مجازی (VPN) با استفاده از شبه‌دستگاه شبکه tun(4) است، که امکان پیوستن امن دو شبکه به یکدیگر را فراهم می‌کند. گزینه پیکربندی PermitTunnel در sshd_config(5) کنترل می‌کند که آیا سرور از این قابلیت پشتیبانی می‌کند یا خیر، و در چه سطحی (ترافیک لایه ۲ یا لایه ۳).

مثال زیر شبکه کلاینت 10.0.50.0/24 را با استفاده از یک اتصال نقطه به نقطه از 10.1.1.1 به 10.1.1.2 به شبکه راه دور 10.0.99.0/24 متصل می‌سازد، به شرط آنکه سرور SSH در حال اجرا بر روی دروازه (gateway) شبکه راه دور در 192.168.1.15 این اجازه را بدهد.

در سمت کلاینت:

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

در سمت سرور:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

دسترسی کلاینت می‌تواند از طریق فایل /root/.ssh/authorized_keys (به زیر مراجعه کنید) و گزینه سرور PermitRootLogin با دقت بیشتری تنظیم شود. مدخل زیر اتصالات را بر روی دستگاه tun(4) شماره ۱ از کاربر “jane” و بر روی دستگاه تونل شماره ۲ از کاربر “john” مجاز می‌دارد، در صورتی که PermitRootLogin بر روی “forced-commands-only” تنظیم شده باشد:

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

از آنجا که راه‌اندازی مبتنی بر SSH مستلزم بار اضافی (overhead) قابل توجهی است، ممکن است برای راه‌اندازی‌های موقت، مانند VPNهای بی‌سیم مناسب‌تر باشد. شبکه‌های خصوصی مجازی پایدارتر بهتر است توسط ابزارهایی مانند ipsecctl(8) و isakmpd(8) فراهم شوند.

ssh به‌طور معمول متغیرهای محیطی زیر را مقداردهی می‌کند:

متغیر DISPLAY محل سرور X11 را مشخص می‌کند. این متغیر به‌طور خودکار توسط ssh تنظیم می‌شود تا به مقداری به شکل “hostname:n” اشاره کند، که در آن “hostname” نشان‌دهنده میزبانی است که پوسته در آن اجرا می‌شود و ‘n’ یک عدد صحیح ≥ 1 است. ssh از این مقدار ویژه برای بازفرستادن اتصالات X11 بر روی کانال امن استفاده می‌نماید. کاربر معمولاً نباید DISPLAY را به صراحت تنظیم کند، زیرا این کار اتصال X11 را ناامن خواهد ساخت (و کاربر را ملزم می‌کند تا کوکی‌های مجوز مورد نیاز را به صورت دستی کپی کند).
روی مسیر دایرکتوری خانگی کاربر تنظیم می‌شود.
مترادفی برای USER؛ جهت سازگاری با سیستم‌هایی که از این متغیر استفاده می‌کنند تنظیم شده است.
روی مسیر صندوق پستی کاربر تنظیم می‌شود.
روی PATH پیش‌فرض تنظیم می‌شود، همان‌گونه که هنگام کامپایل ssh مشخص شده است.
اگر ssh به عبارت عبور نیاز داشته باشد، در صورتی که از یک پایانه اجرا شده باشد آن را از پایانه فعلی می‌خواند. اگر ssh پایانه‌ای مرتبط با خود نداشته باشد اما DISPLAY و SSH_ASKPASS تنظیم شده باشند، برنامه‌ای را که توسط SSH_ASKPASS مشخص شده اجرا کرده و یک پنجره X11 را برای خواندن عبارت عبور باز می‌کند. این قابلیت به ویژه هنگام فراخوانی ssh از یک .xsession یا اسکریپت مرتبط بسیار سودمند است. (توجه داشته باشید که در برخی ماشین‌ها ممکن است لازم باشد ورودی از /dev/null هدایت شود تا این سازوکار عمل کند).
امکان کنترل بیشتر بر استفاده از یک برنامه askpass را فراهم می‌سازد. اگر این متغیر روی “never” تنظیم شده باشد، آنگاه ssh هرگز برای استفاده از آن تلاشی نخواهد کرد. اگر روی “prefer” تنظیم شده باشد، آنگاه ssh هنگام درخواست گذرواژه‌ها، استفاده از برنامه askpass را به TTY ترجیح می‌دهد. در نهایت، اگر این متغیر روی “force” تنظیم شود، از برنامه askpass برای تمام ورودی‌های عبارت عبور، بدون توجه به تنظیم بودن DISPLAY استفاده خواهد شد.
مسیر سوکت دامنه UNIX (UNIX-domain) را که برای برقراری ارتباط با عامل احراز هویت استفاده می‌شود، مشخص می‌کند.
طرف‌های کلاینت و سرورِ اتصال را مشخص می‌نماید. این متغیر حاوی چهار مقدار است که با فاصله جدا شده‌اند: نشانی IP کلاینت، شماره درگاه کلاینت، نشانی IP سرور و شماره درگاه سرور.
این متغیر در صورتی که یک دستور اجباری اجرا شود، حاوی خط فرمان اصلی خواهد بود. می‌توان از آن برای استخراج آرگومان‌های اصلی استفاده کرد.
روی نام tty (مسیر دستگاه) مرتبط با پوسته یا دستور فعلی تنظیم می‌شود. اگر نشست فعلی فاقد tty باشد، این متغیر مقداردهی نمی‌گردد.
به‌صورت اختیاری توسط sshd(8) تنظیم می‌شود تا در صورتی که بازفرستادن تونل توسط کلاینت درخواست شده باشد، حاوی نام‌های رابط‌های اختصاص‌یافته باشد.
به‌صورت اختیاری توسط sshd(8) تنظیم می‌شود؛ این متغیر ممکن است حاوی نام مسیری به یک فایل باشد که روش‌های احراز هویت با موفقیت استفاده‌شده هنگام برقراری نشست را، به انضمام کلیدهای عمومی مورد استفاده، فهرست می‌کند.
این متغیر در صورتی که در زمان راه‌اندازی دیمون تنظیم شده باشد، برای نشان دادن منطقه زمانی فعلی تنظیم می‌شود (یعنی دیمون مقدار را به اتصالات جدید منتقل می‌کند).
روی نام کاربری که وارد می‌شود تنظیم می‌گردد.

علاوه بر این، ssh فایل ~/.ssh/environment را می‌خواند و در صورتی که این فایل موجود باشد و کاربران مجاز به تغییر محیط خود باشند، خطوطی با ساختار “VARNAME=value” را به متغیرهای محیطی می‌افزاید. برای اطلاعات بیشتر، به گزینه PermitUserEnvironment در sshd_config(5) مراجعه کنید.

~/.rhosts
این فایل برای احراز هویت مبتنی بر میزبان به کار می‌رود (به بالا مراجعه کنید). در برخی ماشین‌ها ممکن است لازم باشد این فایل در صورتی که دایرکتوری خانگی کاربر روی یک پارتیشن NFS قرار دارد، برای همگان قابل خواندن (world-readable) باشد، زیرا sshd(8) آن را با دسترسی ریشه (root) می‌خواند. علاوه بر این، مالکیت این فایل باید متعلق به خود کاربر باشد و نباید مجوز نوشتن برای افراد دیگر داشته باشد. مجوزهای توصیه‌شده برای اکثر ماشین‌ها خواندن/نوشتن برای کاربر است، بدون قابلیت دسترسی توسط دیگران.
~/.shosts
این فایل دقیقاً به همان روش .rhosts استفاده می‌شود، اما احراز هویت مبتنی بر میزبان را بدون دادن مجوز ورود با rlogin/rsh ممکن می‌سازد.
~/.ssh/
این دایرکتوری محل پیش‌فرض برای کلیه اطلاعات پیکربندی و احراز هویت ویژه هر کاربر است. هیچ الزام عمومی برای مخفی نگه داشتن کل محتویات این دایرکتوری وجود ندارد، اما دسترسی‌های توصیه‌شده شامل خواندن/نوشتن/اجرا برای خود کاربر و عدم دسترسی توسط دیگران است.
~/.ssh/authorized_keys
کلیدهای عمومی (ECDSA، Ed25519، RSA) را که می‌توانند برای ورود با هویت این کاربر به کار روند، فهرست می‌کند. قالب این فایل در صفحه راهنمای sshd(8) شرح داده شده است. این فایل از حساسیت بالایی برخوردار نیست، اما مجوزهای توصیه‌شده خواندن/نوشتن برای کاربر و غیرقابل دسترس بودن برای دیگران است.
~/.ssh/config
این فایل پیکربندی اختصاصی کاربر است. قالب فایل و گزینه‌های پیکربندی در ssh_config(5) توصیف شده‌اند. به دلیل امکان سوءاستفاده، این فایل باید دسترسی‌های سخت‌گیرانه‌ای داشته باشد: خواندن/نوشتن برای کاربر و غیرقابل نوشتن برای دیگران.
~/.ssh/environment
شامل تعاریف اضافی برای متغیرهای محیطی است؛ به بخش محیط (ENVIRONMENT) در بالا رجوع فرمایید.
~/.ssh/id_ecdsa
 
~/.ssh/id_ecdsa_sk
 
~/.ssh/id_ed25519
 
~/.ssh/id_ed25519_sk
 
~/.ssh/id_mldsa44_ed25519
 
~/.ssh/id_rsa
شامل کلید خصوصی برای احراز هویت است. این فایل‌ها حاوی داده‌های حساس هستند و باید توسط کاربر قابل خواندن باشند اما برای دیگران غیرقابل دسترس باشند (خواندن/نوشتن/اجرا). اگر یک فایل کلید خصوصی برای دیگران قابل دسترسی باشد، ssh به سادگی آن را نادیده خواهد گرفت. می‌توان هنگام تولید کلید یک عبارت عبور تعیین کرد که برای رمزگذاری بخش حساس این فایل با استفاده از AES-128 به کار می‌رود.
~/.ssh/id_ecdsa.pub
 
~/.ssh/id_ecdsa_sk.pub
 
~/.ssh/id_ed25519.pub
 
~/.ssh/id_ed25519_sk.pub
 
~/.ssh/id_mldsa44_ed25519.pub
 
~/.ssh/id_rsa.pub
شامل کلید عمومی برای احراز هویت است. این فایل‌ها حساس نیستند و می‌توانند (اما الزامی نیست) برای هر فردی قابل خواندن باشند.
~/.ssh/known_hosts
شامل فهرستی از کلیدهای میزبان برای تمام میزبان‌هایی است که کاربر به آن‌ها وارد شده و در فهرست سراسری سیستم از کلیدهای میزبان شناخته‌شده وجود ندارند. برای جزئیات بیشتر درباره قالب این فایل، sshd(8) را ببینید.
~/.ssh/rc
دستورات موجود در این فایل هنگامی که کاربر وارد سیستم می‌شود، دقیقاً پیش از شروع پوسته (یا دستور) کاربر، توسط ssh اجرا می‌شوند. برای اطلاعات بیشتر به صفحه راهنمای sshd(8) مراجعه فرمایید.
/etc/hosts.equiv
این فایل برای احراز هویت مبتنی بر میزبان است (به بالا مراجعه کنید). این فایل تنها باید توسط کاربر ریشه (root) قابل نوشتن باشد.
/etc/ssh/shosts.equiv
این فایل دقیقاً به همان روش hosts.equiv استفاده می‌شود، اما احراز هویت مبتنی بر میزبان را بدون اجازه ورود از طریق rlogin/rsh فراهم می‌سازد.
/etc/ssh/ssh_config
فایل پیکربندی سراسری سیستم. قالب فایل و گزینه‌های پیکربندی در ssh_config(5) شرح داده شده است.
/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
این فایل‌ها حاوی بخش‌های خصوصی از کلیدهای میزبان هستند و برای احراز هویت مبتنی بر میزبان به کار می‌روند.
/etc/ssh/ssh_known_hosts
فهرست سراسری سیستم از کلیدهای شناخته‌شده میزبان. این فایل باید توسط مدیر سیستم آماده شود تا حاوی کلیدهای عمومی میزبانِ تمامی ماشین‌های سازمان باشد. این فایل باید برای همگان قابل خواندن باشد. برای جزئیات بیشتر پیرامون قالب این فایل sshd(8) را ببینید.
/etc/ssh/sshrc
دستورات موجود در این فایل زمانی که کاربر وارد می‌شود، درست پیش از شروع پوسته (یا دستور) کاربر، توسط ssh اجرا می‌گردند. برای اطلاعات بیشتر به صفحه راهنمای sshd(8) مراجعه کنید.

ssh با وضعیت خروج دستور راه دور یا در صورت بروز خطا با مقدار 255 خارج می‌شود.

scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, January 2006.

J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, January 2006.

F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, January 2006.

J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, January 2006.

M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, January 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, January 2006.

M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006.

J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, November 2006.

D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, December 2009.

A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

OpenSSH مشتقی از نسخه اصلی و آزاد ssh 1.2.12 اثر Tatu Ylonen است. Aaron Campbell، Bob Beck، Markus Friedl، Niels Provos، Theo de Raadt و Dug Song اشکالات متعددی را برطرف ساختند، قابلیت‌های جدیدتر را بازگرداندند و OpenSSH را ایجاد کردند. Markus Friedl پشتیبانی از پروتکل SSH نسخه‌های ۱.۵ و ۲.۰ را ارائه و پیاده‌سازی کرد.

August 4, 2026 Linux 6.12.107+deb13-amd64