9.2. تسجيل الدخول عن بعد

الاتصال بالحاسوب عن بعد أمر أساسي لأي مدير نظام. فالمخدمات، المحتجزة في غرفها الخاصة، نادراً ما تزود بلوحة مفاتيح وشاشة دائمتين — بل توصل بالشبكة.

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 is an interactive command, similar to ftp. In a single session, sftp can transfer several files, and it is possible to manipulate remote files with it (delete, rename, change permissions, etc.). Many FTP clients, including filezilla, support it.

تستخدم دبيان OpenSSH، وهو نسخة حرة من SSH يشرف عليها مشروع OpenBSD (نظام تشغيل حر يعتمد على النواة BSD، ويركز على الأمن) مشتقة من برنامج SSH الأصلي الذي طورته شركة SSH Communication Security Corp الفنلندية. لقد طورت هذه الشركة SSH بشكل برنامج حر في البداية، لكن قررت لاحقاً متابعة تطويره تحت رخصة احتكارية. بعد ذلك أنشأ مشروع OpenBSD المشتق OpenSSH لمتابعة صيانة نسخة حرة من SSH.

أساسيات مشتق

”المشتق“ (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 كثيراً. لذلك يقدم 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 في دبيان إيتش

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 لتوليد مفتاح، كانت تولد دوماً مفتاحاً ينتمي لمجموعة معروفة من بضعة مئات آلاف المفاتيح (32,000 مضروبة بعدد صغير من أطوال المفاتيح). أثر هذا على مفاتيح SSH، ومفاتيح SSL، وشهادات X.509 التي تستخدمها العديد من التطبيقات، مثل OpenVPN. كان كل ما يحتاجه المخترق هو تجربة جميع المفاتيح حتى يتمكن من الدخول غير المصرح به. لتخفيف ضرر المشكلة، تم تعديل خدمة SSH بحيث ترفض المفاتيح المشكوك بها المذكورة في الحزمتين openssh-blacklist وopenssh-blacklist-extra. بالإضافة لذلك، يسمح الأمر ssh-vulnkey بالتعرف على المفاتيح في النظام التي يحتمل أنها مفضوحة.

بيّنت التحليلات الأكثر تعمقاً أن هذه الحادثة كانت نتيجة عدة مشاكل (صغيرة)، جزء منها يقع على عاتق مشروع OpenSSH، والجزء الآخر على عاتق مشرف الحزمة في مشروع دبيان. يجب ألا تولد مكتبة منتشرة الاستخدام مثل 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. Combining authentication methods

Besides the already mentioned password based, key based, and the certificate based authentication, other methods like using a TOTP exist as well. Not only is this an abundance of options. They can also be combined. On the server side, the AuthenticationMethods directive can define an order of authentication methods a user has to successfully pass, before they are allowed to enter the system. It is even possible to define multiple alternative sequences:

AuthenticationMethods publickey,password publickey,keyboard-interactive:pam

This setting, for example, allows users to login after initially completing the public key authentication, followed by either a successful password authentication or entering a valid TOTP set up via PAM. On the user side, the sequence of methods can be defined using the PreferredAuthentications directive.

9.2.1.4. استخدام تطبيقات X11 عن بعد

The SSH protocol allows forwarding of graphical data (“X11” session, from the name of the most widespread graphical system in Unix); the server then keeps a dedicated channel for those data. Specifically, a graphical program executed remotely can be displayed on the X.org server of the local screen, and the whole session (input and display) will be secure. Since this feature allows remote applications to interfere with the local system, it is disabled by default. You can enable it by specifying X11Forwarding yes in the server configuration file sshd_config(5) or by prepending the public key with the X11-forwarding keyword in the authorized_keys(5) file. Finally, the user must also request it by adding the -X option to the ssh command-line.

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.5. إنشاء الأنفاق المشفرة باستخدام توجيه المنافذ

يسمح الخياران -R و-L للأمر ssh بإنشاء ”أنفاق مشفرة“ بين جهازين، باستخدام التوجيه الآمن لمنفذ TCP محلي (انظر الملاحظة الجانبية أساسيات TCP/UDP) إلى جهاز بعيد أو العكس.

مصطلحات نفق

تعمل شبكة الإنترنت، ومعظم الشبكات المحلية المتصلة بها، في وضع الرزم (packet mode) وليس وضع الاتصال (connected mode)، وهذا يعني أن الرزمة التي تنطلق من حاسوب إلى آخر سوف تتوقف عند العديد من الموجهات الوسيطة حتى تعثر على الطريق إلى وجهتها. لا تزال محاكاة وضع العمل المتصل ممكنة حيث يُغلَّف تيار المعلومات (stream) في رزم IP عادية. تتبع هذه الرزم طريقها المعتاد، لكن يعاد بناء التيار كما هو عند الوجهة. يدعى هذا ”بالنفق“، مثل نفق السيارات حيث تسير فيه المركبات مباشرة من المدخل (input) إلى المخرج (output) دون المرور بأي تقاطعات، بخلاف الطرقات على سطح الأرض التي تحوي العديد من التقاطعات وتغييرات الاتجاه.

يمكنك الاستفادة من هذه الفرصة لتشفير النفق: عندئذ لن يمكن التعرف على التيار الذي يجري عبره من الخارج، لكن يعاد التيار إلى الشكل غير المشفر عند الخروج من النفق.

ينشئ الأمر ssh -L 8000:server:25 intermediary جلسة SSH مع المضيف intermediary وينصت للمنفذ المحلي 8000 (انظر شكل 9.3, “توجيه منفذ محلي باستخدام SSH”). في كل مرة ينشأ فيها اتصالاً مع هذا المنفذ، سيفتح ssh اتصالاً من الحاسوب intermediary إلى المنفذ 25 على server، وسيربط الاتصالين معاً.

أما الأمر ssh -R 8000:server:25 intermediary فهو ينشئ جلسة SSH أيضاً مع الحاسوب intermediary، لكن سوف ينصت ssh للمنفذ 8000 على ذلك الجهاز (انظر شكل 9.4, “توجيه منفذ بعيد باستخدام SSH”). أي اتصال يرد إلى إلى هذا المنفذ سيجعل ssh يفتح اتصالاً من الجهاز المحلي إلى المنفذ 25 على server، ويربط الاتصالين معاً.

في كلا الحالتين، يكون الاتصال مع المنفذ 25 على المضيف server، بعد أن يمر خلال نفق SSH الواصل بين الجهاز المحلي والجهاز intermediary. في الحالة الأولى، مدخل النفق هو المنفذ المحلي 8000، وتتحرك البيانات باتجاه الجهاز intermediary قبل أن تتوجه إلى server عبر الشبكة ”العامة“. أما في الحالة الثانية، فقد تبدل موقعي الدخل والخرج في النفق؛ فقد أصبح المدخل هو المنفذ 8000 على الجهاز intermediary، أما المخرج فهو على الجهاز المحلي، الذي يوجه البيانات بعدها إلى server. عملياً، إما أن يكون 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.5, “إنشاء الأنفاق المشفرة باستخدام توجيه المنافذ”). عليك فقط أن تعرف أن VNC يستخدم المنفذ 5900 افتراضياً للشاشة الأولى (التي تدعى ”localhost:0“)، و 5901 للشاشة الثانية (وتدعى ”localhost:1“)، الخ.

ينشئ الأمر ssh -L localhost:5901:localhost:5900 -N -T machine نفقاً بين المنفذ المحلي 5901 في الواجهة الشبكية المحلية والمنفذ 5900 على المستضيف machine. كلمة ”localhost“ الأولى تقيّد SSH حتى ينصت فقط إلى تلك الواجهة على الجهاز المحلي. أما كلمة ”localhost“ الثانية فهي تشير إلى الواجهة على الجهاز البعيد التي ستستقبل بيانات الشبكة الداخلة إلى ”localhost:5901“. وهكذا سوف يصل الأمر vncviewer localhost:1 عميل VNC مع الشاشة البعيدة، رغم أن الأمر يشير إلى اسم الجهاز المحلي.

لا تنسَ إغلاق النفق عند إغلاق جلسة VNC، عبر الخروج من جلسة SSH المفتوحة من هذا الطرف.