SSHUTTLE(1) sshuttle SSHUTTLE(1)

sshuttle - ایجاد اتصال VPN از طریق SSH

sshuttle [options] -r [username@]sshserver[:port] <subnets ...>

دستور sshuttle به شما اجازه می‌دهد تا از رایانه خود به هر سرور دوری که امکان اتصال از طریق ssh به آن وجود دارد یک اتصال VPN برقرار کنید، مادامی که روی آن سرور نسخه به اندازه کافی جدیدی از Python نصب باشد.

برای کارکرد این ابزار، داشتن دسترسی ریشه (root) روی رایانه محلی الزامی است، اما روی سرور داشتن یک حساب کاربری عادی کافی خواهد بود.

اجرای هم‌زمان بیش از یک نمونه از sshuttle بر روی یک رایانه کارخواه (کلاینت) و اتصال هر بار به یک سرور مجزا کاملاً معتبر است؛ بنابراین می‌توانید در آنِ واحد به بیش از یک VPN متصل باشید.

اگر sshuttle بر روی یک مسیریاب (روتر) اجرا شود، می‌تواند ترافیک تمام زیرشبکه (subnet) شما را به VPN بازفرستد.

<subnets>
فهرستی از زیرشبکه‌ها برای مسیریابی از طریق VPN، به فرم a.b.c.d[/width][port[-port]]. نمونه‌های معتبر عبارتند از 1.2.3.4 (یک آدرس IP تکی) و 1.2.3.4/32 (معادل با 1.2.3.4)، 1.2.3.0/24 (یک زیرشبکه ۲۴ بیتی، یعنی با ماسک شبکه 255.255.255.0). برای تطابق با تمام آدرس‌های IPv4 زیرشبکه 0/0 و برای تطابق با تمام آدرس‌های IPv6 زیرشبکه ::/0 را مشخص کنید. هر یک از نمونه‌های پیشین در صورت افزودن یک درگاه یا بازه‌ای از درگاه‌ها نیز معتبر هستند؛ بنابراین 1.2.3.4:8000 تنها ترافیکی را تونل می‌کند که درگاه مقصد آن 8000 از آدرس 1.2.3.4 باشد و 1.2.3.0/24:8000-9000 ترافیک ارسالی به هر درگاهی بین 8000 تا 9000 (شامل هر دو) را برای تمام IPهای موجود در زیرشبکه 1.2.3.0/24 تونل خواهد کرد. به جای آدرس IP می‌توان یک نام میزبان وارد کرد. اگر نام میزبان به چندین IP ترجمه شود، تمامی آن IPها لحاظ می‌شوند. اگر به همراه نام میزبان یک پهنا (width) مشخص شود، آن پهنا به تمامی IPهای آن نام میزبان (در صورتی که همگی یا IPv4 و یا IPv6 باشند) اعمال می‌گردد. نمی‌توان پهنا را برای نام‌های میزبانی که هم به IPv4 و هم به IPv6 ترجمه می‌شوند مشخص کرد. نمونه‌های معتبر عبارتند از example.com، example.com:8000، example.com/24، example.com/24:8000 و example.com:8000-9000.
کدام روش دیوار آتش (firewall) باید توسط sshuttle استفاده شود؟ برای auto، برنامه sshuttle تلاش می‌کند تا با توجه به آنچه در PATH می‌یابد، روش مناسب را حدس بزند. مقدار پیش‌فرض auto است.
استفاده از این آدرس ip و شماره درگاه به عنوان درگاه پروکسی شفاف (transparent proxy). به‌طور پیش‌فرض sshuttle به‌طور خودکار یک درگاه در دسترس پیدا کرده و روی IP 127.0.0.1 (localhost) گوش می‌دهد، بنابراین نیازی به بازنویسی آن ندارید و اتصالات تنها از رایانه محلی پروکسی می‌شوند، نه از رایانه‌های بیرونی. اگر می‌خواهید اتصالات را از سایر رایانه‌های موجود در شبکه خود بپذیرید (یعنی برای اجرای sshuttle روی یک مسیریاب)، فعال‌سازی IP Forwarding در هسته سیستم را بررسی کرده و سپس از --listen 0.0.0.0:0 استفاده کنید. می‌توانید از هر نامی که به یک آدرس IP رایانه اجراکننده sshuttle ترجمه می‌شود استفاده کنید، مانند --listen localhost.

