يعد بروتوكول النقل الآمن Secure Shell، أو SSH اختصارًا، إحدى الأدوات الأساسية التي يجب على مسؤول النظام إتقانها، حيث يستخدم لتسجيل الدخول الآمن إلى الأجهزة البعيدة عن طريق الطرفية أو سطر الأوامر، وهو من أكثر الطرق شيوعًا للوصول إلى خوادم لينكس، وستتعلم في هذا المقال كيفية التعامل مع بروتوكول SSH للاتصال بنظام بعيد خطوة بخطوة.

العمل على نظام تشغيل ويندوز Windows

إذا كنا نستخدم نظام التشغيل ويندوز على جهازنا، فسنحتاج إلى تثبيت إحدى إصدارات برنامج OpenSSH لنتمكن من استخدام الأمر ssh من سطر الأوامر. أما إن فضّلنا العمل في برنامج PowerShell، فيمكن قراءة توثيقات مايكروسوفت لإضافة OpenSSH إلى PowerShell. أما في حال العمل في بيئة لينكس Linux كاملة، فيمكن إعداد WSL -أي نظام ويندوز الفرعي لنظام لينكس Windows Subsystem for Linux- وهو طبقة توافق لتشغيل أنظمة لينكس داخل أنظمة ويندوز، مما يتيح لنا تشغيل طرفية حقيقية مباشرةً في نظام ويندوز دون الحاجة لآلة افتراضية ويتضمن الأمر ssh. وأخيرًا، يمكننا تثبيت Git على نظام ويندوز، والذي يوفر طرفية Bash أصلية تتضمن أيضًا الأمر ssh. فجميع هذه البيئات الثلاثة مدعومة والخيار متروك لكم في العمل مع إحداها حسب ما تفضلونه.

العمل على نظام تشغيل لينكس Linux أو ماك Mac

إن كنا نستخدم نظام لينكس أو ماك فسيكون الأمر ssh جاهزًا في الطرفية، وفيما يلي صيغته الأساسية:

ssh remote_host

remote_host هو عنوان IP أو اسم النطاق domain الذي نريد الاتصال به.

يفترض الأمر السابق أن اسم المستخدم على النظام البعيد هو نفس اسم المستخدم على نظامنا المحلي، أما إن كان اسم المستخدم مختلفًا، فيمكننا تحديده باستخدام الأمر التالي:

ssh remote_username@remote_host

قد يُطلب منا إدخال كلمة مرور للاتصال بالخادم، وسنتحدث لاحقًا عن كيفية استخدام مفاتيح المصادقة المشفرة keys بدل كلمات المرور passwords.

نستخدم الأمر التالي للخروج من جلسة SSH والعودة إلى الصدفة:

Exit

آلية عمل بروتوكول SSH

يعمل بروتوكول SSH عن طريق توصيل برنامج عميل client program يسمى sshd مع خادم ssh، فبالعودة إلى مثالنا السابق، فإن ssh هو بمثابة برنامج العميل، أما خادم ssh فيعمل على الجهاز البعيد remote host الذي حددناه. يجب أن يبدأ خادم sshd بالعمل تلقائيًا في معظم بيئات لينكس. وإذا لم يعمل لسبب ما، فقد نحتاج إلى الوصول إلى الخادم من خلال إحدى طرفيّات المتصفح المعتمدة على الويب web-based console، أوالطرفيّة المحلية local serial console.

يعتمد الأمر اللازم لتشغيل خادم ssh على توزيعة لينكس التي نستخدمها، فعند استخدام توزيعة أوبنتو، يمكننا تشغيل الأمر التالي:

sudo systemctl start ssh

يُشغّل الأمر السابق خادم sshd وبإمكاننا الآن تسجيل الدخول إلى الخادم عن بعد.

كيفية ضبط إعدادات بروتوكول SSH

عندما نغيّر إعدادات بروتوكول SSH فإننا نغيّر أيضًا إعدادات خادم sshd. سنجد ملف الإعدادات ضمن المسار /etc/ssh/sshd_config. ومن الضروري أخذ نسخة احتياطيةً عن هذا الملف قبل بدء التعديل، باستخدام الأمر التالي:

sudo cp /etc/ssh/sshd_config{,.bak}

ثم نفتحه باستخدام محرر النصوص nano أو أي محرر آخر:

sudo nano /etc/ssh/sshd_config

لنطلع على بعض خيارات الملف:

Port 22

عند الإعلان عن منفذ جديد port declaration فإننا نحدد المنفذ الذي سيستخدمه خادم sshd للاتصال، والمنفذ الافتراضي لذلك هو 22. يُفضّل ألا نغيّر هذا الإعداد، إلا إن كان لدينا سبب لذلك. وسنوضح لاحقًا كيفية الاتصال بالمنفذ الجديد.

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

عند الإعلان عن مفاتيح المضيف host keys فإننا نحدد مكان البحث عن مفاتيح المضيف العامة global host keys. وسنتحدث عن ذلك لاحقًا.

SyslogFacility AUTH
LogLevel INFO

يحدد العنصران السابقان مستوى التسجيل logging level. إذ قد تكون زيادة التسجيل طريقة جيدة لاكتشاف المشكلات في SSH:

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

تحدد المعاملات السابقة بعض معلومات تسجيل الدخول:

• يحدد المعامل LoginGraceTime عدد الثواني إبقاء الاتصال قبل تسجيل الدخول، ويُنصح أن نجعل هذا الوقت أكثر بقليل من الوقت اللازم لتسجيل الدخول عادة
• يحدد المعامل PermitRootLogin هل يُسمح للمستخدم الجذر تسجيل الدخول أم لا، ويجب في معظم الحالات ضبط هذا الإعداد على الخيار no عند إنشاء مستخدم لديه امتيازات الجذر لتقليل خطر حصول أي شخص على امتيازات الجذر والوصول إلى خادمنا
• المعامل strictModes هو حارس أمان لا يسمح بتسجيل الدخول إذا كانت ملفات المصادقة متاحة القراءة للجميع. وهذا يمنع تسجيل الدخول عندما تكون ملفات الإعدادات غير آمنة

X11Forwarding yes
X11DisplayOffset 10

• تضبط هذه المعاملات خاصيةً تسمى X11 Forwarding تتيح لنا عرض واجهة المستخدم الرسومية GUI للنظام البعيد على النظام المحلي، ويجب تفعيل هذا الخيار على الخادم واستخدامه مع عميل SSH أثناء الاتصال مصحوبًا بالخيار x-.

بعد التعديل على الملف نحفظه ثم نغلقه. وإن كنا نستخدم محرر النصوص nano، نضغط على المفتاحين Ctrl+X، ثم Y عندما يُطلب منا ذلك، ثم نضغط على مفتاح Enter. ولا ننسى إعادة تحميل خادم sshd لتنفيذ التعديلات التي أجريناها في الملف باستخدام الأمر التالي:

sudo systemctl reload ssh

يجب اختبار التعديلات بدقة للتأكد أنها تعمل كما يجب. كما يمكننا فتح بضع جلسات في الطرفية أثناء التعديل على ملف الإعدادات، لإلغاء التعديلات إن لزم الأمر دون الحاجة إلى إعادة تسجيل الدخول.

تسجيل الدخول إلى SSH باستخدام مفاتيح المصادقة Keys

يُنصح لتسجيل الدخول إلى نظام بعيد استخدام كلمات المرور passwords أو مفاتيح المصادقة keys والتي تتصف بأنها أسرع وأكثر أمانًا من كلمات المرور.

آلية عمل المصادقة المعتمدة على المفاتيح

تعمل المصادقة المعتمدة على مفاتيح المصادقة عن طريق إنشاء زوج من المفاتيح: مفتاح خاص private key ومفتاح عام public key. يوجد المفتاح الخاص على جهاز العميل وهو سرّي، أما المفتاح العام فيمكن إعطاؤه لأي شخص أو وضعه على أي خادم نرغب الوصول إليه.

عندما نحاول الاتصال باستخدام زوج من المفاتيح، نستخدم الخادم المفتاح العام لإنشاء رسالة محمية لحاسوب العميل لا يمكن قراءتها إلا باستخدام المفتاح الخاص. بعد ذلك، يرسل حاسوب العميل الاستجابة المناسبة إلى الخادم وسيعرف الخادم أن العميل يُسمح له بالاتصال. تُنفَّذ هذه العملية تلقائيًا بعد ضبط إعدادات المفاتيح.

كيفية إنشاء مفاتيح المصادقة في بروتوكول SSH

يجب إنشاء مفاتيح المصادقة في بروتوكول SSH على الحاسوب الذي سنسجل الدخول منه، أي جهازنا المحلي. نكتب ما يلي في سطر الأوامر:

ssh-keygen -t rsa

قد يُطلب منا تعيين كلمة مرور على ملفات المفاتيح نفسها، ولكن هذا الأمر غير شائع. يجب الضغط على مفتاح Enter لقبول الإعدادات الافتراضية. وستُنشأ المفاتيح في المجلد ‎~/.ssh/id_rsa.pub و المجلد ‎~/.ssh/id_rsa.

نغيّر مكان إنشاء المفاتيح إلى المجلد ‎.sshباستخدام الأمر التالي:

cd ~/.ssh

نستعرض سماحيات الملف باستخدام الأمر:

ls -l

وسنحصل على الخرج التالي:

-rw-r--r-- 1 demo demo  807 Sep  9 22:15 authorized_keys
-rw------- 1 demo demo 1679 Sep  9 23:13 id_rsa
-rw-r--r-- 1 demo demo  396 Sep  9 23:13 id_rsa.pub

نلاحظ أن الملف id_rsa قابل القراءة والكتابة بواسطة المالك فقط، مما يساعد على إبقاء الملف سريًّا. أما الملف id_rsa.pub فيمكن مشاركته وله سماحيات تمكّن ذلك.

نقل المفاتيح العامة إلى الخادم

إن فعّلنا الوصول إلى الخادم باستخدام كلمة المرور، فبإمكاننا نسخ مفتاح المرور العام إلى الخادم باستخدام الأمر التالي:

ssh-copy-id remote_host

سيؤدي الأمر إلى إنشاء جلسة SSH، وبعد إدخال كلمة المرور، سيُنسخ المفتاح العام إلى ملف المفاتيح المعتمدة authorized keys في الخادم، مما يسمح لنا بتسجيل الدخول دون كلمة المرور في المرة القادمة.

الخيارات المتاحة لعميل SSH

هناك خيارات عدة عند الاتصال عبر بروتوكول SSH، بعضها قد يكون ضروريًا لمطابقة الإعدادات الموجودة في sshd عند المضيف البعيد remote host. مثلًا، إذا غيّرنا رقم المنفذ في إعدادات sshd، فعلينا تغييره عند العميل باستخدام الأمر التالي:

ssh -p port_number remote_host

ملاحظة:: يُعدَ تغيير منفذ بروتوكول ssh طريقةً مناسبةً لزيادة الأمان، فإذا كنا نسمح بالاتصال بخادم معروف عبر بروتوكول ssh على المنفذ 22 كالمعتاد، ووضعنا كلمة مرور، فمن المحتمل أن نتعرض لمحاولات تسجيل دخول آلية عديدة automated logins. لكن، لا يُعدّ استخدام مفاتيح المصادقة وتشغيل بروتوكول ssh على منفذ غير المنفذ المعتاد الحل الأمني الأمثل، ولكنه يفيد في الحد من الهجمات الآلية.

إذا أردنا تنفيذ أمر واحد فقط على النظام البعيد، فيمكن تحديده بعد المضيف، كما يلي:

ssh remote_host command_to_run

سنتصل بالنظام البعيد وسيُنَفذ الأمر بعد إدخال مفتاح المرور. إن كانت خاصية X11 Forwarding مفعلةً على كلا الجهازين، فيمكننا تفعيل ميزاتها باستخدام الأمر التالي:

ssh -X remote_host

بشرط توفر الأدوات المناسبة لذلك على حاسوبنا، فبرامج واجهة المستخدم الرسومية التي نستخدمها على النظام البعيد ستُشَغّل الآن على نظامنا المحلي.

إلغاء التحقق من كلمة المرور

يمكن عند إنشاء مفاتيح SSH، تحسين أمان الخادم وتعطيل مصادقة كلمة المرور، وتمكين تسجيل الدخول إلى الخادم من خلال المفتاح الخاص المقترن بالمفتاح العام الذي نبّته على الخادم.

تنبيه: قبل متابعة هذه الخطوة، يتوجب التأكد من تثبيت مفتاح عام على الخادم. وإلا لن نستطيع تسجيل الدخول!

نفتح ملف إعدادات sshd كمستخدم مسؤول root user أو أو مستخدم يتمتع بامتيازات sudo باستخدام الأمر التالي:

sudo nano /etc/ssh/sshd_config

نبحث عن سطر Password Authentication ثم نزيل التعليق عنه بمسح رمز #، ونغيّر قيمته إلى القيمة no:

PasswordAuthentication no

أما الخيار PubkeyAuthentication و ChallengeResponseAuthentication فلا يحتاجان إلى تعديل، شريطة ألا نكون عدلنا هذا الملف، إذ يجب تركهما على الضبط الإفتراضي:

PubkeyAuthentication yes
ChallengeResponseAuthentication no

نحفظ الملف ونغلقه بعد الانتهاء من التعديلات. ثم نعيد تحميل برنامج ssh:

sudo systemctl reload ssh

وبهكذا نكون قد ألغينا التحقق من كلمة المرور، وفعّلنا خيار الوصول إلى الخادم حصرًا عبر مفتاح SSH.

الخاتمة

شرحنا في هذا المقال كيفية استخدام بروتوكول SSH وهو أمر مفيد جدًا في مجال الحوسبة السحابية، وسنحتاج أثناء استخدام الخيارات المتنوعة مزيدًا من الميزات المتقدمة التي من شأنها تسهيل عملنا. لهذا بقي بروتوكول SSH شائع الاستخدام لأنه آمن وصغير الحجم ومفيد في الكثير من الحالات.

ترجمة ، وبتصرّف، للمقال How To Use SSH to Connect to a Remote Server لكاتبه Justin Ellingwood.

اقرأ أيضًا

• ما هي تقنية SSH؟
• أنفاق SSH، ماهيتها وكيفية إعدادها
• كيفيّة منع SSH من فصل الجلسات
• مدخل إلى طرفيّة لينكس Linux Terminal

في هذا الفيديو نشرح بروتوكول SSH وآلية عمله وأماكن استخدامه، حيث أن بروتوكول SSH شائع جدًا وله استخدامات عديدة في مجالات مختلفة، خصوصًا في مجالات الحماية والأمان حيث يستخدم لجعل الاتصالات آمنة سواء عبر المصداقة بكلمة السر أو بالمفاتيح.

إذا أردت التعرف أكثر على علوم الحاسوب، فننصحك بالانضمام إلى دورة علوم الحاسوب، ولا تنسَ الاستعانة خلال رحلة تعلمك وعملك بتوثيقات موسوعة حسوب المجانية. وإذا أردت متابعة المعلومات البرمجية العلمية مكتوبة فيمكنك الاطلاع على قسم البرمجة في أكاديمية حسوب، كما يمكنك متابعة جديد الفيديوهات التقنية المتاحة على يوتيوب أكاديمية حسوب مجانًا.

يوجد ثابتان تستطيع تعريفهما في ملف wp-config.php لتفعيل "طبقة المقابس الآمنة" Secure Socket Layer اختصارًا SSL من أجل الاتصال بموقعك وإدارته والتحكم به بأمان. لا يكفي أن تعرف هذين المتغيرين ضمن ملف إضافة ما بل يجب تعريفهما ضمن ملف wp-config.php ويجب أن تضبط مسبقًا SSL على خادمك قبل أن يعمل موقعك بسلاسة مع هذين المتحولين عند ضبط قيمتهما للقيمة True.

اقتباس

ملاحظة: توقف استخدام الثابت FORCE_SSL_LOGIN في الإصدار 4.0 من ووردبريس. من فضلك استخدم الثابت FORCE_SSL_ADMIN.

فرض تسجيل الدخول والوصول للوحة التحكم باستخدام SSL

يُمكن ضبط الثابت FORCE_SSL_ADMIN إلى القيمة True ضمن الملف wp-config.php لإجبار إتمام جلسات المدير وجميع عمليات تسجيل الدخول عبر SSL.

define('FORCE_SSL_ADMIN', true);

استخدام خادم وكيل

إن كان موقع ووردبريس مُستضافًا خلف خادم وكيل عكسي reverse proxy يوفر SSL لكن الموقع نفسه مُستضاف بدون SSL، سوف تُسبب هذه الإعدادات حلقة إعادة توجيه غير منتهية للطلبات، ولتجنب ذلك يجب عليك ضبط ووردبريس ليتعرف على ترويسة HTTP_X_FORWARDED_PROTO (على فرض أنك ضبطت الخادم الوكيل بشكل صحيح لضبط هذه الترويسة).

انظر مثلًا:

define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';

ضبط SSL لحالات مخصصة ولإصدارات ووردبريس قديمة

