9.2. دسترسی از راه‌دور

اتصال به یک رایانه از راه‌دور برای مدیرسیستم یک امر ضروری است. سرورها، که در اتاق‌های جداگانه‌ای بدون صفحه‌کلید و نمایشگر قرار می‌گیرند - به شبکه متصل هستند.

بازگشت به مقدمات معماری کلاینت، سرور

سیستمی که در آن چندین فرآیند با یکدیگر در حال برقراری ارتباط هستند استعاره از “client/server” دارد. سرور برنامه‌ای است که به درخواست‌های دریافتی از کلایت پاسخ می‌دهد. این کلاینت است که عملیات را کنترل می‌کند، سرور هیچ عملیاتی را خود آعاز نمی‌کند.

9.2.1. ورود امن از راه‌دور: SSH

پروتکل SSH یا Secure SHell با توجه به اصول امنیتی و قابلیت اطمینان طراجی شده است. ارتباطاتی که از SSH استفاده می‌کنند امن هستند: طرف مقابل احراز هویت شده و تمام اطلاعات به صورت رمزگذاری شده ارسال می‌شوند.

واژگان احراز هویت، رمزنگاری

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

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

SSH همچنین تو سرویس انتقال فایل را ارائه می‌دهد. scp یک ابزار خط فرمان است که عملکردی مشابه cp دارد، به جز مسیرهای خارج از یک رایانه که باید ابتدا نام رایانه به همراه دو نقطه آورده شود.

$ scp file machine:/tmp/

sftp یک دستور تعاملی مشابه ftp است. در یک نشست واحد، sftp می‌تواند چندین فایل را منتقل کند و امکان ایجاد تغییرات در فایل‌های راه‌دور نیز وجود دارد (حذف، تغییر نام، تغییر مجوزها و از این قبیل).

دبیان از OpenSSH، یک نسخه آزاد از SSH که توسط پروژه OpenBSD مدیریت می‌شود (یک سیستم عامل آزاد مبتنی بر کرنل BSD با تمرکز بر امنیت) و انشعاب نسخه اصلی نرم‌افزار SSH که توسط شرکت SSH Communications Security Corp در فنلاند اداره می‌شد، استفاده می‌کند. این شرکت در ابتدا SSH را به عنوان نرم‌افزار آزاد منتشر کرد، اما در ادامه مسیر تصمیم گرفت تا توسعه آن را تحت یک مجوز انحصاری انجام دهد. پروژه OpenBSD با ایجاد OpenSSH تصمیم گرفت یا یک نسخه آزاد از آن ارائه دهد.

بازگشت به مقدمات Fork

یک “انشعاب”، در حوزه نرم‌افزار، به معنای پروژه جدیدی بر اساس پروژه فعلی است که با آن رقابت می‌کند. از آن زمان به بعد، هر دو نرم‌افزار رویکردهای متفاوتی در نسخه‌های جدید دارند. یک انشعاب معمولا ناشی از عدم تفاقق بین اعضای یک تیم توسعه نرم‌افزار است.

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

OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. احرازهویت کلید-محور

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

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

امنیت محافظت از کلید خصوصی

هر کسی که به کلید خصوصی دسترسی داشته باشد با حساب کاربری مربوط به آن می‌تواند وارد شود. به همین دلیل است که دسترسی به کلید خصوصی از طریق یک “گذزواژه” محافظت می‌شود. کسی که یک رونوشت از کلید خصوصی می‌گیرد (برای نمونه، ~/.ssh/id_rsa) هنوز باید به گذرواژه مخصوص آن دسترسی داشته باشد. این لایه حفاظتی اضافی نیز، اگرچه، رسوخ‌ناپذیر نیست و اگر فکر می‌کنید که کلید خصوصی شما آشکار شده است بهتر است تا مجوز دسترسی به آن روی رایانه‌های سرور را از بین ببرید (با حفظ کردن آن از فایل authorized_keys) و آن را با یک کلید جدید جایگزین کنید.

فرهنگ نقص OpenSSL در دبیان Etch

The OpenSSL library, as initially provided in Debian Etch, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like valgrind. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness.

→ https://www.debian.org/security/2008/dsa-1571