برای روش‌های nft، tproxy و pf این مقدار می‌تواند یک آدرس IPv6 باشد. در صورت نیاز، از این گزینه با مقادیر جداشده با کاما استفاده کنید تا هم آدرس IPv4 و هم IPv6 مشخص شوند، مانند --listen 127.0.0.1:0,[::1]:0.

پویش برای یافتن نام‌های میزبان دوردست و به‌روزرسانی فایل محلی /etc/hosts با مدخل‌های منطبق تا زمانی که اتصال VPN برقرار است. این روش به چند دلیل از تغییر تنظیمات DNS سیستم (/etc/resolv.conf) بهتر است. اول اینکه نام‌های میزبان بدون پسوند نام دامنه اضافه می‌شوند، بنابراین می‌توانید بدون نگرانی از تطابق دامنه محلی با دامنه دوردست، دستور ssh thatserver را اجرا کنید. دوم اینکه اگر هم‌زمان با sshuttle به بیش از یک VPN متصل شوید، در هر صورت استفاده هم‌زمان از بیش از یک سرور DNS غیرممکن است، اما sshuttle مدخل‌های /etc/hosts را به‌درستی بین تمام نمونه‌های در حال اجرا ترکیب (merge) می‌کند. سوم اینکه اگر تنها تعداد کمی زیرشبکه را از طریق VPN مسیریابی می‌کنید، احتمالاً ترجیح می‌دهید برای بقیه موارد همچنان از سرور DNS محلی خود استفاده کنید.

برنامه sshuttle تلاش می‌کند یک نسخه حافظه نهان (cache) از نام‌های میزبان را در فایل ~/.sshuttle.hosts روی میزبان دوردست ذخیره کند. همچنین، زمانی که بعداً با فعال بودن --auto-hosts مجدداً به میزبان متصل شوید، تلاش می‌کند این فایل را بخواند تا فهرست میزبان‌ها را به‌سرعت بارگذاری کند. هنگام عیب‌یابی این ویژگی، حذف این فایل را در میزبان دوردست در زمانی که sshuttle در حال اجرا نیست بررسی کنید.

علاوه بر زیرشبکه‌های ارائه‌شده در خط فرمان، از سرور پرسیده می‌شود که فکر می‌کند کدام زیرشبکه‌ها باید مسیریابی شوند و آن‌ها را به‌طور خودکار مسیریابی می‌کند. این پیشنهادها به‌طور خودکار از جدول مسیریابی (routing table) سرور دریافت می‌شوند.

این ویژگی مسیرهای IPv6 را تشخیص نمی‌دهد. زیرشبکه‌های IPv6 را به‌صورت دستی مشخص کنید. برای نمونه، زیرشبکه ::/0 را در خط فرمان تعیین کنید تا تمام ترافیک IPv6 مسیریابی شود.

