يمكنني استخدام نفق SSH من العمل للتجول في مختلف جدران الحماية العاطفية (كل شيء على مايرام مع مديري :)). المشكلة هي ، بعد فترة من الوقت توقف الاتصال ssh عادة ، وكسر النفق.
إذا تمكنت على الأقل من مراقبة النفق تلقائيًا ، فيمكنني إعادة تشغيل النفق عندما يتم تعليقه ، لكنني لم أحسب طريقة للقيام بذلك.
نقاط المكافأة للشخص الذي يمكن أن تخبرني كيف تمنع اتصال ssh من تعليقه ، بالطبع!
تنسى جميع جدران الحماية ذات الحالة عن الاتصال بعد عدم رؤية حزمة لهذا الاتصال لبعض الوقت (لمنع جداول الحالة من أن تصبح كاملة من الاتصالات حيث انتهى كلا الطرفين دون إغلاق الاتصال). معظم TCP سوف ترسل التطبيقات رزمة keepalive بعد وقت طويل دون سماع من الجانب الآخر (2 ساعة هي قيمة شائعة). ومع ذلك ، إذا كان هناك جدار حماية ذي حالة والذي ينسى الاتصال قبل أن يتم إرسال الحزم keepalive ، فسوف يموت اتصال قديم ولكن خاملاً.
إذا كان هذا هو الحال ، فإن الحل هو منع الاتصال من أن يصبح خاملاً. يحتوي OpenSSH على خيار يسمى ServerAliveInterval والذي يمكن استخدامه لمنع الاتصال من الخمول لفترة طويلة جدًا (على سبيل المكافأة ، سوف يكتشف متى توفي النظير عاجلاً حتى إذا كان الاتصال خاملاً).
على جهاز mac أو linux الخاص بك ، قم بتكوين ssh الخاص بك ، واحتفظ بالخادم ssh على قيد الحياة كل 3 دقائق. افتح محطة وانطلق بصمتك غير المرئية في منزلك:
cd ~/.ssh/
ثم قم بإنشاء ملف تكوين سطر واحد مع:
echo "ServerAliveInterval 180" >> config
يجب عليك أيضا إضافة:
ServerAliveCountMax xxxx (high number)
الافتراضي هو 3 لذلك سيتوقف ServerAliveInterval 180 عن الإرسال بعد 9 دقائق (3 من الفاصل الزمني 3 دقائق المحدد بواسطة ServerAliveInterval).
لقد استخدمت البرنامج النصي Bash التالي للحفاظ على أنفاق ssh الجديدة عند وفاة السابقة. يكون استخدام البرنامج النصي مفيدًا عندما لا تريد أو لا يمكنك تثبيت حزم إضافية أو استخدام برنامج التحويل البرمجي.
while true
do
ssh <ssh_options> [[email protected]]hostname
sleep 15
done
لاحظ أن هذا يتطلب ملفًا أساسيًا لإنشاء الاتصال تلقائيًا ولكن هذا هو الحال مع autossh أيضًا.
Systemd مناسبة بشكل مثالي لهذا الغرض.
قم بإنشاء ملف خدمة /etc/systemd/system/sshtunnel.service
يحتوي على:
[Unit]
Description=SSH Tunnel
After=network.target
[Service]
Restart=always
RestartSec=20
User=sshtunnel
ExecStart=/bin/ssh -NT -o ServerAliveInterval=60 -L 5900:localhost:5900 [email protected]
[Install]
WantedBy=multi-user.target
(تعديل الأمر ssh لتناسب)
sshtunnel
لذلك تأكد من وجود المستخدم أولاًsystemctl enable sshtunnel
لتعيينه للبدء في وقت التمهيدsystemctl start sshtunnel
للبدء على الفورتحديث Jan 2018 : قد تستخدم بعض توزيعات (مثل Fedora 27) سياسة SELinux لمنع استخدام SSH من systemd init ، وفي هذه الحالة سوف تحتاج إلى إنشاء سياسة مخصصة ل تقديم الإعفاءات اللازمة.
من المؤكد أنه يبدو لي أنك جميعًا تسيء تفسير ServerAliveCountMax. كما فهمت مستندات ، هو عدد رسائل الخادم على قيد الحياة التي يمكن أن تمر دون إجابة دون إنهاء الاتصال. لذلك في حالات مثل أننا نناقش هنا ، سيؤدي تعيينه إلى قيمة عالية إلى ضمان عدم اكتشاف اتصال معلق وإنهائه!
ببساطة ، يجب أن يكون إعداد ServerAliveInterval كافيًا لحل المشكلة مع نسيان جدار الحماية للاتصال ، كما أن ترك ServerAliveCountMax منخفضًا سيتيح للطرف الأصلي أن يلاحظ الفشل وينتهي في حالة فشل الاتصال على أي حال.
ما تريده هو ، 1) للاتصال يبقى مفتوحًا بشكل دائم في الظروف العادية ، 2) لاكتشاف فشل الاتصال والجانب الأصلي للخروج عند الفشل ، و 3) لإصدار الأمر ssh في كل مرة مخارج (كيف تقوم بذلك تعتمد على النظام الأساسي ، النص "الحقيقي" الذي اقترحته Jawa هو إحدى الطرق ، على OS XI فعليًا إعداد عنصر launchd).
استخدم دائمًا خيار ServerAliveInterval
SSH في حالة إنشاء مشكلات النفق بجلسات منتهية الصلاحية NAT.
استخدم دائمًا طريقة للاستجابة في حالة انقطاع الاتصال تمامًا ، لديك ثلاثة خيارات على الأقل هنا:
while true do ssh ...; sleep 5; done
) بإزالة أمر السكون ، ssh
قد يفشل بسرعة وسوف تتفاعل مع الكثير من العمليات/etc/inittab
، للوصول إلى صندوق يتم شحنه وتثبيته في بلد آخر ، خلف NAT ، دون إعادة توجيه المنفذ إلى المربع ، يمكنك تكوينه لإنشاء نفق ssh إليك:
tun1:2345:respawn:/usr/bin/ssh -i /path/to/rsaKey -f -N -o "ServerAliveInterval 180" -R 55002:localhost:22 [email protected] 'sleep 365d'
البرنامج النصي المبتدئ على أوبونتو ، حيث /etc/inittab
غير متوفر:
start on net-device-up IFACE=eth0
stop on runlevel [01S6]
respawn
respawn limit 180 900
exec ssh -i /path/to/rsaKey -N -o "ServerAliveInterval 180" -R 55002:localhost:22 [email protected]
post-stop script
sleep 5
end script
أو دائما استخدام كلتا الطريقتين.
لقد حللت هذه المشكلة مع هذا:
تصحيح
~/.ssh/config
و أضف
ServerAliveInterval 15
ServerAliveCountMax 4
وفقًا لـ صفحة man لـ ssh_config:
ServerAliveCountMax
Sets the number of server alive messages (see below) which may be
sent without ssh(1) receiving any messages back from the server.
If this threshold is reached while server alive messages are
being sent, ssh will disconnect from the server, terminating the
session. It is important to note that the use of server alive
messages is very different from TCPKeepAlive (below). The server
alive messages are sent through the encrypted channel and there‐
fore will not be spoofable. The TCP keepalive option enabled by
TCPKeepAlive is spoofable. The server alive mechanism is valu‐
able when the client or server depend on knowing when a connec‐
tion has become inactive.
The default value is 3. If, for example, ServerAliveInterval
(see below) is set to 15 and ServerAliveCountMax is left at the
default, if the server becomes unresponsive, ssh will disconnect
after approximately 45 seconds. This option applies to protocol
version 2 only.
ServerAliveInterval
Sets a timeout interval in seconds after which if no data has
been received from the server, ssh(1) will send a message through
the encrypted channel to request a response from the server. The
default is 0, indicating that these messages will not be sent to
the server. This option applies to protocol version 2 only.
ExitOnForwardFailure yes
هو ملحق جيد للاقتراحات الأخرى. إذا كان يتصل ولكن لا يمكنه إنشاء إعادة توجيه المنفذ ، فهذا لا فائدة لك تمامًا كما لو أنه غير متصل على الإطلاق.
قليلا من الاختراق ، لكنني أحب استخدام الشاشة للحفاظ على هذا. لدي حاليًا جهاز توجيه بعيد يعمل منذ عدة أسابيع.
مثال ، البدء محليا:
screen
ssh -R ......
عند تطبيق إعادة التوجيه عن بُعد ، ويكون لديك Shell على الكمبيوتر البعيد:
screen
Ctrl + a + d
لديك الآن إلى الأمام عن بعد دون انقطاع. الحيلة هي تشغيل الشاشة على كلا الطرفين
حدثت هذه المشكلة مؤخرًا بنفسي ، لأن هذه الحلول تتطلب منك إعادة إدخال كلمة المرور في كل مرة إذا استخدمت كلمة مرور لتسجيل الدخول ، استخدمت sshpass في حلقة مع نص مطالبة لتجنب وجود كلمة المرور في ملف الدُفعات.
اعتقدت أنني سأشارك الحل الخاص بي في هذه الحالة في حال كان لدى أي شخص آخر نفس المشكلة:
#!/bin/bash
read -s -p "Password: " pass
while true
do
sshpass -p "$pass" ssh [email protected] -p port
sleep 1
done
لقد كنت بحاجة للحفاظ على SSH- نفق طويل الأجل. تم تشغيل حل بلدي من خادم Linux ، وهو مجرد برنامج C صغير يستجيب ssh باستخدام المصادقة المستندة إلى المفاتيح.
لست متأكدًا من التعليق ، لكنني تعرضت لأنفاق تموت بسبب المهل.
أرغب في توفير الرمز للمُجيب ، لكن لا يمكنني العثور عليه الآن.
في حين أن هناك أدوات مثل autossh تساعد على إعادة تشغيل جلسة ssh ... ما أجد أنه مفيد حقًا هو تشغيل الأمر "screen". يتيح لك استئناف جلسات الـ ssh الخاصة بك حتى بعد قطع الاتصال. مفيد بشكل خاص إذا كان اتصالك غير موثوق به كما ينبغي.
... لا تنس أن تضع علامة على هذا هو الجواب "الصحيح" إذا كان يساعدك ك! ؛-)
نظرًا لأن autossh
لا يلبي احتياجاتنا (يوجد خطأ إذا كان لا يمكنه الاتصال بالخادم في المحاولة الأولى) ، فقد كتبنا تطبيق bash خالص: https://github.com/aktos-io/link-with-server
يقوم بإنشاء نفق عكسي لمنفذ sshd الخاص بـ NODE (22) على الخادم بشكل افتراضي. إذا كنت بحاجة إلى تنفيذ أي إجراءات أخرى (مثل إعادة توجيه المنافذ الإضافية ، وإرسال رسائل البريد على الاتصال ، وما إلى ذلك) ، يمكنك وضع البرامج النصية on-connect
و on-disconnect
المجلدات.
لقد واجهت مشاكل مماثلة مع مزود خدمة الإنترنت السابق. بالنسبة لي كان الأمر نفسه مع أي اتصال tcp ، أو زيارة مواقع الويب أو إرسال البريد.
كان الحل هو تكوين اتصال VPN عبر UDP (كنت أستخدم OpenVPN). كان هذا الاتصال أكثر تسامحا مع كل ما تسبب في قطع الاتصال. ثم يمكنك تشغيل أي خدمة من خلال هذا الاتصال.
لا تزال هناك مشكلات في الاتصال ، ولكن نظرًا لأن النفق سيكون أكثر تسامحًا ، فإن أي جلسة ssh ستشهد توقفًا قصيرًا بدلاً من قطع الاتصال.
للقيام بذلك ، ستحتاج إلى خدمة VPN عبر الإنترنت يمكنك إعدادها على الخادم الخاص بك.