به خصوص، زمانی که OpenSSL برای تولید یک کلید استفاده می‌شد، همیشه کلیدی بین محدوده مشخصی از آن‌ها تولید می‌کرد (۳۲،۰۰۰ ضرب در تعداد کمی از طول کلید‌ها). این عملکرد روی کلیدهای SSH، کلیدهای SSL و گواهینامه‌های X.509 که توسط بسیاری برنامه‌ها مانند OpenVPN استفاده می‌شدند، تاثیر گذاشت. یک نفوذگر تنها می‌بایست تمام کلید‌های موجود در آن بازه را جهت دسترسی به سیستم پیدا کند. برای کاهش تاثیر این مشکل، فرآیند پس‌زمینه SSH طوری تغییر یافت تا کلیدهای دردسرساز فهرست شده در بسته‌های openssh-blacklist و openssh-blacklist-extra را رد کند. علاوه بر این، دستور ssh-vulnkey امکان شناسایی کلیدهای آشکارشده در سیستم را فراهم می‌کرد.

تحلیل بیشتر روی این موضوع نشان داد که مشکلات کوچک بیشتری در پروژه OpenSSL و نگهدارنده بسته دبیان آن وجود داشت. کتابخانه بزرگی مانند OpenSSL - بدون تغییر - نباید پس از آزمون با valgrind پیام‌های اخطار صادر کند. علاوه بر این، کد (به خصوص قسمت حساسی مانند RNG) باید با توضیحات بهتری از بروز چنین خطایی پیشگیری کند. در طرف دبیان، نگهدارنده بسته قصد داشت تا تغییرات مورد نظر خود را با توسعه‌دهندگان اصلی OpenSSL سازگار سازد، اما بدون ارايه فایل وصله مناسب و در جریان گذاشتن تیم اصلی از تغییرات انجام گرفته خارج از مسئولیت‌های پروژه دبیان اقدام کرد. در نهایت، راه‌حل‌های پیشنهادی خیلی بهینه نبودند: تغییرات ایجاد شده در کد اصلی به خوبی مستند نشده بود؛ تمام تغییرات در یک مخزن Subversion ذخیره شده بودند اما هنگام ایجاد بسته اصلی تنها به تولید یک فایل وصله انجامید.

It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian sources webservice were developed.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also قسمت 10.2.2, “زیرساخت کلید عمومی: easy-rsa” ) by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Both, public key and certificate authentication, can be used alongside each other.

9.2.1.3. استفاده راه‌دور از برنامه‌های X11

پروتکل SSH امکان فوروارد کردن داده‌های گرافیکی را می‌دهد (نشست “X11”، که از نام متداول‌ترین سیستم گرافیکی یونیکس گرفته شده است)؛ سرور یک کانال اختصاصی برای آن در نظر می‌گیرد. به خصوص، یک برنامه گرافیکی که از راه‌دور اجرا می‌شود می‌تواند روی سرور X.org سیستم محلی نمایش یابد و تمام نشست جاری (ورودی و نمایش) امن خواهد بود. از آنجا که این سیستم اجازه تداخل برنامه‌های راه‌دور با سیستم محلی را می‌دهد، به صورت پیش‌فرض غیرفعال است. می‌توانید با مشخص کردن X11Forwarding yes در فایل پیکربندی سرور (/etc/ssh/sshd_config) آن را فعال کنید. در نهایت، کاربر نیز هنگام درخواست ssh باید گزینه -X را بیان کند.

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

9.2.1.4. ایجاد تونل‌های رمزگذاری شده با پورت فورواردینگ

گزینه‌های -R و -L به ssh امکان ایجاد “تونل‌های رمزگذاری‌شده” بین دو رایانه را می‌دهند، که به تبع آن یک پورت TCP محلی (قسمت بازگشت به مقدمات TCP/UDP را مشاهده کنید) به شیوه‌ای امن می‌تواند به یک ماشین راه‌دور فوروارد شود یا بر عکس.

واژگان تونل