رهگیری درخواست‌های DNS محلی و بازفرستادن آن‌ها به سرور DNS دوردست. تمام پرس‌وجوها به هر یک از سرورهای DNS سیستم محلی (/etc/resolv.conf و، در صورت وجود، /run/systemd/resolve/resolv.conf) رهگیری شده و در عوض در سمت دوردست تونل حل‌وفصل می‌شوند؛ در آنجا در صورت مشخص شدن، از DNS تعیین‌شده با گزینه --to-ns استفاده می‌شود. تنها ترافیک عادی DNS که به درگاه 53 این سرورها ارسال می‌شود رهگیری می‌گردد.
رهگیری درخواست‌های DNS محلی ارسالی به سرور(های) مشخص‌شده و بازفرستادن آن‌ها به سرور DNS دوردست. برخلاف گزینه --dns، این پرچم اجازه می‌دهد سرور(های) DNS که پرس‌وجوهای ارسالی به آن‌ها باید رهگیری شوند را مشخص کنید، به جای آنکه تمام ترافیک DNS رایانه محلی رهگیری شود. این مورد می‌تواند زمانی مفید باشد که تنها درخواست‌های DNS خاصی باید در سمت دوردست تونل حل‌وفصل شوند، مثلاً در ترکیب با dnsmasq.
سرور DNS برای ارسال درخواست‌ها به آن در زمانی که حل‌وفصل نام دوردست فعال است. اگر تعیین نشود، sshuttle به سادگی با استفاده از تحلیل‌گر پیکربندی‌شده سیستم در سمت دوردست (از طریق /etc/resolv.conf سمت دوردست) درخواست‌ها را حل‌وفصل خواهد کرد.
نام یا مسیر مفسر python در سیستم دوردست را مشخص می‌کند. پیش‌فرض استفاده از python3 (یا python، در صورت عدم موفقیت python3) در PATH سیستم دوردست است.
نام میزبان دوردست و در صورت تمایل نام کاربری و شماره درگاه ssh برای اتصال به سرور دوردست. برای نمونه، example.com،‏ <testuser@example.com>،‏ <testuser@example.com>:2222 یا example.com:2244. این نام میزبان به ssh تحویل داده می‌شود، بنابراین هر نام مستعار (alias) و تنظیمی را که در ~/.ssh/config پیکربندی کرده باشید شناسایی خواهد کرد.
-x <subnet>, --exclude=<subnet> صریحاً این زیرشبکه را از بازفرستادن (forwarding) مستثنی می‌کند. قالب این گزینه مشابه گزینهٔ <subnets> است. برای مستثنی کردن بیش از یک زیرشبکه، گزینهٔ -x را بیش از یک بار مشخص کنید. به عنوان مثال، می‌توانید عبارتی مانند 0/0 -x 1.2.3.0/24 را مشخص کنید تا همه چیز به جز زیرشبکهٔ محلی از طریق VPN هدایت شود.
زیرشبکه‌های مشخص‌شده در یک فایل را مستثنی می‌کند، یک زیرشبکه در هر خط. زمانی که زیرشبکه‌های زیادی برای مستثنی کردن دارید مفید است.
اطلاعات بیشتری دربارهٔ نشست چاپ می‌کند. این گزینه می‌تواند برای افزایش پرگویی بیش از یک بار استفاده شود. به طور پیش‌فرض، sshuttle فقط پیام‌های خطا را چاپ می‌کند.
دستوری که برای اتصال به کارساز دوردست استفاده می‌شود. مقدار پیش‌فرض فقط ssh است. اگر کلاینت ssh شما در مکانی غیر استاندارد قرار دارد یا می‌خواهید گزینه‌های اضافی به دستور ssh بدهید، از این گزینه استفاده کنید؛ برای مثال، -e 'ssh -v'.
برای مقصدهای ویندوزی (Windows)، برنامهٔ پوستهٔ دوردستِ پیکربندی‌شده‌ای را به عنوان جایگزین پوستهٔ استاندارد posix مشخص می‌کند. مقدار آن معمولاً cmd یا powershell خواهد بود، مگر اینکه چیزی مانند git-bash در حال استفاده باشد.
پیش از فراخوانی پایتون روی میزبان دوردست، حائل خط تیرهٔ دوتایی (--) را اضافه نمی‌کند. این گزینه زمانی مفید است که دستور ssh استفاده‌شده برای اتصال، یک دستور سفارشی باشد که این حائل را به درستی تفسیر نمی‌کند.
فهرستی از نام‌های میزبان که با کاما از هم جدا شده‌اند برای مقداردهی اولیه به الگوریتم پویش --auto-hosts. گزینهٔ --auto-hosts کارهایی مانند بررسی خروجی netstat برای دریافت فهرست نام‌های میزبان محلی را انجام می‌دهد، اما اگر با این گزینه چند نام برای شروع به آن بدهید، می‌تواند سرعت کار را افزایش دهد.

اگر این گزینه بدون --auto-hosts استفاده شود، نام‌های میزبان فهرست‌شده پویش و اضافه می‌شوند، اما نام میزبان دیگری اضافه نخواهد شد.