تتضمن بقية هذا المقال معلومات مخصصةً لمن يستخدم إصدارًا قديمًا من ووردبريس (يجب عليك التحديث لآخر إصدار) أو في حال كان تثبيت SSL لديك مختلف (مثلًا شهادة SSL لنطاق مختلف).

تريد أحيانًا أن تعمل صفحة wp-admin بكاملها ضمن اتصال آمن باستخدام بروتوكول https حيث أن آلية العمل كالتالي:

1. اضبط استضافتين افتراضيتين Virtual Host بنفس الرابط (رابط المدونة) أحدهما آمن والآخر ليس آمنًا.
2. ضمن الاستضافة الافتراضية المؤمنة عليك ضبط قواعد إعادة الكتابة التي توجه الزيارات لصفحات الموقع الغير إدارية إلى الموقع غير المؤمن.
3. ضمن الاستضافة الافتراضية غير المؤمنة عليك ضبط قواعد إعادة الكتابة التي توجه زيارات صفحات المدير إلى الاستضافة المؤمنة.
4. عليك استخدام مرشح (استخدم إضافة) يعمل على انتخاب الروابط ضمن صفحات المدير وعند تفعيله يُعيد كتابة روابط صفحات المدير باستخدام https وهذا يُغير ملفات تعريف الارتباط لتعمل فقط مع الاتصالات المُشفرة.

إن المحتوى التعليمي التالي مُخصص للإصدار 1.5 من ووردبريس وخادم Apache الذي يُفعل وحدة mod_rewrite باستخدام قواعد إعادة الكتابة في ملف httpd.conf الذي يُمكن تعديله بسهولة ليتناسب مع خيارات الاستضافة الأخرى.

الاستضافات الافتراضية

تحتاج استضافةً افتراضيةً مُعدّةً للخادم المؤمن إضافةً إلى موقع غير مؤمن، وفي هذا المثال فإن الاستضافة الافتراضية المؤمنة تستخدم نفس المسار الرئيسي للاستضافة غير المؤمنة، وافتراضيًا تستطيع استخدام استضافة باسم مختلف مثل wpadmin.mysite.com وربطها مع المسار الرئيسي للخادم.

اطلب من فضلك من مزود الخدمة لديك ضبط استضافة افتراضية مؤمنة أو إن كان لديك تحكم كامل بالاستضافة تستطيع ضبطها بنفسك. انتبه أنك لا تستطيع استخدام استضافة افتراضية معتمدةً على الاسم لتعريف خوادم SSL مختلفة.

قواعد إعادة الكتابة للاستضافة غير المؤمنة

أضف القاعدة التالية ضمن ملف ‎.htaccess أو ملف httpd.conf لتوجيهك تلقائيًا للاستضافة المؤمنة عند تصفح الرابط http://mysite.com/wp-admin أو http://mysite.com/wp-login.php.

يجب أن تُضيف القواعد قبل كتلة قواعد ووردبريس:

 RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
  RewriteCond %{HTTPS} !=on [NC]
  RewriteRule ^/?(wp-admin/|wp-login\.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

إن كنت تستخدم قواعد إعادة الكتابة للروابط الدائمة عندها يجب أن يرد هذا السطر قبلها:

RewriteRule ^.*$ - [S=40]‎

إن استخدام THE_REQUEST أمر مهم جدًا لأنه يضمن إعادة كتابة فقط طلبات http.

قواعد إعادة الكتابة للاستضافة المؤمنة (اختياري)

قواعد إعادة الكتابة هذه اختيارية فهي تعطل الوصول العلني للموقع عبر اتصال مؤمن، وإن كنت تريد البقاء مُسجلًا دخولك للقسم العام من موقعك باستخدام الإضافة في الأسفل يجب ألا تُضيف هذه القواعد لأن الإضافة تُعطل ملفات تعريف الارتباط ضمن الاتصالات غير المشفرة.

يجب أن تمتلك الاستضافة الافتراضية المؤمنة قاعدتين ضمن ملف ‎.htaccess أو ضمن ملف تعريف الاستضافة الافتراضية (ألق نظرة على كيفية استخدام الروابط الدائمة لمزيد من المعلومات حول قواعد إعادة الكتابة):

RewriteRule !^/wp-admin/(.*) - [C]
   RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]

تستثني القاعدة الأولى مسار wp-admin من القاعدة الثانية التي توجه زيارات الموقع المؤمن إلى الموقع غير المؤمن للحفاظ على تجربة مريحة للمستخدم.

ضبط رابط ووردبريس

لكي تعمل بعض إضافات ووردبريس ولأسباب أخرى أيضًا عليك ضبط رابط ووردبريس ضمن الخيارات ليستخدم بروتوكول https، وذلك من خلال ضبط الرابط على الشكل التالي https://mysite.com. يجب ألا تُغير رابط المدونة.

إليك مثال عن ضبط Stanzas:

<VirtualHost nnn.nnn.nnn.nnn:443>
        ServerName www.mysite.com

        SSLEngine On
        SSLCertificateFile    /etc/apache2/ssl/thissite.crt
        SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

        DocumentRoot /var/www/mysite

        <IfModule mod_rewrite.c>
                RewriteEngine On
                RewriteRule !^/wp-(admin|includes)/(.*) - [C]
                RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
        </IfModule>
        ...
</VirtualHost>

# Insecure site
<VirtualHost *>
        ServerName www.mysite.com

        DocumentRoot /var/www/ii/mysite

        <Directory /var/www/ii/mysite >
                <IfModule mod_rewrite.c>
                        RewriteEngine On
                        RewriteBase /
                        RewriteCond %{REQUEST_FILENAME} -f [OR]
                        RewriteCond %{REQUEST_FILENAME} -d
                        RewriteRule ^wp-admin/(.*) https://www.mysite.com/wp-admin/$1 [C]
                        RewriteRule ^.*$ - [S=40]
                        RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
                        ...
                </IfModule>
         </Directory>
         ...
</VirtualHost>

ملاحظة: الإعدادات التالية غير متوافقة 100% مع إصدار ووردبريس 2.8 وما بعده حيث يستخدم ووردبريس 2.8 ملفات من مجلد wp-includes. يُمكن أن تُسبب إعادة التوجيه التي تنفذها أول مجموعة من القواعد بعض التحذيرات الأمنية لبعض المستخدمين. ألق نظرةً على الرابط لمزيد من المعلومات.

قواعد إعادة الكتابة لتسجيل الدخول والتسجيل

إن استخدام SSL للتسجيل بالموقع ولمن أنشأ حسابه في أو سجل دخوله إلى الموقع أمر جيد، لذا عليك الاطلاع على قواعد إعادة الكتابة التالية.

مثال غير مؤمن:

RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]

مثال مؤمن:

RewriteRule !^/wp-(admin|login|register)(.*) - [C]

قواعد إعادة الكتابة لتشغيل الموقع على المنفذ 443 أو المنفذ 80

انظر مثال قواعد إعادة الكتابة لتشغيل الموقع على المنفذ 443 أو المنفذ 80:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# For a site running on port 443 or else (http over ssl)
RewriteCond %{SERVER_PORT}  !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ http://%{SERVER_NAME}/$1 [L]

# For a site running on port 80 (http)
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]

RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

الملخص

هذه الطريقة لا تُصلح المشاكل الأمنية المتأصلة في ووردبريس ولا تحميك ضد هجوم رجل في الوسط man-in-the-middle attacks أو من أي مخاطر أخرى يُمكن أن توقف الاتصال المؤمن لكنها تُصعب على المخترقين سرقة ملفات تعريف الارتباط و/أو ترويسة التحقق لاستخدامها وانتحال شخصيتك والدخول للموقع إلى لوحة التحكم، كما أنها تُضعف قدرة المهاجم على الاطلاع على محتواك وهو أمر مهم للمدونات القانونية التي تتضمن مسودات تحتاج حماية صارمة.

التحقق

تُشير السجلات ضمن الخادم إلى أن جميع طلبات GET و POST تعمل ضمن اتصال SSL وجميع الزيارات للوحة تحكم ووردبريس للاستضافة غير المؤمنة توجه إلى الاستضافة المؤمنة.

عينة من سجل POST:

[Thu Apr 28 09:34:33 2005] [info] Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] "POST /wp-admin/post.php HTTP/1.1" 302 - "https://foo.com/wp-admin/post.php?acti
on=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

تستطيع التأكد بمزيد من الاختبارات باستخدام أدوات تحليل للشبكة ومتتبع رزم.

القيود

يفترض الكاتب أنه إن خزّن المستخدم ملفات تعريف الارتباط ضمن متصفحه ليتذكر كلمة المرور (غير معتمد على حقول النموذج إنما عند استخدام طرق تحقق خارجية) ثم زار الرابط http://mysite.com/wp-admin سوف تُرسل الحزم دون تشفير ويُمكن اعتراض ترويسة التحقق وملفات تعريف الارتباط، لذلك ولضمان أعلى درجة أمان يجب على المستخدم استخدام https أو الدخول دائمًا عند بداية كل جلسة.

ترجمة -وبتصرف- للمقال Administration Over SSL من موقع ووردبريس.

اقرأ أيضًا

• هل ووردبريس آمن؟
• إدارة ووردبريس وتسجيلات الدخول بأمان
• كيفية تثبيت شهادة SSL من سلطة شهادات تجارية: المفاهيم الأساسية
• استبدال روابط الصور على مواقع ووردبريس بعد تثبيت شهادة SSL

يشرح هذا المقال حالات استخدام أنفاق SSH مع أمثلة على ذلك، كما يوضح تدفق البيانات بصريًا. حيث يُبين الشكل أدناه مثلًا نفقًا عكسيًا يسمح لمستخدمي عنوان IP محدد (1.2.3.4) بالوصول إلى المنفذ 80 في عميل SSH عبر خادم SSH.

أنفاق SSH هي اتصالات مُعماة (خَفيَّة) تَستخدم بروتوكول TCP بين عميل SSH، وخوادم تسمح بدخول البيانات من جانب واحد من النفق، لتخرج بشفافية وموثوقية من المنفذ الآخر. لقد أُستخدم هذا المصطلح سابقًا لوصف التنفيق عبر واجهات شبكات TUN/TAP الافتراضية لكنه الآن يُشير إلى إعادة توجيه منفذ SSH أي SSH port forwarding، وتتضمن حالات استخدامه النقاط التالية:

• توفير قنوات مُشفّرة لحماية البروتوكولات التي تستخدِم نصوصًا غير مُشفرة.
• فتح أبواب خلفية إلى شبكات خاصة.
• تجاوز الجدران النارية.

إعادة توجيه المنفذ

نقصد بمصطلح إعادة توجيه المنفذ Port forwarding، عملية توجيه حركة البيانات من منفذ ما إلى آخر سواءً كان المنفذ موجود على خادم محلي أو بعيد.

إعادة التوجيه إلى منفذ محلي

تتيح لك إعادة توجيه المنفذ المحلي، إمكانية التحكم في حركة البيانات في عميل SSH وتوجيهه إلى هدف ما من خلال خادم SSH. حيث يسمح لك ذلك بالوصول إلى الخدمات البعيدة باستخدام اتصالات مُشفرة كما لو كانت خدمات محلية. وفي مثال على تلك الحالات الآتية:

• الوصول إلى خدمات بعيدة، مثل: redis، وmemcached وغيرها، والاستجابة لاتصالات IP الداخلية.
• الوصول إلى الموارد المحلية والمتاحة في شبكة الاتصال الخاصة.
• إنشاء توكيلات لطلبات اتصال إلى خدمة بعيدة بشفافية وموثوقية.

إعادة التوجيه إلى منفذ بعيد

تسمح لك عملية إعادة توجيه المنفذ البعيد بالتحكم في حركة البيانات على خادم SSH وتوجيهها إلى منفذ مُحدد، عبر عميل SSH أو خادم بعيد آخر. وهكذا يستطيع مستخدمو الشبكات العامة الوصول إلى الموارد الموجودة في الشبكات الخاصة، وفي مثال على ذلك ما يأتي:

• إتاحة الوصول إلى خادم تطوير ما على شبكة عامة.
• السماح لعنوان IP محدد بالوصول إلى الموارد البعيدة والموجودة على شبكة خاصة.

إعادة توجيه المنفذ الديناميكي

تعتمد عملية إعادة التوجيه الديناميكية على فتح وكيل بروكسي SOCKS في عميل SSH، وذلك للسماح بإعادة توجيه تدفق بيانات TCP عبر خادم SSH إلى خادم بعيد.

إعادة التوجيه من منافذ مميزة

إذا أردت فتح منفذ مميز (أي منفذ من 1 إلى 1023) لإعادة توجيه حركة البيانات، فستحتاج إلى تشغيل بروتوكول SSH مستخدمًا صلاحيات الجذر في النظام الذي تستعمله لفتح ذلك المنفذ كما يوضح المثال التالي:

sudo ssh -L 80:example.com:80 ssh-server

وسوم سطر أوامر SSH

هذه هي بعض رايات سطر أوامر SSH المُفيدة والتي يمكنك استخدامها عند إنشاء أنفاق SSH:

• ‎-f يُنشئ فرعًا من عملية SSH في الخلفية.
• ‎-n يمنع إمكانية القراءة من تيارات الإدخال المُوحّد STDIN.
• ‎-N يمنع تشغيل الأوامر البعيدة ويُستخدم فقط عند إعادة توجيه المنافذ.
• ‎-T يُعطل توزيع أوامر أنظمة يونكس TTY.

يوضح الاستعلام التالي كيفية إنشاء نفق SSH في الخلفية يعمل على إعادة توجيه منفذ محلي عبر خادم SSH:

ssh -fnNT -L 127.0.0.1:8080:example.org:80

سنتجاهل استخدام الرايات سابقة الذكر خلال الأمثلة التالية بهدف الإيجاز.

إعادة توجيه المنفذ المحلي

نعني بإعادة توجيه المنفذ المحلي، عملية إعادة توجيه الاتصالات من منفذ على نظام محلِّي إلى منفذ على خادم بعيد:

ssh -L 127.0.0.1:8080:example.org:80 ssh-server

يُعيد الاستعلام أعلاه توجيه الاتصالات لعنوان 127.0.0.1:8080 في نظامك المحلي إلى منفذ 80 الخاص بعنوان example.org، وذلك عبر خادم SSH. في هذا المثال سيُغلف نفق SSH تدفق البيانات بين نظامك المحلي وخادم SSH، لكن ذلك لا ينطبق على حركة البيانات بين خادم SSH وعنوان example.org. أي أنه من منظور example.org، فإن مصدر حركة البيانات الواردة هو خادم SSH.

ssh -L 8080:example.org:80 ssh-server

ssh -L *:8080:example.org:80 ssh-server

يُعيد هذا المثال توجيه الاتصالات إلى منفذ 8080 في جميع واجهات نظامك المحلي إلى example.org:80 عبر نفق إلى خادم SSH:

ssh -L 192.168.0.1:5432:127.0.0.1:5432 ssh-server

يُعيد المثال الموضح أعلاه توجيه الاتصالات الواردة إلى عنوان 192.168.0.1:5432 في نظامك المحلي، إلى عنوان 127.0.0.1:5432 في خادم SSH. لاحظ أن عنوان 127.0.0.1 هنا يمثل الخادم المحلي من وجهة نظر خادم SSH.

إعدادات خادم SSH

مع أن الإعدادات الافتراضية تكون مناسبةً عادةً، لكن تأكد من تفعيل تحويل اتصالات TCP في خادم SSH على كل حال.

AllowTcpForwarding yes

إذا كنت تُجرى عملية إعادة توجيه المنافذ في واجهات بخلاف 127.0.0.1، فستحتاج إلى تفعيل GatewayPorts على نظامك المحلي عبر تعديل ملف ssh_config، أو عبر خيارات سطر الأوامر.

GatewayPorts yes

حالات الاستخدام

إذا أردت استخدام اتصال آمن للوصول إلى خدمة بعيدة يمكنها التواصل باستخدام بروتوكول نص غير مُشفر، مثل: redis، وmemcached، واستطعت الوصول إلى إحدى تلك الخدمات في خادم بعيد بأمان عبر شبكة عامة؛ فيمكنك إنشاء نفق اتصال من نظامك المحلي إلى الخادم البعيد عوضًا عن جعله يستمع إلى الاتصالات في شبكة الإنترنت العامة.

إعادة توجيه المنفذ البعيد

يُقصد بإعادة توجيه المنفذ البعيد عملية إعادة توجيه منفذ على نظام بعيد إلى نظام آخر.

ssh -R 8080:localhost:80 ssh-server

يُعيد هذا المثال توجيه حركة البيانات من جميع الواجهات في منفذ 8080 على خادم SSH إلى المنفذ 80 لمُضيفك المحلي localhost على حاسبك المحلي. فإذا كانت إحدى تلك الواجهات متاحةً لشبكة الإنترنت العامة، فإن حركة البيانات المتوجهة إلى منفذ 8080 سيُعاد توجيهها إلى نظامك المحلي.

ssh -R 1.2.3.4:8080:localhost:80 ssh-server

