نحتاج في بعض الأحيان نقل البيانات من خلال مقبس بين الأجهزة المختلفة ، مثل اتصال Telnet أو تنزيل ملف FTP أو استعلام SQL أو أي نوع آخر من أنواع النقل.
تنتقل هذه البيانات الخام عبر الشبكة ، لذلك غير آمن، مما يعني أنه يمكن اعتراضها من قبل أي عقدة على المسار بين الأصل والوجهة ، أي ، مسروق.
لا يمكننا منع التقاط هذه البيانات ، ولكن ما يمكننا منعه هو أن يتم تفسيرها وفهمها من قبل أطراف ثالثة ، مما يؤدي إلى تشفير الاتصال.
SSH هي الأداة التي تتيح لنا القيام بذلك اتصالات آمنة بين الآلات. الاستخدام الأكثر شيوعًا هو الاتصال عن بُعد بمترجم أوامر.
ومع ذلك ، فإنه يوفر إمكانيات أخرى ، مثل الإنشاء الأنفاق المشفرة بين الآلات المختلفة.
افترض أننا نريد telnet من host1 إلى host2:
host1$ telnet host2
هذا التواصل مفتوح تمامًا ويمكن أن يكون كذلك تم اعتراضها. لحمايته ، سنعيد توجيه منفذ تم اختياره عشوائيًا (على سبيل المثال 5000) على المضيف 1 إلى المنفذ 23 (telnet) على host2.
بهذه الطريقة ، سنحصل على جميع البيانات المرسلة إلى المنفذ 5000 للمضيف 1 للسفر مشفرة عبر النفق الذي يفتح ssh عبر المنفذ 22 للمضيف 2 ثم نعيد توجيهه إلى المنفذ 23 للمضيف 2 ، وبالتالي نصل إلى وجهته النهائية.
للقيام بذلك ، نحتاج إلى معرفة اسم المستخدم وكلمة المرور الخاصين بـ host2.
لفتح النفق نكتب:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
اوه حسنا:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
كلا الخيارين متكافئان. لتأسيس اتصال telnet ، لم نعد نشير إلى host2 بل إلى المنفذ المختار على host1:
host1$ telnet localhost 5000
مع هذا نجعل أي اتصال آمنًا ، سواء كان ذلك عن بُعد أو غير ذلك. التحقيق أكثر بقليل سنرى ذلك بفضل قوة SSH يمكن أيضًا إجراء عمليات إعادة التوجيه هذه للأجهزة الثالثة ، مما يتيح لنا من خلال نقطة دخول واحدة الوصول بأمان من شبكة LAN بأكملها إلى شبكة LAN مختلفة.
تبدو النظرية مثيرة للاهتمام للغاية ، لكنها ستكون أكثر أهمية إذا رأينا حالة عملية.
لكن الحقيقة هي أنه على الرغم من قصري ، فقد أحببت المقال.
ربما عند النظر إلى الويكي تحصل على الإلهام https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
ونفس الشيء ، ولكن قسم autossh https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
في الواقع ، أي شيء يمكنك إرساله عن طريق ssh ، سواء كان ذلك متدفقًا ، أو اتصالات بالمضيف. إلخ لأنك تريد تشفيرها لسبب س.
وقواعد securecrt
أحيانًا أستخدم SSH على مستوى أساسي جدًا. المنفذ الافتراضي هو 22 ، أليس كذلك؟
لذا ، إذا فهمت بشكل صحيح ، أن جهاز الكمبيوتر الخاص بي هو المضيف 1 والجهاز الذي أريد الاتصال به هو host2 ، فإن هذا النفق سيخلق اتصالًا بين المنفذ 5000 ومنفذه 23 ، ثم ينتهي به المطاف في المنفذ 22؟
لماذا اسباب تبديل المنافذ؟ هل يمكنك إنشاء نفق باستخدام المنفذ 22؟
مقال مشوق جدا. مثل نانو ، أريد المزيد!
يستخدم SSH بالفعل المنفذ 22 افتراضيًا (على الرغم من أنه يمكن تغييره). هذا المنفذ هو المنفذ الذي سيتم استخدامه من خلال الاتصال الفعلي بين المضيفين. إنه الشخص الذي يجب عليك التأكد من أنه مفتوح ولا يوجد جدار ناري يقطعه. لكن بالنسبة للمستخدم فهو شفاف تمامًا. يمكنك نسيانه. في المثال ، تتم إعادة التوجيه بين المنفذين 5000 و 23. هذان هما المنفذان الوحيدان اللذان يجب أن تقلق بشأنهما. سيرى المستخدم أن كل ما يرسله إلى المنفذ 5000 لمضيفه يظهر في 23 من مضيف الوجهة.
من الواضح أن كل مستخدم يمكنه إعادة توجيه المنافذ التي يراها مناسبة.
شكرا لتعليقاتكم. هذه أول مشاركة لي وستساعد آرائك في تحسين المنشور التالي.
هل يمكن فعل ذلك أيضًا باستخدام VPS؟
حسنًا ، هذه حالتي ، PC1 لديه حق الوصول إلى الخادم ، لكن PC2 لا ، كلاهما متصل بواسطة ssh ، أريد الوصول إلى PC2 ، ولكن أي منفذ من PC1 يمكنني إعادة توجيهه؟ إذا كان ما أريده حقًا هو الوصول إلى منفذ الخادم من PC2 وأن الحزم بها PC1 كمصدر IP. هل أفهم؟
أنت تفهم نفسك. في هذه الحالة ، تحتاج إلى PC1 لإعادة توجيه منفذ PC2 إلى المنفذ 22 من الخادم:
PC2 $ ssh -L 5000: الخادم: 22 مستخدمًا PC1 @ PC1
والحفاظ على هذا الاتصال مفتوحًا من محطة طرفية أخرى:
PC2 $ ssh userServer @ localhost -p 5000
وأنت بالفعل بالداخل.
أخيرا حل وظيفي !! شكراً Getafix ، لقد منحتني عالماً من الاحتمالات !!
أنا سعيد!
مقالة ممتازة. مرحبا بك في DesdeLinux <img draggable="false" class="emoji" alt="" src="https://s.w.org/images/core/emoji/2.2.1/svg/1f600.svg">
وماذا نفعل إذا تم حظر 22 لدينا؟ هههه..
شكرا ايلاف.
إذا كان المنفذ 22 محظورًا ، mmmm ، فسيتعين علينا البحث عن بديل لاختراق جدار الحماية XD
والأسوأ من ذلك كله (افتراضي): أنه تم حظره من قبل مزود VPS.
لقد أجريت اختبارًا قبل بضع ساعات بأسئلة عنه 😛
لم اكن لأقول هكذا:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
وهو يعادل سطر الأوامر الآخر ... الذي يحتوي على -L.
نظرًا لأن -R يشير إلى أن المنفذ المفتوح للاتصالات الجديدة موجود على الجانب البعيد ، أي على جانب خادم ssh الخاص بك ؛ بينما يفتح -L منفذًا على الجانب المحلي ، من جانب العميل لاستقبال اتصالات جديدة.
ترجمة الخط:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
سيكون شيئًا من هذا القبيل: كونك على host1 ، اتصل بخادم ssh (المنفذ 22) للمضيف 2 مع المستخدم الخاص بي userhost2 وأعد توجيه الاتصالات التي تم إنشاؤها على المنفذ البعيد 5000 للمضيف 2 إلى المنفذ 23 على المضيف 1 (مضيفي المحلي)
إذا لم يكن كذلك ، صححني! 😉
-
من ناحية أخرى ... إذا قام الخادم بحظر دخول الاتصالات إلى المنفذ 22 ، فلا يمكننا الاتصال عن بُعد بخادم ssh ؛ ما يمكن عمله هو يتم تنفيذ سطر أوامر من الخادم (مسؤول مسؤول صديق خلف جدار الحماية لنظام host2 البعيد):
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f يذهب إلى الخلفية
-N لا ينفذ أي أمر على جهاز التحكم عن بعد
يمنع nohup مقاطعة تنفيذ الأمر عند تسجيل الخروج
host1 $ ssh userhost2 @ localhost -p 6000
بهذه الطريقة ، من host1 ، ننشئ اتصالًا بالمضيف المحلي (نفس المضيف 1) على المنفذ 6000 والذي سيعيد توجيه الاتصال إلى المنفذ 22 لمضيف النظام البعيد 2 ، حيث سنقوم بتسجيل الدخول باستخدام مضيف المستخدم 2.
سيسمح هذا (لم أجربه ، لكن يبدو أنه يعمل) لتسجيل الدخول إلى خادم ssh محظور بواسطة جدار الحماية مع القليل من المساعدة من الداخل! 😀
هذا الأخير قرأته من شرح في مجلة The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
أنا حقا أحب المنشور الخاص بك. أقرأها كثيرًا!
تحية.
أنت محق. هناك خطأ في المقال. عمليات إعادة التوجيه ليست مكافئة. الأمر host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 ينفذ إعادة التوجيه العكسي ، أي أنه يعيد توجيه المنفذ البعيد 5000 إلى 23 المحلي ، وهو عكس ما يفعله الأمر -L.
شكرا للتصحيح.