تأخیر (latency) را فدای بهبود معیارهای پهنای باند می‌کند. ssh از بافرهای سوکت بسیار بزرگی استفاده می‌کند که اگر شروع به انتقال فایل‌های حجیم کنید، می‌تواند اتصال را بیش از حد بارگذاری کند و در نتیجه تمام نشست‌های دیگر شما درون همان تونل کند شوند. به طور معمول، sshuttle سعی می‌کند با استفاده از یک «بررسی پر بودن» ("fullness check") که فقط اجازه می‌دهد مقدار معینی از داده‌های معلق در یک زمان بافر شوند، از این مشکل جلوگیری کند. اما در پیوندهای با پهنای باند بالا، این کار ممکن است باعث شود بخش زیادی از پهنای باند شما استفاده‌نشده باقی بماند. همچنین باعث می‌شود sshuttle در آزمون‌های ارزیابی پهنای باند کند به نظر برسد (آزمون‌های ارزیابی به‌ندرت تأخیر پینگ را که sshuttle تلاش در واپایش آن دارد، می‌سنجند). این گزینه قابلیت واپایش تأخیر را غیرفعال کرده و بهره‌برداری از پهنای باند را به حداکثر می‌رساند. با مسئولیت خودتان استفاده کنید.
اندازهٔ بافر استفاده‌شده در واپایش تأخیر را تنظیم می‌کند. مقدار پیش‌فرض 32768 است. تغییر این گزینه امکان مصالحه بین تأخیر و پهنای باند را بدون غیرفعال‌سازی کامل واپایش تأخیر (توسط --no-latency-control) فراهم می‌کند.
پس از اتصال به کارساز دوردست، به طور خودکار به پس‌زمینه منشعب (fork) می‌شود. متضمن --syslog است.
زیرشبکه‌های مشخص‌شده در یک فایل را به جای خط فرمان لحاظ می‌کند؛ یک زیرشبکه در هر خط.
پس از اتصال، تمام پیام‌های گزارش را به جای stderr به سرویس syslog(3) ارسال می‌کند. در صورت استفاده از --daemon این حالت ضمنی است.
هنگام استفاده از --daemon، شناسهٔ فرایند (pid) مربوط به sshuttle را در pidfilename ذخیره می‌کند. مقدار پیش‌فرض sshuttle.pid در دایرکتوری فعلی است.
پشتیبانی از IPv6 را برای روش‌هایی که از آن پشتیبانی می‌کنند (nat، nft، tproxy و pf) غیرفعال می‌کند.
(فقط استفادهٔ داخلی) مدیر دیوار آتش (firewall manager) را اجرا می‌کند. این تنها بخشی از sshuttle است که باید به عنوان کاربر ریشه (root) اجرا شود. اگر sshuttle را به عنوان کاربری غیر از root اجرا کنید، به طور خودکار sudo یا su را برای راه‌اندازی مدیر دیوار آتش اجرا می‌کند، اما هستهٔ اصلی sshuttle همچنان به عنوان یک کاربر عادی اجرا می‌شود.
(فقط استفادهٔ داخلی) دیمن hostwatch را اجرا می‌کند. این فرایند در سمت کارساز اجرا می‌شود و نام‌های میزبان را برای گزینهٔ --auto-hosts جمع‌آوری می‌کند. استفاده از این گزینه به تنهایی، اشکال‌زدایی و آزمایش قابلیت --auto-hosts را بسیار آسان‌تر می‌کند.
دستور sshuttle پیکربندی خاصی را در خروجی استاندارد چاپ می‌کند که به کاربر اجازه می‌دهد sshuttle را بدون گذرواژه اجرا کند. این گزینه ناامن (INSECURE) است زیرا با کمی زیرکی، به کاربر اجازه می‌دهد تا هر دستوری را به عنوان کاربر ریشه بدون گذرواژه اجرا کند. خروجی همچنین شامل یک روش پیشنهادی برای نصب پیکربندی است.

برای تغییر کاربری که این پیکربندی روی آن اعمال می‌شود، از --sudoers-user استفاده کنید.