يعمل الاستعلام أعلاه على إعادة توجيه حركة البيانات من منفذ 8080 الخاص بخادم SSH إلى منفذ 80 الخاص بالمُضيف المحلي في نظامك المحلي، بينما يسمح فقط لعنوان IP 1.2.3.4 بالوصول إلى مدخل نفق SSH في خادم SSH. استخدم خيار GatewayPorts clientspecified لإجراء هذه العملية على نحو سليم.

ssh -R 8080:example.org:80 ssh-server

يُعيد هذا الاستعلام توجيه حركة البيانات من جميع الواجهات في عنوان ssh-server:8080 إلى عنوان localhost:80 على نظامك المحلي. بحيث سيُعاد توجيه حركة البيانات تلك من نظامك المحلي إلى عنوان example.org:80. ومن وِجهة نظر example.org، فإن مصدر حركة البيانات هو نظامك المحلي.

إعدادات خادم SSH

لا تسمح الإعدادات الافتراضية عادةً بالوصول إلى منافذ إعادة التوجيه من على شبكة الإنترنت العامة، حيث ستحتاج إلى إضافة الاستعلام التالي إلى ملف sshd_config الموجود في خادمك البعيد لتغيير ذلك والسماح بتدفق حركة البيانات من شبكة الإنترنت العامة إلى حاسبك المحلي.

GatewayPorts yes

أو يمكنك تحديد أيّ من العملاء يُسمح بوصولهم عن طريق استخدام الاستعلام التالي في ملف sshd_config عوضًا عن السابق.

GatewayPorts clientspecified

إعادة توجيه المنفذ الديناميكي

يُقصد به إعادة توجيه حركة البيانات من نطاق محدد من المنافذ إلى خادم بعيد.

ssh -D 3000 ssh-server

يفتح الاستعلام السابق وكيل بروتوكول SOCKS على منفذ 3000 لجميع واجهات نظامك المحلي، ليسمح لك ذلك بتوجيه البيانات المُرسلة عبر الوكيل proxy إلى خادم SSH في أي منفذ أو إلى خادم مستهدف. ومن الناحية الافتراضية، فإن بروتوكول SSH سيستخدم بروتوكول SOCKS5 الذي يمكنه توجيه كلا من حركة بيانات TCP وUDP.

ssh -D 127.0.0.1:3000 ssh-server

يفتح الاستعلام السابق وكيل SOCKS على عنوان 127.0.0.1:3000 في نظامك المحلي.

عندما يكون لديك وكيل SOCKS قيد العمل، فيمكنك إعداد متصفحك ليستخدمه ذلك الوكيل للوصول إلى الموارد، كما لو كان الاتصالات آتيةً من خادم SSH. فإذا حصل خادم SSH مثلًا على وصول إلى خوادم أخرى على شبكة خاصة، فيمكنك عبر استخدام وكيل SOCKS الوصول إلى تلك الخوادم محليًا كما لو كنت على الشبكة بدون الحاجة إلى إعداد شبكة افتراضية خاصة.

يمكنك اختبار وكيل SOCKS قيد العمل عبر استخدام الاستعلام التالي:

curl -x socks5://127.0.0.1:12345 https://example.org

إعدادات عميل SSH

إذا أردت أن يكون وكيل SOCKS متاحًا لمزيد من الواجهات وليس فقط الخادم المحلي، فعليك التأكد من تفعيل خيار GatewayPorts على نظامك المحلي:

GatewayPorts yes

بما أن خيار GatewayPorts قد أُعِدّ في عميل SSH سابقًا، فيمكنك أيضًا إعداده باستخدام خيارات سطر الأوامر عوضًا عن ملف ssh_config.

ssh -o GatewayPorts=yes -D 3000 ssh-server

القفز بين الخوادم وأوامر الوكيل

نقصد بهذا عملية إجراء اتصال شفاف إلى خادم بعيد عبر خوادم وسيطة.

ssh -J user1@jump-host user2@remote-host

ssh -o "ProxyJump user1@jump-host" user2@remote-host

يُنشئ المثال الموضح أعلاه اتصال SSH مع خادم قفز jump host، ويوجه تدفق بيانات TCP إلى خادم بعيد. أي أنه يتصل بالخادم البعيد عبر خادم قفز وسيط. يُفترض أن يعمل الاستعلام أعلاه مباشرةً بدون إعداد مسبق إذا كان خادم القفز لديه وصول SSH إلى الخادم البعيد، أما إذا لم يكن الأمر كذلك فيمكنك استخدام طريقة توجيه الوكيل agent forwarding لتمرير هوية SSH الخاصة بحاسبك المحلي إلى الخادم البعيد.

ssh -J jump-host1,jump-host2 ssh-server

يمكنك أيضًا استخدام فواصل متعددة (٫) للفصل بين خوادم القفز.

ssh -o ProxyCommand="nc -X 5 -x localhost:3000 %h %p" user@remote-host

يوضح الاستعلام السابق كيفية الاتصال بخادم بعيد عبر وكيل SOCKS5 مستخدمًا أوامر netcat. ومن وجهة نظر الخادم، فإن عنوان IP قد صدر من خادم وكيل proxy-host، ومع ذلك فإن اتصال SSH بحدّ ذاته مشفر بتقنية طرف لطرف end-to-end، لذلك فإن ذلك الخادم الوكيل لا يرى سوى تدفق من البيانات المشفرة بين النظام المحلي والخادم البعيد.

إعدادات عميل SSH

يمكنك استخدام خيار ssh-add لإضافة هوية SSH المحلية إلى وكيل SSH المحلي وتفعيل إمكانية توجيه الوكيل.

ssh-add

أنفاق SSH الموثوقة

نقصد بأنفاق SSH الموثوقة، كيفية إبقاء نفق SSH مفتوحًا حتى في حالة حدوث أخطاء في الشبكة، حيث تعمل جميع الأوامر سابقة الذكر على نحو مباشر ومُرتجل، لكن إذا أردت الحفاظ على نفق SSH مستقرًا خلال انقطاع الاتصال بالشبكة أو عند استخدام اتصالات رديئة، فستحتاج إلى إجراء إعدادات إضافية.

افتراضيًا، قد تستنفد اتصالات TCP المستخدمة لإنشاء نفق SSH من وقتها بعد فترة من عدم النشاط، ولمنع ذلك يمكنك إعداد الخادم لجعله يُرسل رسائل نبض بانتظام.

ClientAliveInterval 15
ClientAliveCountMax 4

يمكنك أيضًا إعداد العميل ليُرسل تلك النبضات.

ServerAliveInterval 15
ServerAliveCountMax 4

كيفية استخدام برنامج AutoSSH

بينما قد تنجح الخيارات المذكورة سابقًا في منع انقطع الاتصال بسبب عدم النشاط، فهي لن تُعيد إنشاء الاتصال المُنقطع. ولكي تتأكد من إعادة إنشاء نفق SSH، يمكنك استخدام برنامج AutoSSH والذي يُنشئ نفق SSH ويراقب حالته. حيث سيقبل برنامج AutoSSH نفس المتغيّرات التي يستخدمها SSH لإعادة التوجيه.

autossh -R 2222:localhost:22 ssh-server

يُنشئ المثال أعلاه نفقًا عكسيًا يرتد مجددًا عند فشل الاتصال بالشبكة. ومن الناحية الافتراضية، فإن برنامج AutoSSH سيفتح منافذًا إضافية في عميل SSH والخادم، وذلك لإجراء فحوصات الحالة. فإذا حدث وتوقف مرور البيانات بين منافذ فحص الحالة، فسيُعيد برنامج AutoSSH تشغيل نفق SSH.

autossh -R 2222:localhost:22 \
-M 0 \
-o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" \
remote-host

يُعطل استخدام راية M 0- تشغيل منافذ فحص الحالة، ويُسمح لعميل SSH بتولي أمر تلك الفحوصات. في هذا المثال التالي، فإن عميل SSH يتوقع من الخادم إرسال نبضة كل 10 ثوان، وإذا فشل الخادم في إرسال 3 نبضات متتالية، فسيُغلق عميل SSH النفق وسيُعيد برنامج AutoSSH إنشاء اتصال جديد.

المزيد من الأمثلة وحالات الاستخدام

وصول شفاف إلى موارد بعيدة في شبكة خاصة

لنفترض أن هناك مستودع git موجود في شبكة خاصة يمكن الوصول إليها فقط عبر خادم خاص على الشبكة ولا يمكن الوصول إلى هذا الخادم من خلال شبكة الإنترنت العامة. ومع أنك تمتلك وصولًا مباشرًا إلى الخادم، إلا أنك لا تمتلك وصول VPN إلى الشبكة الخاصة.

لنفترض أنك ترغب في الوصول إلى مستودع git الخاص كما لو كنت متصلًا به مباشرةً من نظامك المحلي، فإذا كان لديك وصول SSH إلى خادم آخر يمكن الوصول إليه من كلا نظامك المحلي وخادمك الخاص، فيمكنك الوصول إلى مستودع git الخاص عبر إنشاء نفق SSH واستخدام بعض إعدادات أوامر بروكسي.

ssh -L 127.0.0.1:22:127.0.0.1:2222 intermediate-host

سيعيد ذلك الاستعلام توجيه المنفذ 2222 في الخادم الوسيط إلى منفذ 22 في الخادم الخاص. والآن عند إنشاء اتصال SSH إلى منفذ 2222 من خادم وسيط، فستتصل بخادم SSH الموجود في الخادم الخاص رغم عدم القدرة على الوصول إلى الخادم الخاص عبر شبكة الإنترنت العامة.

ssh -p 2222 user@localhost

إذا رغبت في إنشاء باب خلفي بطريقة أسهل، فيمكنك إضافة بعض الاستعلامات إلى ملف ‎~/.ssh/config المحلي.

Host git.private.network
HostName git.private.network
ForwardAgent yes
ProxyCommand ssh private nc %h %p

Host private
HostName localhost
Port 2222
User private-user
ForwardAgent yes
ProxyCommand ssh tunnel@intermediate-host nc %h %p

وبهذا يكون قد بات لديك وصول إلى مستودع git الخاص كما لو كنت موجودًا على نفس الشبكة الخاصة.

ترجمة -وبتصرف- للمقال A visual guide to SSH tunnels، لكاتبه Linmiao Xu.

اقرأ أيضًا

• أساسيات سير عمل نظام التحكم في النسخ git
• دليلك إلى استعمال برنامج Vagrant
• [فيديو] الاتصال بخدمة GitHub دون كلمة سر

نشرح طريقة الاتصال الآمنة عبر SSH بخوادم لينكس باستعمال برمجية PuTTY. وهذا يتضمن إعداد الوصول إلى الخادم عبر كلمة المرور، أو عبر مفتاح عام.

مقدمة

إذا كنت تعمل(على الشبكة) مُستخدمًا بروتوكول النقل الآمن Secure Shell) SSH)، فإنّك تعلم مُسبقًا أنّ الجلسة session ستُغلق تلقائيًا بعد دقائقٍ قليلةٍ من عدم النشاط "الخمول"، وذلك لأسبابٍ أمنية.من الممكن في الحقيقة أن تكون قد نسيت إغلاقها، وبالتالي فقد يتمكن شخص آخر من السيطرة على نظامك. ولكن إذا كنت لا ترى في ذلك مشكلة، فبإمكانك تغيير هذا السلوك في ضبط GNU/Linux. يجب تنفيذ الأوامر التالية من عميل SSH.

كيفيّة منع SSH من قطع الاتصال

يجب تنفيذ الخطوات التالية في عميل SSH، وليس في الخادم البعيد.

افتح محرّر النص خاصتك في البداية وعدّل ملف الـ config الحالي للمستخدم الخاص بك، والذي تجده في المسار التالي:

	~/.ssh/config

أضف الأسطر التالية:

تأكّد من أن السطر الثاني سيبدأ بمسافة فارغة.

يُخبر السطر الأول الـ SSH بتطبيق هذا الضبط على جميع المضيفات البعيدة remote hosts. كما يمكنك بالطبع تحديد واحد منها فقط، وذلك باستبدال رمز الـ "*" بالمضيف المطلوب.

ستحتاج بعد الانتهاء من ذلك إلى تطبيق الإعدادات المذكورة أعلاه:

sudo source ~/.ssh/config

أضف أو عدّل السطر التالي في ملف etc / ssh / ssh_config/ لتطبيق هذه الإعدادات على المستوى العام globally:

ServerAliveInterval 60

احفظ الملف واغلقه.

وبهذه الطريقة، لن تُغلق جلسة SSH بعد الآن بسبب الخمول.

الخلاصة

تذكّر أن أمان نظامك، وخصوصًا في حالة الخادم server، ليس أمرًا ثانويًا، وذلك كلّه بيديك. إنّ تغيير سلوك برامج مثل SSH يجب أن يتم فقط في حال كنت تعرف بالضبط ما تريده، وبعد التأكّد من أنّ ذلك لن يضعك في مشكلةٍ ما.

ترجمة وبتصرّف للمقال How to prevent SSH from disconnecting sessions لصاحبه Giuseppe Molica

مقدمة

في كثيرٍ من الأحيان يصبح نقل الملفات من وإلى الخادوم عملية متعبة، يعرف ذلك جيدًا كل من يمتلك أو يدير خادومًا يضم موقعه الشخصي أو ماشابه، إنه يعرف تلك العملية المستمرة المتكررة والتي تبدأ بتنزيل الملفات من الخادوم البعيد لإدخال بعض التعديلات عليها (والتي غالبًا ما تكون صغيرة) ومن ثم إعادة رفعها واختبارها، وإذا كان التعديل خاطئا فستجد نفسك محبطًا لاضطرارك تنزيل نسخة جديدة من الملف لتعديلها وإعادة رفعها.
لحسن الحظ هناك طريقة بسيطة تتيح لنا ربط الخادوم البعيد مع جهازنا الشخصي، بحيث نتمكّن من إدارته كما لو كان قرصًا محليًا لدينا بما في ذلك إنشاء وتعديل الملفات عليه بينما تتم عملية رفع الملفات الجديدة أو المعدلة تلقائيًا إلى الخادوم.
سيتناول هذا المقال كيفية تركيب واستخدام الأداة SSHFS للقيام بذلك.

تركيب SSHFS

على دبيان والتوزيعات المبنية عليها

بنيت SSHFS لتعمل على لينكس أساسًا، لذا يمكن تركيبها بسهولة على جهازك عن طريق استدعائها من المستودع الرسمي لتوزيعتك، لمستخدمي دبيان لينكس (أو الأنظمة المبنية عليها مثل Ubuntu أو Mint) يتم ذلك من خلال الأمر apt-get.

sudo apt-get install sshfs

على فيدورا، CentOS

يمكن استخدام مدير الحزم yam كما يلي (وفق صلاحيات الجذر root).

yum install fuse-sshfs

على Archlinux

من خلال مدير الحزم pacman.

sudo pacman -S sshfs

على نظام OSX

مستخدمو أجهزة Mac عليهم تركيب كلًا من حزمتي FUSE و SSHFS من موقع osxfuse.

على نظام Windows

لاستخدام SSHFS على الأجهزة العاملة بنظام Windows نحتاج للحصول على برنامج win-sshfs من مستودعه الخاص على google code من الرابط أدناه.
بعد تنزيل الحزمة السابقة يمكن تركيبها بسهولة بالنقر المزودج عليها، قد يخبرك معالج التركيب بالحاجة إلى تنزيل ملفات إضافية من الشبكة (مثل إطار .NET Framework 4.0) وتركيبها على الجهاز.

https://win-sshfs.googlecode.com/files/win-sshfs-0.0.1.5-setup.exe

استخدام SSHFS لربط نظام ملفات بعيد

التعليمات التالية مخصصة لأنظمة لينكس و Mac OSX، مستخدمي ويندوز عليهم الانتقال إلى الفقرة التالية.

في البداية يتوجب علينا إنشاء مجلد جديد لاستخدامه كنقطة ربط لنظام الملفات المستهدف.

sudo mkdir /mnt/test

يمكنك استبدال test بأي اسم ترغب به.
كل شيء بات جاهزًا حيث يمكنك الآن ربط نظام الملفات محليًا باستخدام الأمر التالي:

sudo sshfs root@192.168.1.200:/ /mnt/test

ملاحظات:

• 192.168.1.200، هو عنوان IP الذي استخدمته للدخول إلى خادوم دبيان الخاص بي.
• مجلد test سيعرض نظام الملفات البعيد.
• ستسألك sshfs عن كلمة المرور في حال كنت تستخدم واحدة، أدخلها للمتابعة.
• أما في حال استخدامك مفتاح توثيق key authorization لتسجيل الدخول، فعليك اخبار sshfs بمفتاحك العام من خلال الأمر التالي والذي سيطلب منك إدخال عبارة المرور التي استخدمتها أثناء إنشاءك المفتاح مع ssh-keygen

sudo sshfs -o IdentityFile=~/.ssh/id_rsa root@192.168.1.200:/ /mnt/test

