.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.TH "psusan" "1" "2020\(hy12\(hy13" "PuTTY\ tool\ suite" "PuTTY\ tool\ suite"
.SH "نام (NAME)"
.PP
\fBpsusan\fP \- شبه\-SSH برای شبکه‌های شنودناپذیر با احراز هویت جداگانه
.SH "خلاصه دستور (SYNOPSIS)"
.PP
.nf
\fBpsusan\fP\ [\ \fIگزینه‌ها\fP\ ]
.fi
.SH "توضیحات (DESCRIPTION)"
.PP
برنامهٔ \fBpsusan\fP یک برنامهٔ کارگزار (سرور) است که مانند درونی‌ترین لایهٔ «اتصال» (connection) یک نشست SSH، بدون دو لایهٔ امنیتی بیرونی رمزنگاری و احراز هویت رفتار می‌کند. این برنامه تمامی امکانات پس از احراز هویت یک اتصال SSH را ارائه می‌دهد:
.IP "\fB\(bu\fP"
انتخاب بین اجرای یک نشست ترمینال تعاملی یا یک دستور مشخصِ منفرد
.IP "\fB\(bu\fP"
چندین نشست ترمینال به‌طور هم‌زمان (یا ترکیبی از آن‌ها و دستورهای مشخص‌شده)
.IP "\fB\(bu\fP"
انتقال فایل SFTP
.IP "\fB\(bu\fP"
تمام گزینه‌های استاندارد فوروارد پورت (port-forwarding) در SSH
.IP "\fB\(bu\fP"
فوروارد X11
.IP "\fB\(bu\fP"
فوروارد کارگزار SSH (SSH agent)
.PP
نکتهٔ قابل توجه این است که به دلیل نبود لایه‌های بیرونی SSH، باید آن را روی نوعی کانال داده اجرا کنید که از قبل برای کاربر مورد نظر احراز هویت شده باشد و در برابر شنود و ربایش نشست (session hijacking) به حد کافی حفاظت شده باشد. یک قاعدهٔ سرانگشتی خوب این است: روی هر کانالی که حاضر بودید یک نشست پوستهٔ \fIساده\fP (bare) اجرا کنید، می‌توانید به جای آن \fBpsusan\fP را اجرا کنید؛ این کار تمام امکانات بالا را بدون تغییر در ویژگی‌های امنیتی به شما می‌دهد.
.PP
پروتکلی که \fBpsusan\fP استفاده می‌کند، توسط PuTTY، Plink، PSCP و PSFTP نیز پشتیبانی می‌شود؛ البته در صورتی که نوع پروتکل را «Bare ssh-connection» یا گزینهٔ خط فرمان \fB-ssh-connection\fP انتخاب کرده و به جای نام میزبان، مسیر مطلق سوکت دامنهٔ یونیکس (Unix-domain socket) مربوطه را مشخص نمایید.
.SH "مثال‌ها (EXAMPLES)"
.PP
ایدهٔ یک کانال دادهٔ امن و از پیش احراز هویت شده، شاید برای افرادی که به اتصالات \fIشبکه‌ای\fP فکر می‌کنند غریب به نظر برسد. اما در بافت یک سیستم یونیکس منفرد، نمونه‌های فراوانی وجود دارد و این دقیقاً جایی است که \fBpsusan\fP معمولاً کاربرد دارد.
.SS "Docker"
.PP
یک نمونهٔ خوب، کنسول یا کانال ورودی/خروجی استانداردی است که به یک کانتینر یا سیستم مجازی‌سازی منتهی می‌شود. Docker نمونه‌ای آشناست. اگر بخواهید یک کانتینر Docker را راه‌اندازی کرده و یک پوسته را مستقیماً درون آن اجرا کنید، ممکن است دستوری مانند زیر بنویسید:
.PP
.nf
docker\ run\ \-i\ \-t\ \fIsome:image\fP
.fi
.PP
که به شما اجازه می‌دهد یک نشست پوستهٔ منفرد را درون کانتینر، در همان ترمینالی که Docker را از آن اجرا کرده‌اید، به کار بیندازید.
.PP
فرض کنید ترجیح می‌دهید \fIچندین\fP نشست پوسته را به‌طور هم‌زمان در همان کانتینر اجرا کنید (شاید برای اینکه یکی از آن‌ها بتواند از ابزارهای اشکال‌زدایی برای بررسی کار دیگری استفاده کند). همچنین شاید بخواهید برنامه‌ای را داخل کانتینر اجرا کنید که به دسترسی کامل آن به شبکه‌تان اعتماد ندارید، اما حاضرید اجازه دهید یک یا دو اتصال شبکهٔ مشخص را برقرار کند، درست مانند اتصالی که با فوروارد پورت SSH راه‌اندازی می‌کنید.
.PP
در این حالت، می‌توانید گزینهٔ \fB-t\fP را از خط فرمان Docker حذف کنید (که به معنی «تخصیص یک دستگاه ترمینال» است)، و به آن بگویید که \fBpsusan\fP را درون کانتینر اجرا کند:
.PP
.nf
docker\ run\ \-i\ \fIsome:image\fP\ /\fIsome/path/to\fP/psusan
.fi
.PP
(البته باید مطمئن شوید که \fBpsusan\fP در جایی درون ایمیج کانتینر نصب شده باشد.)
.PP
اگر این کار را از خط فرمان پوسته انجام دهید، خط اعلانی (banner) شبیه به این خواهید دید:
.PP
.nf
SSHCONNECTION@putty.projects.tartarus.org\-2.0\-PSUSAN_Release_0.75
.fi
.PP
که فایدهٔ چندانی ندارد، جز اینکه نشان می‌دهد \fBpsusan\fP با موفقیت راه‌اندازی شده است.
.PP
برای برقراری ارتباط \fIمفید و کاربردی\fP با این سرور، می‌توانید یک نشست ذخیره‌شدهٔ PuTTY را به صورت زیر تنظیم کنید:
.IP "\fB\(bu\fP"
پروتکل را روی «Bare ssh-connection» (پروتکل \fBpsusan\fP) قرار دهید.
.IP "\fB\(bu\fP"
در کادر hostname \fIچیزی\fP بنویسید. این عبارت در عنوان پنجرهٔ PuTTY (در صورت اجرای گرافیکی PuTTY) نمایش داده می‌شود، بنابراین شاید بخواهید چیزی بنویسید که ماهیت پنجره را به شما یادآوری کند. اگر نظر خاصی ندارید، عبارتی عمومی مانند «\fBdummy\fP» کفایت می‌کند.
.IP "\fB\(bu\fP"
در برگهٔ پیکربندی «Proxy»، نوع پراکسی را روی «Local» تنظیم کرده و دستور «\fBdocker run\fP» بالا را در کادر متنی «Telnet command, or local proxy command» وارد نمایید.
.IP "\fB\(bu\fP"
در برگهٔ پیکربندی «SSH»، به احتمال زیاد مایل خواهید بود قابلیت اشتراک اتصال (connection sharing) را فعال کنید. (به ادامه مراجعه نمایید.)
.PP
این کار ترتیبی می‌دهد که PuTTY هنگام راه‌اندازی، به جای برقراری یک اتصال شبکه‌ای، دستور Docker بالا را اجرا کند و با استفاده از پروتکل شبیه به SSH در \fBpsusan\fP، با آن دستور ارتباط برقرار نماید.
.PP
نتیجه این است که همچنان یک نشست پوسته در بستر کانتینر Docker خواهید داشت، اما این بار با تمام امکانات رفاهی SSH همراه است. اگر اشتراک اتصال را نیز در برگهٔ پیکربندی «SSH» فعال کرده باشید، گزینهٔ «Duplicate Session» یک پوستهٔ دوم در \fIهمان\fP کانتینر Docker به شما می‌دهد (به جای یک پوستهٔ اصلی در نمونه‌ای جداگانه). می‌توانید در حین اجرای کانتینر، با استفاده از PSCP یا PSFTP فایل‌ها را به داخل و خارج آن منتقل کنید؛ پورت‌های شبکه، برنامه‌های گرافیکی X11 یا کارگزار SSH را به داخل کانتینر فوروارد نمایید.
.PP
مسلماً راه دیگر برای انجام همهٔ این کارها، اجرای پروتکل \fIکامل\fP SSH روی همان کانال است. اما این روش نیازمند پیکربندی بیشتری است: باید یک کلید میزبان SSH برای کانتینر بسازید، آن را در کلاینت بپذیرید، و با باقی ماندن آن در حافظهٔ موقت کلیدهای میزبان کلاینت پس از دور انداخته شدن کانتینر سر و کله بزنید. همچنین باید اطلاعات ورود به سیستم را در کانتینر تنظیم کنید: یا گذرواژه‌ای تعیین کرده و آن را در کلاینت وارد کنید، یا کلید عمومی SSH موجود خود را در آن کپی نمایید. تمام این دردسرها \fIغیرضروری\fP است، زیرا این‌ها اقدامات احتیاطی‌ای هستند که هنگام عبور اتصال بین دو سیستم از یک شبکهٔ ناامن و متخاصم الزامی می‌شوند. در این حالت، اتصال تنها از طریق کانال IPC هسته عبور می‌کند که رسیدن آن به مقصد درست تضمین‌شده است؛ بنابراین چنین اقدامات ایمنی مضاعف و زائد بوده و تنها موجب دشواری کار می‌شوند.
.SS "User-mode Linux"
.PP
User-mode Linux (یا UML) نوع دیگری از کانتینر است که می‌توانید به همین شیوه با آن ارتباط برقرار کنید. در ادامه یک مثال عملی کوچک آورده شده است.
.PP
\fIساده‌ترین\fP روش برای اجرای UML استفاده از نوع سیستم فایل «\fBhostfs\fP» آن است تا به هستهٔ مهمان دسترسی به همان سیستم فایل مجازیِ موجود در میزبان داده شود. برای نمونه، خط فرمانی مانند این یک اعلان پوسته در نمونه‌ای از UML در اختیارتان می‌گذارد که از سیستم فایل فعلی شما استفاده می‌کند:
.PP
.nf
linux\ mem=512M\ rootfstype=hostfs\ rootflags=/\ rw\ init=/bin/bash
.fi
.PP
اگر این دستور را در خط فرمان اجرا کنید (با فرض اینکه هستهٔ UML در مسیر شما با نام «\fBlinux\fP» در دسترس باشد)، باید پیام‌های متعدد آغاز به کار هسته را مشاهده کنید که به دنبال آن یک اعلان پوسته شبیه به زیر ظاهر می‌شود:
.PP
.nf
root@(none):/#
.fi
.PP
برای تبدیل این مورد به یک نشست UML مبتنی بر \fBpsusan\fP، باید خط فرمان را طوری ویرایش کنیم که به جای اجرای \fBbash\fP، برنامهٔ \fBpsusan\fP را اجرا کند. اما اجرای مستقیم \fBpsusan\fP به تنهایی کافی نیست، زیرا \fBpsusan\fP به مقدار کمی پیکربندی اولیه، نظیر سوار بودن \fB/proc\fP نیاز دارد. بنابراین به جای آن، فرایند init را روی یک اسکریپت پوسته تنظیم می‌کنیم که کارهای لازم را انجام داده و \fIسپس\fP \fBpsusan\fP را فراخوانی کند.
.PP
همچنین اجرای مستقیم \fBpsusan\fP روی دستگاه کنسول UML ایدهٔ مناسبی نیست، زیرا در این صورت پروتکل دودویی \fBpsusan\fP با پیام‌های متنی کنسول آمیخته می‌شود. بنابراین راه‌حل بهتر این است که کنسول UML را به خروجی خطای استاندارد فرایند \fBlinux\fP هدایت کرده و ورودی و خروجی استاندارد آن را به یک درگاه سریال نگاشت کنیم. بدین ترتیب خط فرمان جایگزین UML ممکن است شبیه به این باشد:
.PP
.nf
linux\ mem=512M\ rootfstype=hostfs\ rootflags=/\ rw\ \e
\ \ \ \ con=fd:2,fd:2\ ssl0=fd:0,fd:1\ init=\fI/some/path/to/uml\-psusan.sh\fP
.fi
.PP
و اسکریپت راه‌اندازی \fBuml-psusan.sh\fP می‌تواند به این شکل باشد:
.PP
.nf
#!/bin/bash
\fI#\ Set\ up\ vital\ pseudo\-filesystems\fP
mount\ \-t\ proc\ none\ /proc
mount\ \-t\ devpts\ none\ /dev/pts
\fI#\ Redirect\ I/O\ to\ the\ serial\ port,\ but\ stderr\ to\ the\ console\fP
exec\ 0<>/dev/ttyS0\ 1>&0\ 2>/dev/console
\fI#\ Set\ the\ serial\ port\ into\ raw\ mode,\ to\ run\ a\ binary\ protocol\fP
stty\ raw\ \-echo
\fI#\ Choose\ what\ shell\ you\ want\ to\ run\ inside\ psusan\fP
export\ SHELL=/bin/bash
\fI#\ Set\ up\ a\ default\ path\fP
export\ PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
\fI#\ And\ now\ run\ psusan\ over\ the\ serial\ port\fP
exec\ /home/simon/src/putty/misc/psusan
.fi
.PP
اکنون یک نشست ذخیره‌شدهٔ PuTTY را مانند مثال Docker بالا تنظیم کنید. اساساً می‌خواهید از دستور \fBlinux\fP بالا به عنوان دستور پراکسی محلی استفاده کنید. با این حال، ارزش دارد آن را درون \fBsetsid\fP(\fI1\fP) قرار دهید؛ زیرا هنگام بسته شدن UML، تمام گروه فرایندی خود را می‌کشد. بنابراین بهتر است PuTTY جزئی از آن گروه نباشد تا فرصت داشته باشد خودش به‌طور تمیز بسته شود. در نتیجه احتمالاً در نهایت دستور پراکسی را چیزی شبیه به این تنظیم خواهید کرد:
.PP
.nf
setsid\ linux\ mem=512M\ rootfstype=hostfs\ rootflags=/\ rw\ \e
\ \ \ \ con=fd:2,fd:2\ ssl0=fd:0,fd:1\ init=\fI/some/path/to/uml\-psusan.sh\fP
.fi
.PP
همچنین ممکن است متوجه شوید که باید ترفند دور زدن باگی را که نشان می‌دهد سرور «داده‌های ارسال‌شده پیش از پیام خوشامدگویی‌اش را دور می‌اندازد» (Discards data sent before its greeting) فعال کنید، زیرا در غیر این صورت پیام آغازین پروتکل ارسالی PuTTY ممکن است در طول راه‌اندازی UML تصادفاً از بین برود. (باگ دبیان شمارهٔ ۹۹۱۹۵۸ را ببینید.)
.PP
پس از انجام این کار، یک نشست PuTTY خواهید داشت که با اجرای آن یک نمونهٔ تمیز از UML راه‌اندازی می‌شود و (در صورت فعال بودن اشتراک اتصال) نمونه‌های بعدی از همان نشست مجدداً به همان نمونه متصل خواهند شد.
.SS "Windows Subsystem for Linux"
.PP
در ویندوز، روش پیش‌فرض برای استفاده از WSL اجرای برنامهٔ \fBwsl\fP یا یکی از نام‌های مستعار آن در کنسول ویندوز است؛ چه با اجرای آن از یک خط فرمان موجود، و چه با استفاده از میانبری که آن را در یک کنسول جدید باز می‌کند. این کار یک محیط ترمینال لینوکس اما درون پنجرهٔ کنسول ویندوز در اختیارتان می‌گذارد.
.PP
اگر ترجیح می‌دهید با استفاده از PuTTY به عنوان ترمینال با همان محیط تعامل داشته باشید (مثلاً اگر میانبرهای موشواره در PuTTY برای کپی و جای‌گذاری را ترجیح می‌دهید)، می‌توانید با نصب \fBpsusan\fP در محیط لینوکس و سپس ایجاد یک نشست ذخیره‌شدهٔ PuTTY که با آن ارتباط برقرار می‌کند، این کار را انجام دهید. یک راه جالب برای این کار، استفاده از نام توزیع WSL به عنوان «نام میزبان» (host name) است:
.IP "\fB\(bu\fP"
دستور پراکسی محلی را روی «\fBwsl -d %host /usr/local/bin/psusan\fP» (یا هر جا که \fBpsusan\fP را در سیستم لینوکس نصب کرده‌اید) تنظیم کنید
.IP "\fB\(bu\fP"
نام یک توزیع خاص WSL را در کادر نام میزبان (host name) وارد کنید. (برای مثال، اگر دبیان WSL را به روش استاندارد از فروشگاه ویندوز نصب کرده‌اید، این نام صرفاً «Debian» خواهد بود.)
.IP "\fB\(bu\fP"
مانند معمول، پروتکل را روی «Bare ssh-connection» قرار دهید.
.PP
مانند تمامی مثال‌های دیگر در اینجا، این روش نیز به شما اجازه می‌دهد پورت‌ها را به داخل و خارج محیط WSL فوروارد کنید (مثلاً در دسترس قرار دادن یک سرویس شبکه در WSL2 از طریق NAT داخلی هایپروایزر)، Pageant را به درون آن فوروارد نمایید، و موارد دیگر.
.SS "Cygwin"
.PP
یک محیط یونیکس‌مانند دیگر در ویندوز Cygwin است. این محیط همراه با برنامهٔ ترمینال گرافیکی اختصاصی خود، یعنی \fBmintty\fP (که بر حسب اتفاق، مشتقی از PuTTY است) عرضه می‌شود؛ اما اگر ترجیح می‌دهید از خود PuTTY برای تعامل با نشست‌های ترمینال Cygwin استفاده کنید، \fBpsusan\fP می‌تواند کمک کند.
.PP
برای این کار، ابتدا باید ابزارهای یونیکسیِ PuTTY را درون Cygwin بسازید (از طریق روش متداول \fBcmake\fP). سپس، فایل اجرایی \fBpsusan.exe\fP حاصل را در دایرکتوری \fB/bin\fP در Cygwin کپی کنید. (برای اینکه برنامه‌های غیر-Cygwin بتوانند آن را اجرا کنند، حتماً باید در این دایرکتوری باشد؛ در غیر این صورت هنگام راه‌اندازی قادر به یافتن DLL مربوط به Cygwin نخواهد بود.)
.PP
سپس نشست ذخیره‌شدهٔ PuTTY خود را به این صورت تنظیم کنید:
.IP "\fB\(bu\fP"
دستور پراکسی محلی را طوری تنظیم کنید که \fBpsusan.exe\fP را از طریق مسیر واقعی ویندوزی آن اجرا کند. همچنین ممکن است بخواهید گزینهٔ \fB--sessiondir\fP را اضافه کنید تا نشست‌های پوسته در دایرکتوری خانگی Cygwin شما شروع شوند. برای مثال، می‌توانید از دستور «\fBc:\ecygwin64\ebin\epsusan.exe --sessiondir /home/simon\fP» استفاده نمایید (مسیر فایل و نام کاربری را متناسب با سیستم خود تغییر دهید).
.IP "\fB\(bu\fP"
هر چیزی را که مایلید در کادر host name وارد کنید؛ «\fBCygwin\fP» احتمالاً انتخاب خوبی است
.IP "\fB\(bu\fP"
مانند معمول، پروتکل را روی «Bare ssh-connection» قرار دهید.
.PP
فوروارد پورت در این حالت کاربرد چندانی ندارد، زیرا Cygwin فضای پورت شبکه را با ماشین میزبان به اشتراک می‌گذارد. اما فعال کردن فوروارد کارگزار (agent forwarding) مفید است، زیرا کلاینت خط فرمانی SSH در Cygwin می‌تواند بدون هیچ پیکربندی اضافی با Pageant ارتباط برقرار کند.
.SS "\fBschroot\fP"
.PP
مثال دیگری از یک محیط کانتینرمانند، چیدمان سیستم فایل جایگزینی است که توسط \fBschroot\fP(\fI1\fP) ایجاد می‌شود.
.PP
\fBschroot\fP برنامهٔ دیگری است که به‌طور پیش‌فرض یک نشست پوستهٔ تعاملی را در ترمینالی که از آن اجرا شده به کار می‌اندازد. اما باز هم می‌توانید با راه‌اندازی یک نشست ذخیره‌شدهٔ PuTTY که دستور پراکسی محلی آن شبیه به زیر باشد، اتصالی از طریق \fBpsusan\fP به محیط \fBschroot\fP برقرار نمایید:
.PP
.nf
schroot\ \-c\ \fIchroot\-name\fP\ /\fIsome/path/to\fP/psusan
.fi
.PP
بسته به اینکه چه مقدار از محیط chroot از محیط اصلی شما کپی شده است، ممکن است متوجه شوید که این کار اموری نظیر اجرای برنامه‌های X11 را درون chroot که پنجره‌هایی روی نمایشگر اصلی X شما باز می‌کنند یا انتقال فایل‌ها به داخل و خارج chroot را ساده‌تر می‌سازد.
.SS "بین فضاهای نام شبکه (Between network namespaces)"
.PP
اگر چندین فضای نام شبکه (network namespaces) را با پیکربندی‌های مختلف TCP/IP روی یک سیستم لینوکس راه‌اندازی کرده‌اید، در صورتی که \fBpsusan\fP را به عنوان یک کاربر غیر ریشه (non-root) در فضای نامِ غیرپیش‌فرضِ خود اجرا کنید و به اتصالات روی یک سوکت دامنهٔ یونیکس گوش فرا دهد، می‌تواند یک درگاه ارتباطیِ مناسب و بدون نیاز به دسترسی‌های ویژه میان آن‌ها باشد.
.PP
اگر این کار را انجام دهید، کنترلی راحت روی این موضوع خواهید داشت که کدام اتصالات شبکهٔ خروجی شما از کدام پیکربندی TCP/IP استفاده کنند: می‌توانید در صورت نیاز به اجرای دستورهایی مانند \fBping\fP، از PuTTY برای اجرای یک نشست پوسته در بستر فضای نام دیگر استفاده کنید، یا اینکه فوروارد پورت‌های جداگانه یا حتی یک سرور SOCKS راه‌اندازی نمایید تا فرایندهایی که در یک فضای نام اجرا می‌شوند بتوانند اتصالات شبکهٔ خود را از طریق فضای نام دیگر برقرار کنند.
.PP
برای این کاربرد، احتمالاً راحت‌ترین کار استفاده از گزینهٔ \fB--listen\fP در \fBpsusan\fP است که باعث می‌شود برنامه به عنوان یک سرور اجرا شده و روی یک سوکت دامنهٔ یونیکس به اتصالات ورودی گوش دهد. سپس می‌توانید آن نام سوکت را در فیلد پیکربندی host name در PuTTY وارد کنید (و همچنان گزینهٔ پروتکل «Bare ssh-connection» را انتخاب نمایید) تا مانند یک کلاینت SSH به آن سوکت متصل شوید.
.PP
به شرطی که سوکت دامنهٔ یونیکس داخل دایرکتوری‌ای باشد که تنها کاربر مورد نظر به آن دسترسی دارد، این اطمینان حاصل می‌شود که احراز هویت به‌طور ضمنی توسط هستهٔ لینوکس صورت می‌گیرد.
.SS "بین شناسه‌های کاربری از طریق GNU userv (Between user ids, via GNU userv)"
.PP
اگر از چندین شناسهٔ کاربری روی یک ماشین استفاده می‌کنید، مثلاً برای اهداف جداسازی امتیازات (اجرای برنامه‌ای با قابلیت اطمینان کمتر و با دسترسی‌های محدود به تمام دارایی‌های شما)، در این صورت احتمالاً یک حساب کاربری «پیش‌فرض» یا دارای بالاترین امتیاز دارید که نشست ورود اصلی خود را در آن اجرا می‌کنید، و گاهی نیاز دارید که پوسته‌ای را در حسابی دیگر به کار بیندازید.
.PP
برنامهٔ \fBpsusan\fP می‌تواند با استفاده از GNU \fBuserv\fP(\fI1\fP) به عنوان بستر انتقال، به عنوان کانال دسترسی میان حساب‌ها به کار رود. در حسابی که می‌خواهید به آن دسترسی داشته باشید، یک بند پیکربندی \fBuserv\fP شبیه به زیر بنویسید:
.PP
.nf
if\ (glob\ service\ psusan\ &\ glob\ calling\-user\ \fImy\-main\-account\-name\fP)
\ \ \ reset
\ \ \ execute\ /\fIsome/path/to\fP/psusan
fi
.fi
.PP
این کار به حساب اصلی شما اجازه می‌دهد تا این دستور را اجرا کند:
.PP
.nf
userv\ \fImy\-sub\-account\-name\fP\ psusan
.fi
.PP
و می‌توانید آن نام دستور را درست مانند بیشتر مثال‌های قبلی، به عنوان یک دستور پراکسی محلی در PuTTY پیکربندی کنید.
.PP
البته در حال حاضر راه‌های فراوانی برای دسترسی از یک حساب محلی به حسابی دیگر مانند \fBsudo\fP وجود دارد. یکی از مزایای این روش این است که هنگام تمایل به تغییر کنترل‌های دسترسی (مثلاً تغییر اینکه کدام حساب‌های شما به حسابی دیگر دسترسی داشته باشند) نیازی به دخالت مدیر سیستم ندارید: تا زمانی که از ابتدا \fIروشی\fP برای ورود به هر حساب داشته باشید و \fBuserv\fP نصب باشد، می‌توانید بدون نیاز به ایجاد زحمت برای کاربر ریشه (root)، تغییرات پیکربندی بعدی را اعمال کنید.
.PP
مزیت دیگر این است که ممکن است انتقال فایل بین حساب‌ها را ساده‌تر کند. اگر از آن دسته افرادی هستید که دایرکتوری‌های خانگی خود را خصوصی نگه می‌دارند، کپی کردن یک فایل از یکی از حساب‌هایتان به دیگری تنها با استفاده از دستور \fBcp\fP دشوار خواهد بود، زیرا مکان مناسبی در یک حساب وجود ندارد که بتوانید فایل را در آن بگذارید تا حساب دیگر بتواند آن را بخواند. اما با \fBpsusan\fP روی بستر \fBuserv\fP، نیازی به هیچ بخش مشترکی از سیستم فایل ندارید: می‌توانید فایل‌ها را با \fBscp\fP بدون هیچ زحمتی جابه‌جا کنید.
.SH "گزینه‌ها (OPTIONS)"
.PP
گزینه‌های خط فرمان پشتیبانی‌شده توسط \fBpsusan\fP عبارتند از:
.IP "\fB--listen\fP \fIunix-socket-name\fP"
اجرای \fBpsusan\fP در حالت شنود. آرگومان \fIunix-socket-name\fP مسیر یک سوکت دامنهٔ یونیکس برای شنود است. باید اطمینان حاصل کنید که این مسیر درون دایرکتوری‌ای قرار دارد که مجوزهای خواندن و اجرای آن فقط به کاربری (یا کاربرانی) محدود است که می‌خواهید بتوانند به محیطی که \fBpsusan\fP در آن اجرا می‌شود دسترسی داشته باشند.
.RS
.PP
سوکت شنود باید یک سوکت دامنهٔ یونیکس باشد. برنامهٔ \fBpsusan\fP گزینه‌ای برای اجرا روی TCP/IP ارائه نمی‌دهد، زیرا ماهیت احراز هویت‌نشدهٔ این پروتکل آن را ذاتاً ناامن می‌سازد.
.RE
.IP "\fB--listen-once\fP"
در حالت شنود، این گزینه باعث می‌شود \fBpsusan\fP تنها برای یک اتصال به شنود بپردازد، و بلافاصله پس از پایان آن اتصال خاتمه یابد.
.IP "\fB--sessiondir\fP \fIpathname\fP"
این گزینه دایرکتوری‌ای را که نشست‌های پوسته و زیرفرایندها در آن شروع می‌شوند تعیین می‌کند. این مقدار به‌طور پیش‌فرض دایرکتوری کاریِ خودِ \fBpsusan\fP است، اما در برخی شرایط، تغییر آن با یک گزینهٔ خط فرمان آسان‌تر از قرار دادن \fBpsusan\fP درون اسکریپتی است که قبل از راه‌اندازی دایرکتوری را تغییر می‌دهد.
.IP "\fB-v\fP, \fB--verbose\fP"
این گزینه باعث می‌شود \fBpsusan\fP پیام‌های گزارش تفصیلی را روی خروجی خطای استاندارد خود چاپ کند. این گزینه احتمالاً در حالت شنود بیشترین کاربرد را دارد.
.IP "\fB\-sshlog\fP \fIlogfile\fP"

.IP "\fB\-sshrawlog\fP \fIlogfile\fP"
این گزینه‌ها باعث می‌شوند \fBpsusan\fP جزئیات پروتکل را در یک فایل ثبت کند، مشابه گزینه‌های ثبت گزارش در PuTTY و Plink.
.RS
.PP
گزینهٔ \fB\-sshlog\fP بسته‌های رمزگشایی‌شدهٔ SSH و سایر رویدادها (مواردی که \fB\-v\fP چاپ می‌کند) را ثبت می‌نماید. گزینهٔ \fB\-sshrawlog\fP علاوه بر آن، داده‌های خام ارتباطی، از جمله قالب بیرونی بسته‌ها و پیام‌های آغازین خوشامدگویی را ثبت می‌کند.
.RE