نام کاربر یا گروه را با %group_name برای عملیات بدون گذرواژه تعیین می‌کند. مقدار پیش‌فرض کاربر فعلی است. برای همهٔ کاربران مقدار آن را روی ALL تنظیم کنید (توصیه نمی‌شود: یادداشت مربوط به امنیت در مستندات --sudoers-no-modify در بالا را ببینید). فقط با گزینهٔ --sudoers-no-modify کار می‌کند.
گزینه‌ای که توسط روش tproxy استفاده می‌شود: از نشان (mark) ترافیک مشخص‌شده استفاده می‌کند. نشان باید یک مقدار هگزادسیمال باشد. پیش‌فرض 0x01 است.
نسخهٔ برنامه را چاپ می‌کند.

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

برای اجرای sshuttle با گزینه‌های تعریف‌شده در مثلاً /etc/sshuttle.conf، تنها کافی است مسیر فایل را به‌همراه نویسهٔ @ در ابتدای آن ارسال کنید؛ مانند @/etc/sshuttle.conf.

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

آرگومان‌های خوانده‌شده از فایل باید مطابق نمونهٔ زیر، در هر سطر یکی باشند:

value
--option1
value1
--option2
value2

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

# company-internal API
8.8.8.8/32
# home IoT
192.168.63.0/24

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

برای نمونه:

SSHUTTLE_ARGS="-e 'ssh -v' --dns" sshuttle -r example.com 0/0

از دستور زیر برای هدایت تمام ترافیک TCP در IPv4 از طریق میزبان دوردست (-r) example.com (و احتمالاً ترافیک‌های دیگر، بسته به --method انتخابی) استفاده کنید. زیرشبکهٔ 0/0 که کوته‌نوشت 0.0.0.0/0 است، با تمام نشانی‌های IPv4 مطابقت دارد. زیرشبکهٔ ::/0 نیز که با تمامی نشانی‌های IPv6 مطابقت دارد، می‌تواند به مثال افزوده شود. ما همچنین example.com:22 را مستثنی (-x) می‌کنیم تا بتوانیم اتصال‌های ssh را از دستگاه محلی به میزبان دوردست بدون هدایت شدن از طریق sshuttle برقرار کنیم. مستثنی کردن میزبان دوردست ممکن است در برخی ماشین‌ها برای کارکرد درست sshuttle ضروری باشد. برای خروج کلید‌های Ctrl+C را فشار دهید. برای هدایت پرس‌وجوهای DNS از طریق sshuttle، افزودن --dns را امتحان کنید. برای مشاهدهٔ اطلاعات بیشتر یا کمتر، گزینه‌های -v را اضافه یا حذف کنید:

$ sshuttle -r example.com -x example.com:22 0/0
Starting sshuttle proxy (version ...).
[local sudo] Password:
fw: Starting firewall with Python version 3.9.5
fw: ready method name nat.
c : IPv6 disabled since it isn't supported by method nat.
c : Method: nat
c : IPv4: on
c : IPv6: off (not available with nat method)
c : UDP : off (not available with nat method)
c : DNS : off (available)
c : User: off (available)
c : Subnets to forward through remote host (type, IP, cidr mask width, startPort, endPort):
c :   (<AddressFamily.AF_INET: 2>, '0.0.0.0', 0, 0, 0)
c : Subnets to exclude from forwarding:
c :   (<AddressFamily.AF_INET: 2>, '...', 32, 22, 22)
c :   (<AddressFamily.AF_INET: 2>, '127.0.0.1', 32, 0, 0)
c : TCP redirector listening on ('127.0.0.1', 12299).
c : Starting client with Python version 3.9.5
c : Connecting to server...
user@example.com's password:
 s: Starting server with Python version 3.6.8
 s: latency control setting = True
 s: auto-nets:False
c : Connected to server.
fw: setting up.
fw: iptables -w -t nat -N sshuttle-12299
fw: iptables -w -t nat -F sshuttle-12299
...
Accept: 192.168.42.121:60554 -> 77.141.99.22:22.
^C
c : Keyboard interrupt: exiting.
c : SW'unknown':Mux#1: deleting (1 remain)
c : SW#7:192.168.42.121:60554: deleting (0 remain)