يمكنك الآن العمل على نظام الملفات البعيد كما لو كان قرصًا إضافيًا موصولًا إلى جهازك. على سبيل المثال كل ملف تعمل على إنشائه في مجلد test المحلي سيتم رفعه إلى الخادوم البعيد الخاص بك مباشرة (سواء أكنت تستخدم خادومًا افتراضيًا أو حقيقيًا)، يشمل ذلك النسخ، التعديل، الحذف، وغيره..
نقطة مهمة يجب الانتباه إليها، وهي أن عملية الربط السابقة مع الخادوم مؤقتة فإذا ما تم إيقاف أو إعادة تشغيل جهازك أو جهاز الخادوم فيجب تكرار الخطوات السابقة مجددًا.
عندما تنتهي من العمل يمكنك إلغاء ربط نقطة الوصول بسهولة باستخدام

sudo umount /mnt/test

ربط نظام الملفات بشكل دائم

إذا كنت ترغب في تثبيت نقطة الربط السابقة كي لا يتم إلغاؤها مع إيقاف أو إعادة تشغيل أيٍّ من جهازك أو الخادوم البعيد، فنحن بحاجة إلى إدخال بعض التعديلات على ملف /etc/fstab في جهازك المحلي لتفعيل نقطة الربط تلقائيًا مع كل إقلاع.
في البداية علينا تحرير ملف /etc/fstab بصلاحيات الجذر باستخدام محرر nano في الطرفية

sudo nano /etc/fstab

بعد ذلك أضف السطر التالي أسفل ملف fstab

sshfs#root@192.168.1.200:/ /mnt/test

احفظ التعديلات بالضغط على Ctrl مع X ثم اكتب yes واضغط Enter.
بينما تغني الخطوة الأخيرة عن تكرار عملية الربط بشكل يدوي وإدخال عبارة المرور ومفاتيح ssh في كل مرة، إلا أنها تنطوي على مخاطر أمنية، ففي حال تعرض جهازك المحلي لاختراق أو سرقة على سبيل المثال فسيغدوا خادومك البعيد عرضةً لذلك أيضًا، لذا لا ينصح عادةً بالتعديل على ملف fstab لإنشاء ربط تلقائي.

استخدام Win-SSHFS لربط نظام الملفات على أجهزة Windows

لربط نظام ملفات بعيد على Windows سنستعين ببرنامج win-sshfs والذي يملك واجهة رسومية بسيطة تقودنا خطوة بخطوة لإنجاز المطلوب، وذلك على النحو المبين آتيًا:

• بعد تشغيل البرنامج اضغط على زر Add أسفل يسار النافذة.
• أدخل اسما للخادوم الذي ستستضيف ملفاته من خانة Drive Name field.
• أدخل عنوان الـ IP الخاص بالخادوم.
• أبق الرقم 22 في خانة المنفذ SSH port (إلا إذا قمت بتغيير منفذ SSH يدويًا).
• أدخل اسم المستخدم في حقل Username.
• أدخل كلمة مرور SSH خاصتك في خانة password (في Windows لا يمكننا إعداد الحساب بتوثيق مفاتيح SSH).
• أدخل المسار الذي ترغب بربطه من الخادوم البعيد في حقل Directory، استخدم / لربط نظام الملفات ابتداء من مسار الجذر، أو /var/www لربط مجلد المنزل.
• اختر حرفًا من حقل Dirve Leter كي يستخدمه Windows كاسم لقرص نظام الملفات البعيد عند ربطه في جهاز الكمبيوتر.
• أخيرًا إضغط على زر Mount لإنشاء الإتصال وتفعيل نقطة الربط.

يمكنك التوجه إلى جهاز الكمبيوتر حيث ستشاهد قرصًا جديدًا يحمل الحرف الذي كنت قد اخترته منذ قليل ويحوي نظام ملفاتك البعيد.

استخدامات نقطة الربط

كما سبق وأشرنا يمكن التعامل مع نقطة الربط المنشأة كما لو كانت قرصًا إضافيًا على جهازك المحلي، يشمل ذلك عمليات النسخ، اللصق، النقل، التحرير، الإنشاء، الضغط، وأية عملية يمكن إجراءها على نظام الملفات باستثناء القدرة على تشغيل البرامج أو السكربتات scripts.
علاوة على تسهيل الوصول إلى ملفات الخادوم البعيد الخاص بك، يتيح إنشاء نقطة الربط استخدام البرامج التي تفضلها، إذ يمكنك تحرير ملفّات موقعك الشخصي على سبيل المثال بالمحرر الذي تحبّ، كما يمكنك تعديل البرمجيات باستخدام بيئة IDE التي تفضل، وحالما تنتهي من إجراء التعديلات وحفظها على حاسبك، ستكون في طريقها إلى الخادوم البعيد كذلك.
إضافةً إلى ذلك فإن استخدام نقطة الربط يتيح لك اختبار التعديلات التي تعمل عليها بشكل فوري ودون الحاجة إلى تنزيل الملف من الخادوم، التعديل عليه، ومن ثم إعادة رفعه لمشاهدة النتائج، لا سيما عند إجراء اختبارات متكررة والتي تجعل من العملية السابقة مملة بشكل كبير.

ترجمة -وبتصرّف- للمقال How To Use SSHFS to Mount Remote File Systems Over SSH

سنقدم في هذا الدرس من دليل إدارة خواديم أوبنتو مجموعة أدوات فعّالة للتحكم البعيد ونقل الملفات بين الحواسيب المتصلة بالشبكة تسمى «OpenSSH»، سنتعلم أيضًا مجموعةً من إعدادات الضبط الممكنة مع خادوم OpenSSH ونتعلم كيف نغيرها في نظام أوبنتو الخاص بك.

إن OpenSSH هو إصدار مجاني وحر من مجموعة أدوات بروتوكول «الصدفة الآمنة» (Secure Shell ‏[SSH]) للتحكم البعيد أو نقل الملفات بين الحواسيب؛ الأدوات التقليدية التي كانت مستخدمةً لإنجاز هذه المهام -مثل telnet أو rcp- لم تكن آمنةً حيث كانت تنقل كلمة مرور المستخدم بنصٍ واضح عند استخدامها؛ أما OpenSSH، فيُوفِّر عفريتًا وأدوات للعميل لإنشاء عمليات تحكم عن بعد أو نقل الملفات آمنة ومشفرة؛ ويستبدل الأدوات القديمة استبدالًا فعالًا.

مكونة خادوم OpenSSH المسماة sshd «تستمع» (listens) باستمرار لاتصالات العميل، وعندما يحدث طلب اتصال، فإن sshd ينُشِئ نوع الاتصال الصحيح اعتمادًا على نوع أداة العميل التي تجري الاتصال؛ على سبيل المثال، لو أن الحاسوب البعيد يتصل باستخدام برمجية عميل ssh، فإن خادوم OpenSSH يهيّء جلسة تحكم عن بُعد بَعد الاستيثاق؛ وإذا اتصل المستخدم البعيد مع خادوم OpenSSH باستخدام scp، فسيُهيّء عفريت خادوم OpenSSH نقلًا آمنًا للملفات بين الخادوم والعميل بعد الاستيثاق؛ ويمكن أن يَستخدِم OpenSSH عدَّة طرق للاستيثاق، منها كلمة المرور العادية، والمفتاح العمومي (public key)، وبطاقات Kerberos للدخول.

التثبيت

إن عملية تثبيت خادوم وعميل OpenSSH هي عمليةٌ بسيطة؛ استخدم هذا الأمر من مِحَث الطرفية لتثبيت عميل OpenSSH على نظام أوبنتو:

sudo apt-get install openssh-client

استخدم هذا الأمر في سطر الأوامر لتثبيت خادوم OpenSSH، وملفات الدعم المتعلقة به:

sudo apt-get install openssh-server

يمكن أيضًا تحديد حزمة openssh-server للتثبيت أثناء عملية تثبيت نسخة الخادوم من أوبنتو.

الضبط

يمكنك ضبط السلوك الافتراضي لتطبيق خادوم OpenSSH‏ (sshd) بتعديل الملف ‎/etc/ssh/sshd_config، للمزيد من المعلومات حول الضبط المستخدم في هذا الملف، تستطيع مراجعة صفحة الدليل الملائمة بإدخال الأمر الآتي في الطرفية:

man sshd_config

هنالك تعليمات كثيرة في ملف ضبط sshd تتحكم بأشياء مثل إعدادات الاتصالات وأنماط الاستيثاق؛ يمكن أن تُعدَّل ما سنشرحه من تعليمات الضبط بتعديل ملف ‎/etc/ssh/sshd_config.

تنويه: قبل تعديل ملف الضبط، عليك أخذ نسخة من الملف الأصلي وحفظها من الكتابة عليها لكي تحصل على نسخة من الضبط الافتراضي كمرجع، ولإعادة استخدامها وقت الحاجة.

انسخ ملف ‎/etc/ssh/sshd_config واحمهِ من الكتابة باستخدام الأوامر الآتية:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
sudo chmod a-w /etc/ssh/sshd_config.original

ما يلي هو أمثلة عن تعليمات الضبط التي قد ترغب في تعديلها:

• لضبط OpenSSH لكي يستمع على منفذ TCP ذي الرقم 2222 بدلًا من منفذ TCP الافتراضي 22، فغيِّر تعليمة المنفذ كما يلي:

Port 2222

• لكي تجعل sshd يسمح باستخدام الاستيثاق المبني على المفتاح العمومي، فأضف أو عدِّل السطر:

PubkeyAuthentication yes

إذا كان السطر موجودًا مسبقًا، فتأكد من عدم وجود رمز التعليق قبله.

• لجعل خادوم OpenSSH يعرض محتويات ملف ‎/etc/issue.net كلافتة قبل تسجيل الدخول، فأضف أو عدِّل السطر الآتي:

Banner /etc/issue.net

في ملف ‎./‎etc/ssh/sshd_config

بعد إجراء التعديلات على ملف ‎/etc/ssh/sshd_config، فاحفظ الملف ثم أعد تشغيل خادوم sshd لتأخذ التغيرات مفعولها، وذلك بإدخال الأمر الآتي في مِحَث الطرفية:

sudo service ssh restart

تحذير: تتوفر المزيد من تعليمات الضبط لخادوم sshd لتعديل سلوك الخادوم لكي يلائم احتياجاتك، لكن يجب التنويه أنه إذا كانت الطريقة الوحيدة للوصول إلى الخادوم هي ssh، وارتكبت خطأً في ضبط sshd عبر ملف ‎/etc/ssh/sshd_config، فستجد نفسك غير قادرٍ على الوصول إلى الخادوم بعد إعادة تشغيل خدمة sshd؛ بالإضافة إلى أنك إذا وضعت تعليمة ضبط خاطئة، فسيرفض خادوم sshd أن يعمل؛ لذلك كن حذرًا جدًا عند تعديل هذا الملف على خادوم بعيد.

مفاتيح SSH

تسمح مفاتيح SSH بالاستيثاق بين جهازين دون الحاجة إلى كلمة مرور، يَستخدم الاستيثاق بواسطة مفتاح SSH مفتاحين: مفتاح خاص (private) ومفتاح عام (public).

أدخِل الأمر الآتي في الطرفية لتوليد المفاتيح:

ssh-keygen -t dsa

سيولد الأمر السابق المفاتيح باستخدام خوارزمية التوقيع الرقمية (Digital Signature Algorithm‏ [DSA])، ستُطلَب منك كلمة المرور أثناء العملية، بعد ذلك اضغط ببساطة على Enter لإنشاء المفتاح.

افتراضيًا، يُحفَظ المفتاح العام في الملف ‎~/.ssh/id_dsa.pub، بينما يكون ملف ‎~/.ssh/id_dsa هو المفتاح الخاص، انسخ ملف id_dsa.pub إلى المضيف البعيد، ثم أضفه إلى نهاية ملف ‎~/.ssh/authorized_keys باستخدام الأمر:

ssh-copy-id username@remotehost

في النهاية، تأكد من الأذونات على ملف authorized_keys، حيث يجب أن يملك المستخدم الموثوق فقط إذن القراءة والكتابة؛ إذا لم تكون الأذونات صحيحة، فعدلها بالأمر:

chmod 600 .ssh/authorized_keys

يجب أن تصبح الآن قادرًا على الدخول إلى SSH على المضيف البعيد دون طلب كلمة المرور.

مصادر

• صفحة ويكي أوبنتو «SSH».
• موقع «OpenSSH».
• صفحة الويكي «Advanced OpenSSH».

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenSSH Server.

إنّ عامل الاستيثاق authentication factor هو جزء من المعلومات يُستخدَم لإثبات أنّه لدينا الحق لتنفيذ إجراء ما، مثل تسجيل الدخول إلى النّظام، وقناة الاستيثاق authentication channel هي الطّريقة التي يُوصِل بها نظام الاستيثاق عاملًا factor للمستخدم أو الطّريقة التي يطلب بها من المستخدم الرّد، من الأمثلة على عوامل الاستيثاق نجد كلمات السّر ورموز الأمان security tokens، ومن الأمثلة على قنوات الاستيثاق نجد الحواسيب والهواتف المحمولة.

تستخدم SSH افتراضيًّا كلمات السّر من أجل الاستيثاق، وتُوصي تعليمات SSH باستخدام مفتاح SSH key بدلًا من ذلك، على أيّة حال يبقى هذا عاملًا واحدًا فقط، فإن تمّ تهديد الحاسوب لدينا من قبل شخص ما، فبإمكانه استخدام مفتاحنا لتهديد خواديمنا أيضًا.