اینترنت، و اکثر شبکه‌های محلی متصل به آن، در حالت بسته‌ای کار می‌کنند نه متصل، به این معنی که بسته ارسال شده از یک رایانه در مسیر خود چندین رایانه دیگر (مسیریاب) را طی می‌کند تا در نهایت به مقصد برسد. می‌توانید عملیات اتصال را طوری شبیه‌سازی کنید که در آن جریان داده در بسته‌های نرمال IP ذخیره شده باشد. این بسته‌ها از مسیرهای خود طبعیت می‌کنند، اما جریان داده در انتهای مسیر بدون تغییر باقی می‌ماند. ما به این فرآیند یک “تونل” می‌گوییم، مشابه با یک تونل در دنیای واقعی که در آن خودروها از سمت ورودی (input) به خروجی (output) حرکت می‌کنند بدون اینکه مسیرشان تغییر کند، بر خلاف یک مسیر معمولی که ممکن است شامل تقاطع‌های متفاوت باشد.

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

دستور ssh -L 8000:server:25 intermediary یک نشست SSH با میزان intermediary برقرار کرده و به پورت محلی ۸۰۰۰ گوش می‌دهد ( شكل 9.3, “فوروارد کردن یک پورت محلی با SSH” را مشاهده کنید). برای هر ارتباطی که روی این پورت برقرار شود، ssh یک ارتباط میانی از رایانه intermediary با پورت ۲۵ روی server برقرار کرده و هر دو ارتباط را به یکدیگر متصل می‌کند.

دستور ssh -R 8000:server:25 intermediary نیز یک نشست SSH با رایانه intermediary برقرار می‌کند، اما روی این رایانه است که ssh به پورت ۸۰۰۰ ( شكل 9.4, “فوروارد کردن یک پورت راه‌دور با SSH” را مشاهده کنید) گوش می‌دهد. هر ارتباطی که روی این پورت برقرار شود ssh یک ارتباط با پورت ۲۵ server برقرار کرده و هر دو ارتباط را به یکدیگر متصل می‌کند.

در هر دو مورد، ارتباطات با پورت ۲۵ میزان server برقرار شد، که جریان داده آن از طریق تونل SSH بین سیستم محلی و سیستم intermediary می‌گذرد. در مورد اول، ورودی تونل پورت ۸۰۰۰ محلی است و داده قبل از اینکه به server در شبکه “عمومی” برسد از طریق رایانه intermediary می‌گذرد. در مورد دوم، ورودی و خروجی تونل برعکس شده است؛ ورودی پورت ۸۰۰۰ از رایانه intermediary است و خروجی روی سیستم محلی قرار دارد و جریان داده به این شکل به server هدایت می‌شود. در عمل، سرور همان سیستم محلی یا میانی است. به این شیوه SSH می‌تواند ارتباط امنی بین هر دو رایانه برقرار کند.

شكل 9.3. فوروارد کردن یک پورت محلی با SSH

شكل 9.4. فوروارد کردن یک پورت راه‌دور با SSH

9.2.2. استفاده از میزکارهای گرافیکی راه‌دور

VNC یا Virtual Network Computing اجازه دسترسی راه‌دور به میزکارهای گرافیکی را می‌دهد.

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

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

امنیت VNC همراه با SSH

اگر قصد استفاده از VNC در حالت امن و رمزنگاری شده را دارید، امکان ذخیره‌سازی داده در یک تونل SSH وجود دارد ( قسمت 9.2.1.4, “ایجاد تونل‌های رمزگذاری شده با پورت فورواردینگ” را مشاهده کنید). تنها کافی است بدانید که VNC به صورت پیش‌فرض از پورت ۵۹۰۰ برای نمایشگر اول (که “localhost:0” خوانده می‌شود)، ۵۹۰۱ برای نمایشگر دوم (که “localhost:1” خوانده می‌شود) و به همین ترتیب استفاده می‌کند.

دستور ssh -L localhost:5901:localhost:5900 -N -T machine یک تونل بین پورت ۵۹۰۱ محلی در رابط شبکه localhost و پورت ۵۹۰۰ از میزبان machine ایجاد می‌کند. اولین “localhost” به SSH می‌گوید که تنها روی این رابط شبکه از رایانه محلی متمرکز باشد. دومین “localhost” نشان‌دهنده رابط شبکه رایانه راه‌دور است که ترافیک دریافتی را از طریق “localhost:5901” می‌فرستد. بنابراین vncviewer localhost:1 کلایت VNC را به نمایشگر راه‌دور متصل کرده، با اینکه نام رایانه محلی را ذکر کرده‌اید.

زمانی که نشست VNC به پایان رسید به یاد داشته باشید که باید نشست SSH مربوط به آن را نیز خاتمه دهید.