اتصال به یک سرور دوردست، با حدس خودکار نام میزبان و زیرشبکه:

$ sshuttle -vNHr example.com -x example.com:22
Starting sshuttle proxy (version ...).
[local sudo] Password:
fw: Starting firewall with Python version 3.9.5
fw: ready method name nat.
c : IPv6 disabled since it isn't supported by method nat.
c : Method: nat
c : IPv4: on
c : IPv6: off (not available with nat method)
c : UDP : off (not available with nat method)
c : DNS : off (available)
c : User: off (available)
c : Subnets to forward through remote host (type, IP, cidr mask width, startPort, endPort):
c : NOTE: Additional subnets to forward may be added below by --auto-nets.
c : Subnets to exclude from forwarding:
c :   (<AddressFamily.AF_INET: 2>, '...', 32, 22, 22)
c :   (<AddressFamily.AF_INET: 2>, '127.0.0.1', 32, 0, 0)
c : TCP redirector listening on ('127.0.0.1', 12300).
c : Starting client with Python version 3.9.5
c : Connecting to server...
user@example.com's password:
 s: Starting server with Python version 3.6.8
 s: latency control setting = True
 s: auto-nets:True
c : Connected to server.
c : seed_hosts: []
 s: available routes:
 s:   77.141.99.0/24
fw: setting up.
fw: iptables -w -t nat -N sshuttle-12300
fw: iptables -w -t nat -F sshuttle-12300
...
c : Accept: 192.168.42.121:60554 -> 77.141.99.22:22.
^C
c : Keyboard interrupt: exiting.
c : SW'unknown':Mux#1: deleting (1 remain)
c : SW#7:192.168.42.121:60554: deleting (0 remain)

اجرای sshuttle با فایل پیکربندی /etc/sshuttle.conf:

$ sshuttle @/etc/sshuttle.conf

استفاده از گزینه‌های تعریف‌شده در /etc/sshuttle.conf ولی با خروجی پرجزئیات‌تر:

$ sshuttle @/etc/sshuttle.conf -vvv

جایگزینی سرور دوردستِ تعریف‌شده در /etc/sshuttle.conf:

$ sshuttle @/etc/sshuttle.conf -r otheruser@test.example.com

نمونه فایل پیکربندی:

192.168.0.0/16
--remote
user@example.com

هنگام شروع، sshuttle یک نشست ssh با سرور مشخص‌شده توسط گزینه -r ایجاد می‌کند.

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

برخلاف بیشتر VPNها، sshuttle نشست‌ها را هدایت می‌کند، نه بسته‌ها را. بدین معنا که از پروکسی شفاف هسته (قوانین iptables REDIRECT در لینوکس) برای دریافت نشست‌های خروجی TCP استفاده کرده، سپس نشست‌های TCP کاملاً مجزایی را به سمت مقصد اصلی در سوی دیگر تونل ایجاد می‌کند.

هدایت در سطح بسته (مانند استفاده از دستگاه‌های tun/tap در لینوکس) در نگاه اول ایده‌آل به نظر می‌رسد، اما به چندین مشکل می‌انجامد، به‌ویژه مشکل 'tcp over tcp'. پروتکل tcp اساساً برای پیاده‌سازی الگوریتم کنترل ازدحام خود به دور انداخته شدن بسته‌ها وابسته است؛ اگر بسته‌های tcp را از یک تونل مبتنی بر tcp (مانند ssh) عبور دهید، بسته‌های درونی tcp هرگز دور انداخته نخواهند شد، و در نتیجه کنترل ازدحام جریان درونی tcp کاملاً از کار می‌افتد و کارایی به شدت افت خواهد کرد. از این رو، VPNهای مبتنی بر بسته (مانند IPsec و openvpn) نمی‌توانند از جریان‌های رمزگذاری‌شده مبتنی بر tcp مانند ssh یا ssl استفاده کنند و مجبورند رمزگذاری خود را از پایه پیاده‌سازی نمایند، که بسیار پیچیده و مستعد خطا است.

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

همچنین ببینید:

ssh(1)، python(1)

Brian May

2016, Brian May

December 14, 2025 1.3