لمكافحة هذا سنقوم في هذا الدّرس بإعداد استيثاق مُتعدِّد العوامل (Multi-factor authentication (MFA، والذي يتطلّب أكثر من عامل من أجل الاستيثاق أو تسجيل الدّخول، وهذا يعني أنّه يجب على المُخترِق أن يُهدِّد عدّة أشياء، مثل حاسوبنا وهاتفنا المحمول معًا لكي يستطيع الدخول، يتم عادةً تلخيص أنواع العوامل المختلفة كما يلي:

1. شيء نعرفه، مثل كلمة سر أو سؤال أمان
2. شيء نملكه، مثل تطبيق استيثاق أو رمز أمان security token
3. شيء نكون نحن عليه، مثل بصمة الأصابع أو الصوت

من العوامل الشائعة تطبيق OATH-TOTP مثل Google Authenticator، إنّ (OATH-TOTP (Open Authentication Time-Based One-Time Password الاستيثاق المفتوح لكلمة سر لمرّة واحد مُعتمِدة على الزمن هو عبارة عن ميثاق protocol مفتوح يقوم بتوليد كلمة سر صالحة للاستخدام لمرّة واحدة تكون عادةً عددًا من 6 أرقام يتم تجديده كل 30 ثانية.

سيشرح هذا الدّرس كيفيّة تمكين استيثاق SSH باستخدام تطبيق OATH-TOTP بالإضافة لمفتاح SSH ، حيث سيتطلّب تسجيل الدخول إلى خادومنا عبر SSH عاملين اثنين عبر قناتين ممّا يجعله أكثر أمانًا من كلمة السّر أو مفتاح SSH لوحدهما.

المتطلبات الأساسية

سنحتاج لمتابعة هذا الدّرس إلى:

• خادوم Ubuntu 14.04.
• مستخدم sudo غير جذري non-root مع إضافة مفتاح SSH، والذي نستطيع إعداده باتّباع درس الإعداد الابتدائي لخادوم أوبنتو 14.04.
• هاتف ذكي أو لوحي tablet مُثبَّت عليه تطبيق OATH-TOTP مثل Google Authenticator (روابط تنزيله من أجل Android و iOS).

الخطوة الأولى – تثبيت libpam-google-authenticator

سنقوم في هذه الخطوة بتثبيت وإعداد PAM الخاصّة بـ Google.

إنّ PAM، والتي ترمز إلى وحدة الاستيثاق القابلة للإضافة Pluggable Authentication Module، هي عبارة عن بنية تحتيّة للاستيثاق تُستَخدم على أنظمة لينِكس من أجل استيثاق المستخدمين، ولأنّ Google صنعت تطبيق OATH-TOTP فقد قامت أيضًا بإنشاء PAM تقوم بتوليد TOTPs ومتوافقة بشكل كامل مع أي تطبيق OATH-TOTP.

نقوم في البداية بتحديث الذاكرة المؤقتة cache لمستودع Ubuntu:

sudo apt-get update

نُثبِّت بعدها PAM:

sudo apt-get install libpam-google-authenticator

وبعد تثبيت PAM سنستخدم تطبيق مُساعِد يتم تثبيته مع PAM لتوليد مفتاح TOTP للمستخدم الذي نرغب بإضافة عامل ثانٍ له، يتم توليد هذا المفتاح للمستخدم على أساس المستخدم وليس على أساس النّظام، ويعني هذا أنّ كل مستخدم يريد استعمال تطبيق استيثاق TOTP سيحتاج لتسجيل الدخول وتشغيل التطبيق المُساعِد للحصول على المفتاح الخاص به:

google-authenticator

بعد تنفيذ الأمر سيتم سؤالنا عدّة أسئلة، يطلب السؤال الأول معرفة إذا ما كان يجب أن تكون رموز الاستيثاق authentication tokens على أساس زمني.

يسمح PAM هذا برموز على أساس زمني time-based أو على أساس تتابعي sequential-based، يعني استخدام رموز على أساس تتابعي أنّ الشيفرة code تبدأ في نقطة مُعيّنة وبعدها تقوم بزيادة الشيفرة بعد كل استخدام، ويعني استخدام رموز على أساس زمني أنّ الشيفرة تتغير بشكل عشوائي بعد انقضاء وقت مُحدّد، سنختار الرموز على أساس زمني لأنّ هذا ما تتوقعه تطبيقات مثل Google Authenticator، لذا نجيبه بنعم:

Do you want authentication tokens to be time-based (y/n) y

بعد الإجابة على هذا السؤال سيتم تمرير الكثير من الخَرْج output، ومن ضمنه شيفرة QR كبيرة، تأكّد من تسجيلك للمفتاح السّري secret key، شيفرة التحقيق verification code، وشيفرات البداية في حالات الطوارئ emergency scratch codes في مكان آمن مثل مُدير كلمات السّر.

عند هذه النقطة نستخدم تطبيق الاستيثاق authenticator الموجود على هاتفنا لمسح scan شيفرة QR أو نكتب يدويًّا المفتاح السّري، إن كانت شيفرة QR كبيرة جدًّا لمسحها نستطيع استخدام الرابط الموجود أعلاها للحصول على نسخة أصغر منها، حالما تتم إضافتها سنرى رمزًا مُكوَّنًا من 6 أرقام يتغيّر كل 30 ثانية في تطبيقنا.

تقوم بقيّة الأسئلة بإعلام PAM كيف يعمل، سنمر عليها واحدًا تلو الآخر:

Do you want me to update your "~/.google_authenticator" file (y/n) y

يقوم هذا بشكل أساسي بكتابة المفتاح والخيارات إلى الملف google_authenticator.، إن قلنا "لا" سيخرج البرنامج ولن تتم كتابة أي شيء، والذي يعني أنّ تطبيق الاستيثاق authenticator لن يعمل.

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

نمنع عندما نجيب على هذا السؤال بنعم هجمات الإعادة replay attack بأن نجعل كل رمز تنتهي صلاحيّته مباشرة بعد استخدامه، وهذا يمنع المُهاجِم من التقاط الرّمز الذي استخدمناه للتو وتسجيل الدخول به.

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n

تسمح إجابة نعم هنا بثمانية رموز صالحة خلال فترة 4 دقائق، وبإجابتنا "لا" نقوم بتحديدها إلى 3 رموز صالحة خلال فترة 1:30 دقيقة، إن لم تكن لديك مشكلة مع هذه الفترة فالإجابة "لا" هنا هي الخيارة الأكثر أمانًا.

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

يعني تحديد المُعدَّل Rate limiting أنّ المُهاجِم البعيد يستطيع فقط أن يحاول عدد مُحدَّد من التخمينات قبل أن يتم حظره، إن لم نقم مُسبقًا بإعداد تحديد المُعدَّل بشكل مباشر داخل SSH فإنّ فعل هذا هنا هو تقنية رائعة.

الخطوة الثانية – إعداد OpenSSH

إنّ الخطوة التالية الآن هي إعداد SSH لاستخدام مفتاح TOTP لدينا، سنحتاج أن نخبر SSH عن PAM ومن ثم نقوم بإعداد SSH لاستخدامه.

نفتح أولًا ملف الإعدادات sshd لتحرير باستخدام nano أو مُحرِّر النصوص المُفضَّل لدينا:

sudo nano /etc/pam.d/sshd

نضيف السطر التالي إلى نهاية الملف:

. .
\# Standard Un*x password updating.
@include common-password
auth required pam_google_authenticator.so nullok

تُخبِر الكلمة "nullok" الموجودة في النهاية PAM أنّ طريقة الاستيثاق هذه اختياريّة، فيسمح هذا للمستخدمين الذين لا يملكون مفتاح OATH-TOTP أن يظلّوا قادرين على تسجيل الدخول باستخدام مفتاح SSH الخاص بهم، أمّا إن كان جميع المستخدمين يملكون مفتاح OATH-TOTP فنستطيع حذف "nullok" من هذا السّطر لجعل الاستيثاق مُتعدِّد العوامل MFA إجباريًّا.

نحفظ ونغلق الملف.

نقوم بعدها بإعداد SSH ليدعم هذا النوع من الاستيثاق، نفتح ملف إعدادات SSH لتحريره:

sudo nano /etc/ssh/sshd_config

نبحث عن ChallengeResponseAuthentication ونعيّن قيمتها إلى yes:

. . .
\# Change to yes to enable challenge-response passwords (beware issues with
\# some PAM modules and threads)
ChallengeResponseAuthentication yes
. . .

نحفظ ونغلق الملف، ونعيد تشغيل SSH لإعادة تحميل ملفّات الإعدادات:

sudo service ssh restart

الخطوة الثالثة – جعل SSH على علم بالاستيثاق مُتعدد العوامل MFA

سنختبر في هذه الخطوة إذا ما كان مفتاح SSH يعمل.

نفتح أولًا طرفيّة terminal أخرى ونحاول الدخول عبر SSH إلى الخادوم، سنلاحظ أنّنا سجلّنا الدخول إلى هذه الجلسة الثانية باستخدام مفتاح SSH الخاص بنا بدون إدخال شيفرة التحقيق أو كلمة السّر، حدث هذا لأنّ مفتاح SSH يقوم بشكل افتراضي بتجاوز جميع خيارات الاستيثاق الأخرى، نحتاج أن نُخبِر SSH أن يستخدم شيفرة TOTP ومفتاح SSH بدلًا من كلمة السر.

نفتح الآن ملف الإعدادات sshd مرّة أخرى:

sudo nano /etc/ssh/sshd_config

نبحث عن السطر PasswordAuthentication ونزيل التعليق عنه بحذف الحرف # في بداية السّطر ونقوم بتحديث قيمته إلى no، يُخبِر هذا SSH ألّا يقوم بالسؤال عن كلمة السّر.

. . .
\# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
. . .

نضيف بعد ذلك السطر التالي إلى أسفل الملف، والذي يُخبِر SSH ما هي طرق الاستيثاق المطلوبة:

. . .
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

نحفظ ونغلق الملف.

نفتح بعدها ملف إعدادات PAM sshd:

sudo nano /etc/pam.d/sshd

نقوم بإيجاد السطر include common-auth@ وجعله كتعليق بإضافة الحرف # كالحرف الأول في هذا السطر، يُخبِر هذا PAM ألّا تسأل عن كلمة السر، وقد قمنا سابقًا بإخبار SSH ألّا تفعل هذا في sshd_config:

. . .
# Standard Un*x authentication.
#@include common-auth
. . .

نحفظ ونغلق الملف ومن ثم نعيد تشغيل SSH:

sudo service ssh restart

نحاول الآن تسجيل الدخول إلى الخادوم مرّة أخرى، ينبغي أن نرى أنّنا قمنا بالاستيثاق بشكل جزئي باستخدام مفتاح SSH الخاص بنا ومن ثمّ حصلنا على مُحِث prompt من أجل شيفرة التحقيق verification code، والذي سيبدو مشابهًا لما يلي:

ssh sammy@your_server_ip

Authenticated with partial success.
Verification code:

نُدخِل شيفرة التحقيق من تطبيق OAUTH-TOTP لدينا، وسيتم تسجيل دخولنا إلى الخادوم، نمتلك الآن الاستيثاق مُتعدِّد العوامل MFA مُمكَّنًا من أجل SSH.

الخاتمة

وكما يحدث مع أي نظام نقوم بتمنيعه وتأمينه سنصبح مسؤولين عن إدارة هذا الأمان، ويعني هذا في هذه الحالة عدم فقدان مفتاح SSH الخاص بنا أو مفتاح أمان TOTP، ومع ذلك قد يحدث هذا في بعض الأحيان ونفقد التحكّم بالمفاتيح التي تجعلنا نُسجِّل الدخول.

نجد هنا بعض الاقتراحات لاستعادة النفاذ إلى خادومنا:

• إن فقدنا تطبيق TOTP أو لم نعد نملك نفاذًا إليه، نستخدم شيفرات الاستعادة recovery codes كشيفرة للتحقيق، قد يحدث هذا إن اشترينا هاتفًا جديدًا ونسينا تصدير مفاتيحنا من الهاتف القديم، أو نفذت بطارية هاتفنا.
• إن فقدنا مفتاح الأمان secret key والنسخة الاحتياطية، نقوم بإعادة تسمية أو حذف الملف google_authenticator./~، حيث يحرص هذا ألّا تعود PAM على معرفة بإعداداتنا وألّا تطلب منّا الرمز، تأكّد من أنّ الملف etc/pam.d/sshd/ لا زال يملك "nullok" في آخره، مثل الخطوة الثانية، وإن غيّرنا هذا نقوم بإعادة تشغيل SSH.
• إن فقدنا مفتاح SSH الخاص بنا، نقوم بإزالة المفتاح العام القديم من ssh/authorized_hosts./~، ونستبدله بمفتاح جديد.

بامتلاك عاملين (مفتاح SSH+رمز MFA token) عبر قناتين اثنتين (حاسوبنا+هاتفنا المحمول) جعلنا من المستحيل تقريبًا لأي عميل خارجي أن يشقّ طريقه بالقوة القاسية brute force إلى داخل جهازنا عبر SSH وقمنا بزيادة أمان جهازنا بشكل رائع.

ترجمة -وبتصرّف- لـ How To Set Up Multi-Factor Authentication for SSH on Ubuntu 14.04 لصاحبه Michael Holley.

تنفيق النقل (أي نقله) عبر نفق SSH آمن (SSH Tunnel)، هو طريقة ممتازة للعمل حول إعدادات جدار ناري تقييدي خاص بـ SSH. ويُعتبر أيضا طريقة رائعة لتشفير أو فك تشفير نقل الشّبكة (network traffic).

ضبط تنفيق محلي إلى خادوم

يُمكن استخدام اتّصالات SSH لتنفيق النقل (أي نقل البيانات عبر أنفاق) من المنافذ على المُضيف المحلي إلى منافذ أخرى على مُضيف بعيد.

أوّلاً، يُؤسَّس اتّصال SSH مع المُضيف البعيد. أمّا على الخادوم البعيد، يتم إنشاء اتّصال إلى عنوان شبكة خارجيّة (أو داخليّة) مُقدّم من المُستخدم، والنّقل إلى هذا الموقع يُنفّق (أي يستخدم نفقا) إلى الحاسوب المحلي على منفذ مُحدّد. هذا الأمر يُستخدم عادة للتنفيق نحو بيئة شبكية أقل تقييدا لتجاوز جدار ناري (الأمر أشبه بـآلية عمل VPN)، أي أن هناك طرفا ثالثا (كالبروكسي أو خادوم في منتصف الطريق يمر عليه نقل الشبكة Network traffic). ويُستعمل أيضا بشكل شائع للوصول إلى واجهة ويب من نوع 'مُضيف محلي فقط' من مكان بعيد. لإنشاء نفق محلي نحو الخادوم البعيد، ستحتاج إلى استخدام مُعامل L- عند الاتّصال ويجب عليك توفير 3 معلومات إضافية:

• المنفذ المحلي الذي ترغب في الوصول إلى الاتّصال المُنفّق منه.
• المُضيف الذي ترغب في أن يتصل به المُضيف البعيد.
• المنفذ الذي تريد أن يتصل منه المُضيف البعيد. 

وهي مُعطاة بالترتيب أعلاه (مُفرّقة بنقطتين بين كل منها) كقيم للمعامل L-. وسنستخدم أيضا المُعامل f- الذي يُحيل SSH للعمل في الخلفيّة قبل التشغيل، وكذلك المُعامل N-، الذي لا يفتح شلّا أو يُنفذ برنامجا على الجهة البعيدة. 

على سبيل المثال، للاتّصال بـ example.com على المنفذ رقم 80 على المُضيف البعيد، متيحا الاتّصال على جهازك المحلي عبر المنفذ رقم 8888، يُمكنك أن تكتب الآتي: 

ssh -f -N -L 8888:example.com:80 username@remote_host 

إذا قمت بالدّخول إلى 127.0.0.1:8888 على مُتصفّحك المحلي، ستحصل على محتوي example.com من المنفذ رقم 80. تركيب جملة أعمّ يُمكن أن يكون كالتّالي: 

ssh -L your_port:site_or_IP_to_access:site_port username@host 

بما أنّ الاتّصال يتم في الخلفّية يجب عليك إيجاد رقم PID لقتله (إغلاقه)، يُمكنك فعلُ ذلك بالبحث عن المنفذ الذي وضّفته: 

ps aux | grep 8888

1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 
ssh -f -N -L 8888:example.com:80 username@remote_host 
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888 

يُمكنك بعدها قتلُ العمليّة باستهداف رقم PID، وهو الرقم على العمود الثّاني الذّي يُوافق أمر SSH :

kill 5965 

هناك خيّار آخر وهو بدء الاتّصال بدون المُعامل f-. الأمر الذي سيُبقي الاتّصال في الواجهة، مانعاً استخدام نافذة الطّرفية كامل مدّة الإحالة. والإفادة هنا هي إمكانية إيقاف النّفق بالضّغط على "CTRL-C”.

ضبط تنفيق بعيد إلى خادوم

يُمكن استعمال اتّصالات SSH لتنفيق النّقل من منافذ على المُضيف المحليّ إلى منافذ على المُضيف البعيد. الاتّصال يُخلق نحو مُضيف بعيد على النفق البعيد، خلال إنشاء النّفق يُحدّد رقم منفذ بعيد. هذا المنفذ على المُضيف البعيد سيُنفّق نحو مُضيف ومنفذ مربوطين من الجهاز المحليّ. هذا سيُخوّل الحاسوب البعيد للوصول إلى مُضيف عبر جهازك المحليّ. يُمكنُ لهذا أن يكونَ مُفيداً إذا احتجتَ للسّماح بالوصول إلى شبكة داخليّة مُغلقة نحو اتّصالات خارجيّة. إذا كان الجدار النّاري يسمح بالاتّصالات خارج الشّبكة فإنّ هذا سيُخولُ لك الاتّصال إلى جهاز بعيد ونفق نقل من ذلك الجهاز نحو مكان على الشبكة الدّاخليّة. لإنشاء نفق بعيد نحو خادومك البعيد، ستحتاج إلى تمرير المعامل R- عند الاتّصال ويجب عليك توفير 3 معلومات إضافيّة:

• رقم المنفذ الذي يُمكن للمُضيف البعيد أن يصل إلى الاتّصال المُنفّق منه.
• المُضيف الذي ترغب في أن يتّصل به جهازك المحلي.
• المنفذ الذي ترغب في أن يتّصل منه جهازك المحليّ. 

وهي مُعطاة بالترتيب أعلاه (مُفرّقة بنقطتين بين كل منها) كقيم للمعامل R-. وسنستخدم أيضا المُعامل f- الذي يُحيل SSH للعمل في الخلفيّة قبل التشغيل، وكذلك المُعامل N-، الذي لا يفتح شلّا (shell) أو يُنفذ برنامجا على الجهة البعيدة.

على سبيل المثال، للاتّصال ب example.com على المنفذ رقم 80 على المُضيف المحليّ، متيحا الاتّصال على الجهاز البعيد عبر المنفذ رقم 8888، يُمكنك أن تكتب الآتي: 

ssh -f -N -R 8888:example.com:80 username@remote_host 

إذا قمت بالدّخول إلى 127.0.0.1:8888 على مُتصفّح الخادوم، ستحصل على محتوي example.com من المنفذ رقم 80. تركيب جملة أعمّ يُمكن أن يكون كالتّالي: 

ssh -R your_port:site_or_IP_to_access:site_port username@host 

بما أنّ الاتّصال يتم في الخلفّية يجب عليك إيجاد رقم PID لقتله (إغلاقه)، يُمكنك فعلُ ذلك بالبحث عن المنفذ الذي وضّفته:

ps aux | grep 8888

1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 
ssh -f -N -L 8888:example.com:80 username@remote_host 
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888 

يُمكنك بعدها قتلُ العمليّة باستهداف رقم PID، وهو الرقم على العمود الثّاني الذّي يُوافق أمر SSH :

kill 5965 

هناك خيّار آخر وهو بدء الاتّصال بدون المُعامل f-. الأمر الذي سيُبقي الاتّصال في الواجهة، مانعاً استخدام نافذة الطّرفية كامل مدّة الإحالة. والإفادة هنا هي إمكانية إيقاف النّفق بالضّغط على "CTRL-C”.

ضبط تنفيق ديناميكي نحو خادوم بعيد

يُمكن استعمال اتّصالات SSH لتنفيق النّقل من منافذ على المُضيف المحليّ إلى منافذ على المُضيف البعيد. النّفق الديناميكي مُماثل للنّفق المحليّ من حيث أنّه يُخول الجهاز المحلي للاتّصال بموارد أخرى عبر مُضيف بعيد. يقوم النّفق الديناميكي بهذا ببساطة عبر تحديد منفذ محلي واحد. التطبيقات التي ترغب في أن تستغلّ الفرصة للتنفيق من هذا المنفذ يجب أن تكون قادرة على التواصل باستخدام بروتوكول SOCKS ليُعاد توجيه الحزم بنجاح على الجانب الآخر من النّفق. النّقلُ المُمَرّر نحو المنفذ المحلي سيُرسَلُ إلى المُضيف البعيد. من هناك سيُترجم بروتوكول SOCKS لإنشاء اتّصالٍ نحو النهاية المرغوبة. هذا الضّبط يسمح لتطبيق من نوع SOCKS-capable بالاتّصال بأي عدد من الأماكن عبر خادوم بعيد بدون أنفاق ساكنة مُتعدد لإنشاء الاتّصال. 

سنُمرّر المُعامل D- مع رقم المنفذ المحلي الذي نرغب أن نصل إلى النّفق منه. وسنستخدم أيضا المُعامل f- الذي يُحيل SSH للعمل في الخلفيّة قبل التشغيل، وكذلك المُعامل N-، الذي لا يفتح شلّا أو يُنفذ برنامجا على الجهة البعيدة. على سبيل المثال، لإنشاء اتّصال مع نفق على المنفذ "7777” سنكتب الأمر: 

ssh -f -N -D 7777 username@remote_host 

يُمكنك الآن أن تبدأ توجيه تطبيق SOCKS-aware (كمُتصفح الويب)، نحو المنفذ الذي اخترته سيرسل التّطبيق معلوماته إلى المقبس المربوط مع المنفذ. طريقة توجيه النّقل نحو منفذ SOCKS تختلف حسب التّطبيق، في فايرفوكس Firefox على سبيل المثال الموقع العام هو:

Preferences > Advanced > Settings > Manual proxy configurations

أما في Chrome فتستطيع تشغيل التطبيق مع تحديد مُعامل –proxy-server= . سترغب في استخدام واجهة المُضيف المحلي (localhost interface ) ورقم المنفذ الذي أحَلْتَه. بما أنّ الاتّصال يتم في الخلفّية يجب عليك إيجاد رقم PID لقتله (إغلاقه)، يُمكنك فعلُ ذلك بالبحث عن المنفذ الذي وضّفته:

ps aux | grep 8888

1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 
ssh -f -N -D 7777 username@remote_host 
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888 

يُمكنك بعدها قتلُ العمليّة باستهداف رقم PID، وهو الرقم على العمود الثّاني الذّي يُوافق أمر SSH : 

kill 5965 

هناك خيّار آخر وهو بدء الاتّصال بدون المُعامل f-. الأمر الذي سيُبقي الاتّصال في الواجهة، مانعاً استخدام نافذة الطّرفية كامل مدّة الإحالة. والإفادة هنا هي إمكانية إيقاف النّفق بالضّغط على "CTRL-C”.

استعمال شيفرات الإلغاء للتحكم بالاتّصالات

حتى عند إنشاء جلسة SSH، يُمكن التحكم في الاتّصال من داخل الطرفيّة. يُمكن القيام بهذا مع شيء اسمه "شيفرات الإلغاء (SSH escape codes)”  والتي تُخوّل لنا التّفاعل مع تطبيق SSH المحلي من داخل الجلسة.

إجبار إلغاء الاتّصال من جهة العميل (كيف تخرج من جلسة مُتجمّدة لا تقبل الإجابة)

تعتبر إمكانيّة التحكم في جوانب مُعيّنة من الجلسة بالدّاخل من أهم مُميّزات OpenSSH التي غالبا ما لا يُلاحظها الكثيرون. يُمكن تشغيل هذه الأوامر بتقديمها برمز التحكم "~" داخل جلسة SSH. ستُفسّرُ أوامر التحكم فقط إذا كانت أول شيء مكتوب بعد سطر جديد، لذلك اضغط دائما على ENTER مرّة أو مرّتين كإجراء احتياطي. من أكثر الإمكانيات التي يُتيحها التحكم قوة هي إمكانية إلغاء الاتّصال من جهة العميل. اتّصالات SSH عادة ما تُغلق من طرف الخادوم، لكنّ هذا يُمكن أن يكون مُشكلة إذا كانت هناك مشاكل في الخادوم أو إذا قُطع الاتّصال. يُمكن أن تُغلق الاتصال بشكل نظيف من جهة العميل. لإغلاق اتّصال من العميل، استخدم رمز التحكم "~”، مع إضافة نقطة "." . إذا كانت هناك مشاكل في الاتّصال في الغالب ستجد نفسك مع جلسة طرفيّة مُتجمّدة. اكتب الأمر ولو لم تشعر بأنك تكتب شيئا:

[ENTER] ~. 

يجب على الاتّصال أن يُغلق فورا، وسيرجعك إلى جلسة الشل المحليّة.

وضع جلسة SSH في الخلفيّة

تعتبر إمكانيّة التحكم في جوانب مُعيّنة من الجلسة بالدّاخل من أهم مُميّزات OpenSSH التي غالبا ما لا يُلاحظها الكثيرون. يُمكن تشغيل هذه الأوامر بتقديمها برمز التحكم "~" داخل جلسة SSH. ستُفسّرُ أوامر التحكم فقط إذا كانت أول شيء مكتوب بعد سطر جديد، لذلك اضغط دائما على ENTER مرّة أو مرّتين كإجراء احتياطي. يُعطينا التحكم إمكانية وضع جلسة SSH لتعمل في الخلفيّة. وللقيّام بذلك سنحتاج إلى كتابة رمز التحكم "~" وننفّذ بعده اختصار لوحة المفاتيح (CTRL-Z) لوضع العمليّة في الخلفيّة :

[ENTER] ~[CTRL-Z] 

ما قمنا به سينقل الاتّصال ليعمل في الخلفيّة، وسيرجعنا إلى جلسة الشل المحليّة. للرجوع إلى جلسة SSH يُمكنك استعمال آليّة التّحكم. يُمكنك إعادة تفعيل آخر عمليّة محالة إلى الخلفية بكتابة: 

fg 

إذا كنت تملك أكثر من عمليّة في الخلفيّة، يُمكنك رؤية العمليّات المتاحة بكتابة: 

jobs 
[1]+ Stopped ssh username@some_host 
[2] Stopped ssh username@another_host 

يُمكنك بعد ذلك جلب أي عمليّة إلى الأمام باستعمال الدليل في العمود الأول مع رمز % :

fg %2

تعديل إعدادات إحالة منفذ على اتّصال SSH موجود

تعتبر إمكانيّة التحكم في جوانب مُعيّنة من الجلسة بالدّاخل من أهم مُميّزات OpenSSH التي غالبا ما لا يُلاحظها الكثيرون. يُمكن تشغيل هذه الأوامر بتقديمها برمز التحكم "~" داخل جلسة SSH. ستُفسّرُ أوامر التحكم فقط إذا كانت أول شيء مكتوب بعد سطر جديد، لذلك اضغط دائما على ENTER مرّة أو مرّتين كإجراء احتياطي.

هذه الميّزة تسمح لنا بالتعديل على إعدادات إحالة المنفذ بعد أن يؤسّس بالفعل اتّصال مُسبق، ويُخوّل لك إنشاء أو هدم قواعد إحالة منفذ في الوقت الفعلي. هذه القدرات جزء من واجهة سطر أوامر SSH، ويُمكن الوصول إليها خلال الجلسة باستخدام رمز التّحكم (~) و"C" :

[ENTER] ~C
ssh>

 سوف تُمنَح موجه أوامر خاص بSSH، موجه الأوامر هذا يتيح مجموعة محدودة جدّا من الأوامر، يمكنك كتابة h- من الموجه لرؤية الخيّارات المتاحة. إذا كانت المُخرجات خاليّة، سيجب عليك زيادة إسهاب (verbosity) مخرجات SSH باستخدام v~ عدّة مرّات:

[ENTER] ~v ~v ~v ~C -h

Commands: 
-L[bind_address:]port:host:hostport Request local forward -R[bind_address:]port:host:hostport Request remote forward -D[bind_address:]port Request dynamic forward -KL[bind_address:]port Cancel local forward -KR[bind_address:]port Cancel remote forward -KD[bind_address:]port Cancel dynamic forward

وكما ترى، يُمكنك بسهولة تنفيذ أي من الخيارات باستخدام الخيّار المناسب (اُنظر قسم الإحالة لمزيد من المعلومات). يُمكنك أيضا هدم نفق مع الأمر K- قبل رمز نوع الإحالة. على سبيل المثال، لإغلاق إحالة محليّة (L-)، يمكنك أن تستعمل الأمر KL-. وستحتاج إلى توفير رقم المنفذ. لضبط إحالة منفذ محلي، يمكنك استعمال:

[ENTER] ~C -L 8888:127.0.0.1:80 

يستطيع المنفذ 8888 على جهازك المحلي الآن التواصل مع خادوم الويب على المُضيف الذي تتصلُ به. عندما تنتهي، يُمكنك أن تهدم الإحالة بكتابة:

[ENTER] ~C -KL 8888

خاتمة

التعليمات أعلاه يجب أن تغطي مُعظم ما يحتاجه المستخدمون عن SSH. إذا كان لديك أي نصائح أخرى أو إذا رغبت في نشر الإعدادات والطّرق المُفضّلة لديك، خذ راحتك ولا تتردد في استخدام التعليقات أدناه.

ترجمة -مع شيءٍ من التصرّف- للقسم الثالث والأخير من مقال: SSH Essentials: Working with SSH Servers, Clients, and Keys.

حقوق الصورة البارزة: Designed by Freepik.

هذا القسم سيُغطّي بعضاً من أساسيّات الاتّصال بخادوم مع SSH، وهو تكملة لسلسلة "مدخل إلى ssh"، بعد أن تكلمنا في الدرس الأول منها عن العملاء والمفاتيح.

الاتصال بخادوم عن بعد

للاتّصال بخادوم عن بعد وفتح جلسة طرفية هناك، يمكنك استعمال أمر ssh. أبسط طريقة تفترض أنّ اسم المُستخدم الخاصّ بك هو نفسه اسم المُستخدم على الخادوم، إذا كان هذا صحيحاً، يُمكنك الاتّصال باستخدام:

ssh remote_host 

إذا كان اسم المُستخدم مختلفاً على الخادوم، ستحتاج إلى تمرير اسم مستخدم الخادوم كالتالي: 

ssh username@remote_host 

في المرة الأولى التّي تتصل بمُضيف جديد، سترى رسالة تبدو كالتّالي:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

اكتب yes لإكمال الاتّصال بالمُضيف. إذا كنت تستخدم فحص لكلمة المرور، سيُطلب منك إدخالها هنا. إذا كنت تستخدم مفاتيح SSH، سيُطلب منك إدخال كلمة المُرور لمفتاحك الخاصّ إذا كنت قد عيّنتها من قبل، إذا كان الأمر غير ذلك فستدخل آلياً إلى الخادوم.

تشغيل أمر واحد على الخادوم البعيد

لتشغيل أمر واحد على الخادوم عن بعد عوضا عن فتح جلسة طرفية، يُمكنك إضافة الأمر بعد معلومات الاتّصال: 

ssh username@remotehost الأمرالمُراد_تشغيله 

هذا الأمر سيقوم بالاتصال بالخادوم، ثم يستثيق باستخدام المعلومات وينفّذ الأمر الذي حدّدته. وسيُغلق الاتّصال مُباشرة بعد ذلك.

الدخول إلى خادوم من منفذ آخر

يقوم عفريت SSH (بالانجليزية: ssh daemon وهو برنامج يعمل في الخلف بشكل دائم على النظام) بالدّخول إلى الخادوم من المنفذ رقم 22 تلقائيّاً. عميل SSH الخاص بك سيفترض أن هذه هي الحالة عند مُحاولة الاتّصال. إذا كان خادوم SSH يستمع من منفذ غير معياريّ (سيُشرح الأمر لاحقا في قسم آخر)، سيجب عليك تحديد رقم المنفذ الجديد عند محاولة الدّخول. يُمكنك فعل هذا بتحديد رقم المنفذ مع خيّار p-:

ssh -p رقم_المنفذ username@remote_host 

لتجنّب فعل هذا في كلّ مرة تدخلُ إلى الخادوم، يُمكنك إنشاء أو تعديل ملفّ إعدادات في مُجلّد ssh./~ داخل مُجلّد المنزل في جهازك المحليّ. عدّل أو أنشئ الملفّ بكتابة: 

nano ~/.ssh/config 

يُمكنك هنا تحديد إعدادات خيارات المُضيف. لتحديد منفذ جديد، استخدم نموذجاً كالتّالي: 

Host remote_alias HostName remote_host Port port_num 

هذا سيُمكّنك من الدّخول إلى الخادوم بدون تحديد رقم المنفذ كلّ مرة من سطر الأوامر.

إضافة مفاتيح SSH إلى عميل SSH لتجنب كتابة كلمة المرور

إذا كنت تمتلك جملة مرور على المفتاح الخاص، سيُطلب منك كتابتها في كلّ مرة تحاول الاتّصال بالمُضيف. لتجنّب الأمر، يُمكنك تشغيل عميل SSH. وهو أداة صغيرة تُخزّن مفتاحك الخاص بعد كتابة كلمة المرور للمرّة الأولى. وستكون مُتاحة طوال مدة جلسة الطّرفيّة، وستخوّل لك الاتصال بدون إعادة كتابة كلمة المرور في المستقبل. هذا الأمر مهم أيضا إذا كنت تريد إحالة معلومات SSH الخاصّة بك (مُبيّنٌ أدناه). لتشغيل عميل SSH، اكتب في جلسة طرفيّة جهازك المحلي: 

eval $(ssh-agent)

هذا الأمر سيُشغّل عميل SSH في الخلفيّة. الآن عليك أن تُضيف مفتاحك الخاصّ إلى العميل لكي يتمكن من إدارتها: 

ssh-add Enter passphrase for /home/demo/.ssh/id_rsa: Identity added: /home/demo/.ssh/id_rsa (/home/demo/.ssh/id_rsa) 

سيتوجب عليك كتابة كلمة المرور (في حال عيّنتها). بعدئذٍ ملف الهوية الخاص بك سيُضاف إلى العميل متيحا لك استخدام مفتاحك بدون إعادة إدخال كلمة المرور مُجدّداً.

إحالة معلومات SSH الخاصة بك لاستخدامها على خادوم

إذا كنت ترغب في أن تكون قادراً على الاتّصال بدون كلمة مرور من خادوم إلى آخر، سيتوجب عليك إحالة معلومات SSH الخاصّة بك. ما يخوّلك للاتّصال بخادوم آخر من الخادوم الذي تتّصل به، باستخدام المعلومات على جهازك المحلي. للبدء يجب عليك أن تمتلك عميل SSH مُشغلا ومضافٌ إليه مفتاح SSH الخاص بك (انظر أعلاه). بعد الانتهاء من هذا، ستحتاج إلى الاتّصال بالخادوم الأول باستعمال خيّار A-. هذا الأمر يحيل معلوماتك إلى الخادوم للجلسة الحالية:

ssh -A username@remote_host 

من الآن يُمكنك الاتصال بمُضيف جديد مُخوّل له الوصول من مفتاح SSH وسوف تدخل كما لو أن مفتاحك الخاص موجود على الخادوم.

إعدادات جهة الخادوم Server-Side

هذا القسم يحتوي على بعض من أشهر خيارات إعدادات جهة الخادوم التي يمكن لها تشكيل طريقة استجابة الخادوم وأي من أنواع الاتّصال المسموح بها.

تعطيل فحص كلمة مرور

إذا كنت قد ضبطت مفاتيح SSH واختبرتها وتعاملت بها بشكل جيّد، يعتبر تعطيل الفحص بكلمة المرور فكرة جيّدة، هذا سيمنع أي مُستخدم من الاتصال باستخدام SSH مع كلمة مرور. لفعل هذا، اتصل بخادومك وافتح ملفّ etc/ssh/sshd_config/ بصلاحيّات الجذر: 

sudo nano /etc/ssh/sshd_config 

ابحث داخل الملفّ عن PasswordAuthentication إذا كانت تعليقا أزل رمز التعليق واجعلها no لتعطيل الدخول بكلمة المرور: PasswordAuthentication no بعد أن تقوم بالتغيير، احفظ وأغلق الملف. يجب عليك إعادة تشغيل خدمة SSH لتطبيق التغييرات. على أبنتو/دبيان: 

sudo service ssh restart 

على فيدورا / CentOS:

 sudo service sshd restart 

الآن جميع الحسابات على النظام ستمنع من الدّخول باستخدام كلمة مرور.

تغيير منفذ عفريت SSH (بالانجليزية: ssh daemon)

ينصح بعض الإداريين بتغيير منفذ SSH الافتراضي، يمكن لهذا أن يعين في تقليل عدد محاولات الاتّصال إلى خادومك من قبل البرمجيات الخبيثة. لتغيير المنفذ، سيتوجب عليك الدخول إلى الخادوم الخاص بك. ثم افتح ملفّ sshd_config على الخادوم بصلاحيات الجذر:

sudo nano /etc/ssh/sshd_config 

عندما تدخل، يمكنك تغيير المنفذ الذي يشتغل منه SSH بإيجاد مواصفة Port 22 وتغييرها إلى رقم المنفذ الذي تريد استخدامه. مثلاً لتغيير المنفذ إلى 4444، ضع هذا في ملفّك:

Port 4444 

احفظ وأغلق الملفّ عندما تنتهي. يجب عليك إعادة تشغيل SSH لتطبيق التغييرات: على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart بعد إعادة التّشغيل ستحتاج إلى إلى الفحص بتحديد رقم المنفذ (شُرح سابقاً)

تحديد المستخدمين الذين يمكن لهم الاتّصال عبر SSH

يُمكنك اتّخاذ خذ بعض الإجراءات لتحديد المُستخدمين الذين يمكنهم الاتّصال عبر SSH، ويمكن ذلك عبر تعديل ملفّ إعدادات SSH. افتح هذا الملف على الخادوم بصلاحيات الجذر: 

sudo nano /etc/ssh/sshd_config 

الطريقة الأولى لتحديد المستخدمين الذين يمكن لهم الاتّصال هي عبر خاصّية AllowUsers . ابحث عن AllowUsers في الملفّ. إذا لم يكن السّطر موجودا فأنشئه في أي مكان. أدرج بعدها اسماء المستخدمين المرغوب في السّماح لهم بالاتّصال عبر SSH:

AllowUsers user1 user2 

احفظ وأغلق الملفّ. أعد تشغيل SSH لتطبيق التغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart

إذا كنت مرتاحا مع إدارة المجموعات أكثر، يُمكنك استعمال AllowGroups . في حال كنت ترغب في ذلك أضف المجموعة التي سيُسمح لها بالاتصال (سوف ننشئ هذه المجموعة وسنضيف إليها الأعضاء بعد قليل):

 AllowGroups sshmembers 

احفظ وأغلق الملفّ. يُمكنك الآن إنشاء مجموعة (بدون مجلد منزل) توافق المجموعة التّي حدّدتها بكتابة: 

sudo groupadd -r sshmembers

تأكّد من أنّك أضفت حساب المستخدم الذي تريد إلى هذه المجموعة. يُمكن القيام بالأمر كالتالي: 

sudo usermod -a -G sshmembers user1 sudo usermod -a -G sshmembers user2 

أعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart

تعطيل ولوج الجذر root

يعد تعطيل ولوج الجذر عبر SSH منصوحا به بعد أن تضبط حساب مستخدم بميزة sudo. لفعل ذلك، افتح على الخادوم ملف إعدادات SSH باستخدام الجذر أو مع sudo .

sudo nano /etc/ssh/sshd_config

ابحث عن PermitRootLogin إذا كانت تعليقا أزل رمز التعليق واجعلها no:

PermitRootLogin no

احفظ الملف وأغلق الملف وأعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart

إتاحة وصول الجذر لأوامر معينة

هناك بعض الحالات التي قد ترغب فيها بتعطيل وصول الجذر عامّة، والسّماح لبرمجيّات معيّنة للوصول إليه لتعمل بشكل صحيح، ويُمكنك أن تأخذ النّسخ الاحتياطي كمثال. يُمكن القيّام بهذه العملية عبر ملف authorized_keys الخاصّ بمستخدم الجذر، الذي يحتوي على المفاتيح المُخوّلِ لها استخدام الحساب. أضف المفتاح الذي ترغب في استعماله من جهازك المحلي (يُنصح بإنشاء مفتاح جديد لكل عملية تلقائيّة ) إلى ملفّ authorized_keys الخاصّ بمستخدم الجذر على الخادوم. سنشرح مع أمر ssh-copy-id هنا، لكنك تستطيع أي طريقة أخرى للنسخ المفاتيح (ستُشرح في قسم آخر):

 ssh-copy-id root@remote_host 

ادخل الآن إلى الخادوم البعيد، سنحتاج إلى ضبط الدّخول على ملفّ authorized_keys لذلك افتحه باستخدام الجذر أو مع sudo. 

sudo nano /root/.ssh/authorized_keys 

في بداية سطر المفتاح الذي نسخته، أضف =command لكي تُعرّف الأمر الذي يصلح له المفتاح. يجب أن يتضمن مسار الملف القابل للتنفيذ مع أي معامل:

 command="/path/to/command arg1 arg2" ssh-rsa  

احفظ وأغلق الملفّ عندما تنتهي.

افتح ملفّ sshd_config باستخدام الجذر أو مع sudo:

sudo nano /etc/ssh/sshd_config 

ابحث عن PermitRootLogin وغيّر القيمة إلى forced-commands-only.هذه العمليّة ستسمح للمفاتيح باستخدام الجذر فقط عند تحديد أمر للمفتاح:

PermitRootLogin forced-commands-only

احفظ الملف وأغلق الملف وأعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart

إحالة تطبيق X لعرضه للعميل

يُمكن ضبط SSH لإحالة تطبيقات X وعرضها على الجهاز المحلي تلقائيّاً. لينجح الأمر يجب على العميل امتلاك مدير نوافذ X مضبوط ومتاح. لاتاحة هذه الوظيفة ادخل إلى الخادوم البعيد وعدّل ملفّ sshd_config باستخدام حساب الجذر أو مع sudo:

sudo nano /etc/ssh/sshd_config 

ابحث عن X11Forwarding إذا كانت تعليقا أزل رمز التعليق ومرّر القيمة yes:

X11Forwarding yes 

احفظ الملف وأغلق الملف وأعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart

للاتّصال بالخادوم وإحالة عرض تطبيق ما، يجب عليك تمرير مُعامل X- من جهة العميل عند الاتصال: 

ssh -X username@remote_host 

التطبيقات الرسوميّة المفتوحة على الخادوم في الجلسة الحاليّة يجبُ أن تُعرض على الجهاز المحلي. يُمكن أن يكون الأداء بطيئا قليلاً، لكنّه جيد ومجدي في بعض الحالات.

خيارات إعدادات جهة العميل

في هذا القسم، سنركّز على بعض التعديلات التي يُمكنك القيّام بها على جهة العميل من الاتّصال.

تحديد خصائص معلومات الاتّصال بالخادوم

يُمكنك تحديد إعدادات على جهازك المحلي لبعض أو لجميع الخوادم التي تتصل بها. ويُمكن تخزينُ هذه الإعدادات على ملفّ ssh/config./~ والذي يُمكن قراءته من طرف عميل SSH في كل مرة يُستدعى فيها. أنشئ أو افتح الملفّ بمحرّر نصوص على جهازك المحليّ:

nano ~/.ssh/config 

يُمكنك تحديد الإعدادات التي ترغب فيها بداخل هذا الملف بتقديم كل منها مع كلمة Host متبوعة بكنية (alias). وتحت السّطر يُمكنك تحديد أي من التّعليمات الموجودة على صفحة man ssh_config بشرط أن تكون بمسافة بادئة:

man ssh_config 

كمثال عن الإعدادات: 

Host testhost HostName example.com Port 4444 User demo 

يُمكنك بعد ذلك الاتّصال ب example.com على المنفذ 4444 باستخدام اسم المُستخدم “demo” بكتابة: 

ssh testhost

يُمكنك أيضاً استخدام حروف البدل (wildcards) لموافقة أكثر من مُضيف. تذكّر أن الموافقات اللاحقة يُمكنها الكتابة فوق السّابقة، لذلك يجب عليك أن تضع الموافقات العامّة في الأعلى. على سبيل المثال، يمكنك أن تعطل إحالة X بشكل افتراضي لجميع الاتصالات، بوضع التالي في ملفّك:

Host * ForwardX11 no
Host testhost HostName example.com ForwardX11 yes Port 4444 User demo

 احفظ وأغلق الملفّ عندما تنتهي.

إبقاء الاتّصالات حيّة لتجنّب نفاذ الوقت (Timeout)

إذا وجدت نفسك خارج جلسة SSH قبل أن تكون جاهزا لذلك، من المُحتمل أنّ وقت الاتّصال ينفذ. يُمكنك ضبط العميل لإرسال حزمة إلى الخادوم بين الحين والآخر لتجنّب هذه المسألة: يُمكنك ضبط هذا على جهازك المحليّ لكل اتّصال بتعديل ملفّ ssh/config./~. افتح الآن:

nano ~/.ssh/config 

إذا لم تملك سطرا يوافق جميع المضيفين أعلى الملفّ فقم بإضافته. ثم أضف ServerAliveInterval بقيمة "120” لإرسال حزمة إلى الخادوم كلّ دقيقتين. هذا كافٍ لإبلاغ الخادوم بعدم إغلاق الاتّصال: 

Host * ServerAliveInterval 120 

احفظ وأغلق الملفّ عندما تنتهي.

تعطيل التحقق من المضيف

في الحالة الافتراضية، كلّما اتّصلتَ بخادومٍ جديد، ستُعرضُ لك بصمة مفتاح:

SSH. The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes 

هذا الأمر مضبوط لكي تتأكد من الفحص المُضيف الذي تُحاول الاتّصال به وتجنب إمكانية أن يتنكر مستخدم خبيث في هيئة المُضيف البعيد. قد ترغب في تعطيل هذه الميزة في بعض الحالات.

ملاحظة: هذا الأمر يمكن أن يكون خطيرا جدّا أمنيا، لذلك تأكد من أنك تعرف ما تفعله إذا قُمت بضبط النظام هكذا.

 للقيّام بالأمر، افتح ملفّ ssh/config./~ على جهازك المحليّ:

nano ~/.ssh/config 

إذا لم تملك سطرا يوافق جميع المضيفين أعلى الملفّ فقم بإضافته. ثم أضف StrictHostKeyChecking بقيمة no لإضافة مضيفين جدد تلقائيّا إلى ملفّ known_hosts،  وأضف UserKnownHostsFile بقيمة /dev/null/ لعدم التحذير على مُضيف جديد أو مُضيف معدّل: 

Host StrictHostKeyChecking no UserKnownHostsFile /dev/null

يُمكنك تشغيل التحقق لكل حالة على حدة بعكس هذه الخيّارات لمضيفين آخرين. القيمة الافتراضية ل StrictHostKeyChecking هي "ask”:

Host testhost HostName example.com StrictHostKeyChecking ask UserKnownHostsFile /home/demo/.ssh/known_hosts

مضاعفة SSH خلال اتصال TCP واحد

هناك بعض الحالات التي يُمكن أن يأخذ فيها إنشاء اتّصال TCP وقتا أطول من المعتاد. إذا كنت تقوم باتّصالات متعدّدة إلى نفس الجهاز، يُمكنك استغلال ميّزة المُضاعفة. مُضاعفة SSH تقوم بإعادة استخدام نفس اتّصال TCP لجلسات SSH مُتعدّدة. وبهذا يتجنّب بعض العمل الضروري لإنشاء جلسة جديدة الشيء الذي يسرع الأمر، الحد من عدد الاتّصالات قد يكون مُجديّا أيضا لأسباب أخرى. 

لإعداد المُضاعفة، يُمكنك إعداد الاتّصالات، أو يُمكنك ضبط العميل لاستعمال المُضاعفة عندما تكون متاحة. سنشرح الخيار الثاني هنا. لإعداد المُضاعفة، عدّل ملف إعدادات عميل SSH على الحاسوب المحلي:

nano ~/.ssh/config 

إذا لم تملك سطرا يوافق جميع المضيفين أعلى الملفّ فقم بإضافته الآن (مثل Host *). سنضبط القيم ControlMaster , ControlPath و ControlPersist لإنشاء إعدادات المُضاعفة. يجب أن يكون ControlMaster بقيمة auto لتخويل المُضاعفة تلقائيّا عندما تكون متاحة. ControlPath سيكون مسار تحكم المقبس. الجلسة الأولى ستنشئ هذا المقبس وستكون الجلسات اللاحقة قادرة على إيجاده لأنه موسوم من طرف المُستخدم، المُضيف والمنفذ.

ضبط خيّار ControlPersist مع القيمة 1 ستُخوّلُ اتّصال الرئيس الأولي( initial master) ليعمل في الخلفية. 1 تعني أن اتّصال TCP يجب أن ينتهي بعد ثانية واحدة من إغلاق آخر جلسة SSH:

Host * ControlMaster auto ControlPath ~/.ssh/multiplex/%r@%h:%p ControlPersist 1

احفظ وأغلق الملفّ عندما تنتهي. نحتاج الآن لإنشاء المجلّد الذي حدّدناه في مسار التحكم:

mkdir ~/.ssh/multiplex

أي جلسة تُنشئ الآن مع نفس الجهاز ستُحاول استعمال المقبس الموجود واتّصال TCP. عندما تكون آخر جلسة موجودة، سيُهدمُ الاتّصال بعد ثانيّة واحدة. إذا كنت تريد تجنب إعدادات المُضاعفة لسبب ما مؤقتا، يُمكنك فعلُ ذلك بتمرير مُعامل S- مع قيمة none:

ssh -S none username@remote_host

تحدثنا في هذا الدرس عن كيفية إنشاء إتصال بخادوم بعيد بشكل آمن وبخيارات متعددة سواءً من جهة الخادوم أو من جهة العميل (المستخدم)، سنتحدث في المقال القادم إن شاء الله عن أنفاق ssh، ماهيتها، وكيفية إعدادها.

ترجمة -مع شيءٍ من التصرّف- للقسم الثاني من مقال: SSH Essentials: Working with SSH Servers, Clients, and Keys.

حقوق الصورة البارزة: Designed by Freepik.

يعد توفير الخدمات وإتاحة التطبيقات والموارد للمستخدمين الأهداف الأساسية لتجهيز الخواديم وإعدادها؛ إلا أن أي خادوم موصول بشبكة الإنترنت سيتعرض لا محالة لمستخدمين سيئي النيات يأملون استغلال الثغرات الأمنية للحصول على صلاحيات الدخول.

توجد الجدران النارية Firewalls بهدف حجب المنافذ Ports غير المستخدمة؛ إلا أن السؤال يُطرح عن ما يجب فعله للخدمات التي تريد الوصول إليها دون أن تكون معروضة للجميع، تريد استخدامها عند الحاجة ومنع الوصول إليها في الأوقات الأخرى.

الطرق على المنافذ Port knocking هو إحدى وسائل إخفاء الخدمات العاملة على جهازك؛ فتعمل على جعل الجدار الناري يحمي الخدمات إلى أن تطلب منه فتح منفذ عبر إرسال متتالية محدَّدة من البيانات.

سنتحدث في هذا الدليل عن كيفية إعداد آلية للطرق على المنافذ من أجل إخفاء خدمة SSH باستخدام حزمة knockd على أوبنتو 14.04.

ملحوظة: يغطي هذا الشرح الإصدار الرابع من بروتوكول IP. يفصل لينكس بين تأميني الإصدار الرابع والإصدار السادس. على سبيل المثال، لا تنطبق قواعد iptables إلا على حزم البيانات المنقولة عبر عناوين الإصدار الرابع، غير أنه يوجد مكافئ لها بالنسبة لعناوين الإصدار الرابع وهو ip6tables.

إذا كان الخادوم لديك معدا لاستخدام عناوين الإصدار السادس فلا تنس تأمين كل من واجهات Interfaces كل من الإصدارين باستخدام الأدوات المناسبة.

كيف يعمل الطرق على المنافذ؟

تتمثل فكرة الطرق على المنفذ في إعداد خدمة لمراقبة سجلات Logs الجدار الناري أو واجهات Interfaces الشبكة بحثا عن محاولات اتصال. تغير الخدمةُ قواعدَ الجدار الناري، إذا جرت محاولات اتصال معرَّفة مسبقا (تعرف بالطرْقات Knocks)، من أجل السماح بالاتصالات عبر منفذ معيَّن.

تسمح هذه الطريقة بالإبقاء على الخدمات مخفية إلى الوقت الذي تريد استخدمها فيه. لا يناسب هذا الإعداد خواديم الويب التي يُسمَح عادة لجميع الاتصالات بالوصول إليها؛ إلا أنها مفيدة للخدمات الموجهة فقط لمستخدمين معروفين وبصلاحيات محددة، على سبيل المثال خدمة SSH.

لا ينبغي جعل الطرق على المنافذ التدبير الوحيد لتأمين الخدمات، رغم أن متتالية الطرق يمكن أن تكون معقدة جدا. تنفذ الخدمات عادة طرق تأمين واستيثاق خاصة بها تُعرَض للمستخدم بعد إرساله متتالية الطرق الصحيحة. يضيف الطرق على المنافذ، في هذا الإطار، طبقة جديدة يجب أن يمر بها المستخدم قبل أن يرى طريقة الاستيثاق المعتادة.

يوفر الطرق على المنافذ ميزة أخرى مفيدة هي أنه لا يُصدِر أي ردود على محاولات الطرق. إذا حاول متسلل فحص المنافذ فسيرى أنها مغلقة وإن إحاول تخمين متتالية الطرق فيجب عليه التحقق بعد كل تخمين لمعرفة إن كان المنفذ فُتِح أم لا؛ الأمر الذي سيكون كافيا في أغلب الحالات ليمنع المهاجمين من الدخول ويصرف أنظارهم عن إعادة المحاولة.

سنستخدم خلال هذا الشرح الجدار الناري المدمج افتراضيا مع أوبنتو (iptables) ونثبت برنامج knockd لتوفير وظيفة الطرق على المنافذ.

إعداد IPTables لمنع أغلب الاتصالات

نحتاج، قبل أن نبدأ في إعداد آلية للطرق على المنافذ، إلى ضبط قاعدي للجدار الناري. سنمنع كل الاتصالات تقريبا.

يأتي جدار IPTables الناري مضمنا في أوبنتو إلا أنه لا توجد افتراضيا أي قاعدة مما يعني أنه يُسمَح لجميع الاتصالات بالمرور. يمكنك تعلم كيفية إعداد جدار ناري باستخدام IPTables على Ubuntu 14.04 .

نبدأ بالسماح بالاتصال عبر الجهاز المحلي. يعني هذا القبول بالبيانات المرسَلة من الخادوم نفسه وهو ما يسمح للخدمات العاملة على الخادوم بالتواصل في ما بينها.

sudo iptables -A INPUT -i lo -j ACCEPT

يضيف الأمر أعلاه قاعدة إلى سلسلة INPUT التي تتعامل مع جميع الاتصالات القادمة إلى الخادوم. تطلب القاعدة التي أضفناها من iptables قبول جميع البيانات القادمة من الواجهة المحلية lo التي تستخدم للاتصالات الداخلية.

الخطوة التالية هي السماح لكل الاتصالات الجارية بالاستمرار؛ لذا ننفذ الأمر:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

تطلب القاعدة الموجودة في الأمر أعلاه من iptables السماح للاتصالات الجارية والبيانات المتعلقة بها بالمرور. هذه القاعدة مهمة ليمكننا مواصلة الاتصال بالخادوم عن بعد باستخدام SSH حتى لا نفقد الاتصال به عند بدء حظر الاتصالات.

ثم نضيف قواعد للسماح بالخدمات الموجهة للعموم، أي تلك التي لا يوجد شرط على مستخدميها مثل خادوم الويب (إن وُجد) الذي يعمل عادة على المنفذ رقم 80:

sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

احذر أن تضيف قواعد للخدمات التي ستستخدم الطرق على المنافذ للوصول إليها. ستكون إضافةُ هذه القواعد مهمةَ خدمة الطرق التي ستعدل قواعد الجدار الناري حسب الطلب. لهذا السبب لن نضيف خادوم SSH إلى إعداد iptables.

حتى هذه اللحظة لم نضف سوى قواعد تقبل الاتصال ولم نضف أي قواعد لحظر الاتصالات. وهو ما يعني أن الجدار الناري لا زال يقبل جميع الاتصالات؛ بعضها مذكور صراحة، وهي تلك التي أضفناها.

سنمنع الآن جميع الاتصالات، ما عدا تلك التي حددناها في الأوامر السابقة:

sudo iptables -A INPUT -j DROP

يعني هذا أن جميع محاولات الاتصال التي لا توافق إحدى القواعد المذكورة سابقا ستُحظَر. تمكن معاينة القواعد بتنفيذ الأمر:

sudo iptables -S

النتيجة:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -j DROP

لاحظ أنه لا توجد حتى الآن قاعدة في إعدادات الجدار الناري تسمح باتصالات SSH.

أنهينا الآن قواعد الجدار الناري، بقي أن نجعلها دائمة حتى لا يعاد تعيينها عند إعادة تشغيل الخادوم. نستخدم أداة iptables-persistent لهذا الغرض. نفذ الأمر التالي لتثبيتها:

sudo apt-get install iptables-persistent

ثم شغل الخدمة بعد انتهاء التثبيت:

sudo service iptables-persistent start

تثبيت خدمة Knockd

يدعى البرنامج الذي سنستخدمه لتمكين آلية للطرق عبر المنافذ knockd. ثبته بتنفيذ الأمر التالي:

sudo apt-get install knockd

لا يشغَّل البرنامج مباشرة بعد ثبيته وذلك حتى لا يحظُر بيانات كثيفة على الفور. يجب أن تضبط الخدمة وتفعلها يدويا.

إعداد Knockd لاستخدام الطرق على المنافذ

يوجد ملف إعداد يجب تحريره لإعداد الخدمة:

sudo nano /etc/knockd.conf

يجب أن يظهر لديك ملف بمحتوى شبيه بالتالي:

[options]
UseSyslog

[openSSH]
sequence    = 7000,8000,9000
seq_timeout = 5
command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
tcpflags    = syn

[closeSSH]
sequence    = 9000,8000,7000
seq_timeout = 5
command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
tcpflags    = syn

في المقطع [options] توجد تعليمة باسم UseSyslog تخبر خدمة knockd أن عليها استخدام الوسائل الاعتيادية لحفظ السجلات. ينتج عن هذه التعليمة إدراج السجلات ضمن المجلد var/log/messages/.

إذا أردت حفظ السجلات في مكان مغاير فيمكنك ذلك باستخدام التعليمة التالية بدلا من UseSyslog (حيث path/to/log/file/ مسار ملف السجلات):

LogFile = /path/to/log/file

ثم يأتي مقطعان يُستخدَمان لتجميع قواعد تُطابِق جميعها حدثا واحدا. لا يؤثر اسم المقطع على عمله إلا أنه يفيد لإعطاء نبذة لمن يفتح الملف عن عمل المقطع.

يوجد في ملف الإعداد الافتراضي مقطع يفتح منفذ SSH وآخر لغلق نفس المنفذ.

المعطى الذي يعيّن نمط الطرق هو التالي:

sequence    = 7000,8000,9000

يعني النمط أعلاه أن مجموعة القواعد هذه ستبحث ما إذا كان نفس عنوان IP طلب الاتصال على المنفذ رقم 7000 متبوعا مباشرة بالمنفذ 8000 ثم أخيرا المنفذ 9000. سنغير متتالية الطرق لتصبح على النحو التالي:

sequence    = 2022,3022,4022

يوجد معطيان آخران في المجموعة يراقبان النشاط:

seq_timeout = 5
tcpflags = syn

يحدد المعطى الأول مدة زمنية يجب أن تكتمل فيها متتالية طلبات الاتصال المعرفة في المعطى السابق. أما المعطى الثاني فيحدد خيارا يجب أن يتواجد في حزم tcp حتى تكون صالحة (يستخدم هذا الخيار لمعرفة الطريقة التي يجب بها التعامل مع الحزم وحالتها). يشيع استخدام القيمة syn للتفريق بين الحزم التي نريدها وتلك التي تنشئها برامج مثل SSH في الخلفية.

ثم نجد الأمر:

command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

يجب أن تتعرف على قاعدة من قواعد iptables. يمكن إذن تفسير المقطع بأنه عند إرسال متتالية الطرق في الوقت المحدد فسينفذ الأمر أعلاه من أجل السماح باتصالات SSH.

إذا تفطنت لإعدادات iptables فسترى أن القاعدة الجديدة تستخدم الخيار A- لإلحاق القاعدة بنهاية سلسلة INPUT؛ وهو ما يعني أنها ستكون بعد القاعدة التي تحظر كافة الاتصالات.

سنحتاج للتعديل على الأمر وإبدال القاعدة بأخرى تُدرَج في بداية الملف؛ لذا سنستخدم الخيار I- ونعلم القاعدة على أنها القاعدة رقم 1:

command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPT

ستُضاف قاعدة جديدة للسماح بقبول اتصالات SSH من المسخدِم الذي أرسل متتالية الطرق. الجزء %IP% الموجود في القاعدة سيُبدَل بعنوان IP الذي أتت منه متتالية الطرق.

المقطع الأخير يؤدي عملا مشابها بمتتالية مغايرة وأمر يعمد إلى حذف قاعدة فتح اتصالات SSH من iptables. سنستخدم المتتالية 4022,3022,2022 لإنهاء الاتصال الذي أنشأناه وغلق المنفذ المرتبط به (أي المنفذ رقم 22).

يجب تغيير المتتاليات الموجودة افتراضيا في المقاطع وإبدالها بأخرى عشوائية. ترك المتتالية الموجودة افتراضيا في ملف الإعداد يجعل من تنفيذ آلية طرق المنافذ هذه بلا فائدة (الجميع يعرف المتتالية الافتراضية).

أغلق الملف (CTRl + X) ثم احفظه (CTRL +O).

تشغيل خدمة Knockd

يمكننا الآن بعد أن أنهينا إعداد knockd للحصول على مجموعة قواعد صالحة اختبارُ الإعداد بتشغيل الخدمة. تذكر أن الإعداد الافتراضي صالح إلا أنه لن يكون آمنا إلا إذا غيرت متتالية الطرق الافتراضية لكل مقطع.

يجب التعديل على ملف آخر لتفعيل الخدمة:

sudo nano /etc/default/knockd

نغير قيمة الخيار START_KNOCKD لتصبح 1:

START_KNOCKD=1

أغلق الملف (CTRl + X) ثم احفظه (CTRL +O).

يمكننا الآن تشغيل الخدمة، لذا ننفذ الأمر:

sudo service knockd start

يشغل الأمر خدمة knockd ويسمح بتغيير قواعد الجدار الناري عند الطرق على المنافذ حسب المتتالية المعرَّفة في ملف الإعداد.

اختبار الطرق على المنافذ

سنرى الآن ما إذا كان بإمكاننا التعديل على قواعد iptables بالطرق على المنافذ المعرفة في ملف الإعداد. أبق - احترازا - على اتصالك الجاري بالخادوم نشطا وافتح نافذة جديدة للطرفية.

توجد الكثير من الأدوات للاستخدام في طرق المنافذ؛ ومن أشهرها nmap، netcat وعميل آخر صُمِّم خصيصا للطرق واسمه knock.

سنستخدم أداة knock ولكن قبل ذلك فلنتأكد أولا من أن منفذ SSH مغلق فعليا.

ssh root@server_ip_address

يجب أن تكون النتيجة على النحو التالي:

ssh: connect to host server_ip_address port 22: Operation timed out

يعني هذا أن الخادوم لم يُجِب وأن المهلة الممنوحة للاتصال انقضت. يعود السبب إلى أن خدمة SSH محظورة على الخادوم حسب قواعد iptables. اضغط على زري CTRL وC للعودة إلى الطرفية إن طالت مدة محاولة الاتصال.

أداة Knock لطرق المنافذ

أداة knock وسيلة سهلة للطرق على المنافذ يطورها نفس فريق knockd. تُضَمَّن هذه الأداة في حزمة knockd؛ لذا يمكن تثبيتها على الجهاز العميل مثل ما فعلنا على الخادوم:

sudo apt-get install knockd

يمكن أيضا تنزيل الأداة من الموقع الرسمي الذي توجد به إصدارات لكل من Windows وOS X؛ وكذلك لأندرويد وiOS.

تُستخدَم أداة knock على النحو التالي:

knock server_ip_address sequence

حيث sequence متتالية الطرق وserver_ip_address عنوان IP الخادوم. بالنسبة لمثالنا سيكون الاستخدام على النحو التالي:

knock server_ip_address 2022 3022 4022

ولإغلاق المنفذ نرسل المتتالية التي حددناها في ملف الإعداد:

knock server_ip_address 4022 3022 2022

إعداد Knockd لغلق الاتصالات تلقائيا

تأكدنا الآن من أن خدمة الطرق تعمل. سنغير الإعدادات لجعلها أكثر صلابة.

أعد فتح ملف الإعداد على الخادوم

sudo nano /etc/knockd.conf

يتيح knockd إمكانية تحديد مدة زمنية يُنفَّذ أمر محدد بعد انقضائها؛ نستفيد من هذه الميزة للاكتفاء بقاعدة واحدة لفتح وإغلاق منفذ SSH؛ مما يعني أننا لن نحتاج لإرسال متتالية الطرق حتى يغلَق المنفذ.

يمكن حذف مقاطع openSSH وcloseSSH ضمن ملف الإعداد لأننا سنبدلها بمقطع وحيد نسميه SSH:

[options]
UseSyslog

[SSH]

سنعرِّف داخل مقطع SSH متتالية للطرق، خيار tcpflags ومهلة زمنية للانتظار ينبغي الطرق على المنافذ خلالها؛ مثل ما فعلنا مع المقطعين السابقين. سنضيف أيضا الأمر المستخدَم لفتح منفذ SSH:

[options]
    UseSyslog

[SSH]
    sequence = 5438,3428,3280,4479
    tcpflags = syn
    seq_timeout = 15
    start_command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPT

اختر متتالية منافذ فريدة. حددنا في هذا المثال أربعة منافذ. تمكن زيادتها حسب رغبتك ولكن انتبه إلى أنه يجب طرق المنافذ خلال المدة الزمنية (بالثواني) المحدَّدة ضمن معطى seq_timeout.

معطى start_command هو نفسه معطىcommand الذي رأيناه في الأمثلة السابقة؛ الفرق الوحيد هو أن الاسم أكثر إسهابا.

يأتي الآن دور المعطيات الجديدة التي ستساعدنا على غلق المنفذ:

[options]
UseSyslog

[SSH]
sequence = 5438,3428,3280,4479
tcpflags = syn
seq_timeout = 15
start_command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPT
cmd_timeout = 10
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

يحدد معطى cmd_timeout الثواني التي ستنتظرها خدمة knockd قبل تنفيذ الأمر الموجود ضمن معطى stop_command.

النتيجة هي أنه عند إرسال المتتالية الصحيحة فإن المنفذ سيُفتح لمدة 10 ثوان ثم يُغلق من جديد.

احفظ الملف ثم أغلقه.

أعد تشغيل الخدمة لاعتماد القواعد الجديدة:

sudo service knockd restart

يمكن استخدام الأمر التالي للاتصال ضمن الوقت المحدد:

knock server_ip_address 5438 3428 3280 4479 && ssh root@server_ip_address

سيغلق المنفذ بعد 10 ثوان من الاتصال.

خاتمة

يُنظَر إلى الطرق على المنافذ على أنه مجرد إخفاء للخدمات بدل تأمينها؛ على الرغم من ذلك يبقى وسيلة رائعة لإضافة طبقة أمان جديدة ضد الهجمات العشوائية.

يجب دائما تأمين خدماتك عبر الوسائل الأمنية المتاحة في النظام إلا أن إضافة مِصيدة مثل الطرق على المنافذ أمام التدابير الأمنية المعتادة يمكن أن يقلل بقدر ملحوظ هجمات القوة القاسية ومحاولات التسلل التي يتعرض لها خادومك.

ترجمة - بتصرف - لمقال How To Use Port Knocking to Hide your SSH Daemon from Attackers on Ubuntu.

SSH عبارة عن بروتوكول آمن يُستخدم كوسيلة أساسيّة للاتصال بخوادم لينكس عن بُعد. SSH تُقدّمُ واجهة نصّية بحيثُ تعطيك الصّلاحيّة لكتابة أي أوامر وتنفيذها مباشرة على الخادوم. بعد الاتصال، جميع الأوامر التي تكتبها على الطرفيّة محليّاً تُرسل إلى الخادوم عن بعد وتُنفّذ هناك. 
في هذا الدّليل السّريع، سنُغطّي بعضاً من أكثر وسائل الاتّصال بSSH شيوعاً لتحقيق أهدافك. هذا المقال يُمكن أن يُستعمل كمرجع سريعٍ كلّما احتجت إلى معرفة كيفية الاتصال بخادومك أوضبطه بطرق مختلفة.

$ ssh-keygen

Generating public/private rsa key pair. 
Enter file in which to save the key (/home/demo/.ssh/id_rsa): 

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 

Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a root@here
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|       +         |
|      o S   .    |
|     o   . * +   |
|      o + = O .  |
|       + = = +   |
|      ....Eo+    |
+-----------------+

ssh-keygen -b 4096 

Overwrite (y/n)? 

ssh-keygen -p 
Enter file in which the key is (/root/.ssh/id_rsa): 

Enter old passphrase: 

Enter new passphrase (empty for no passphrase): 
Enter same passphrase again:

ssh-keygen -l 
Enter file in which the key is (/root/.ssh/id_rsa): 

4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e demo@test (RSA) 

ssh-copy-id username@remote_host 

The authenticity of host ‘111.111.11.111 (111.111.11.111)’ can’t be established. 
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. 
Are you sure you want to continue connecting (yes/no)? yes 
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed 
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys 
demo@111.111.11.111’s password: 

Number of key(s) added: 1

Now try logging into the machine, with: "ssh ‘demo@111.111.11.111’"
and check to make sure that only the key(s) you wanted were added. 
يُمكنك الآن الدّخول إلى الحساب بدون كلمة مرور: 
ssh username@remote_host

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

The authenticity of host ‘111.111.11.111 (111.111.11.111)’ can’t be established. 
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. 
Are you sure you want to continue connecting (yes/no)? yes 
demo@111.111.11.111’s password: 

ssh username@remote_IP_host

cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test 

mkdir -p ~/.ssh 

echo سلسلة_المفتاح_العام >> ~/.ssh/authorized_keys 

ssh username@remote_IP_host