स्क्रीन, या समान, स्वचालित रूप से एक परतदार ssh कनेक्शन को फिर से शुरू करने के लिए

Question

मुझे अक्सर एक अविश्वसनीय वाईफाई वातावरण में ssh पर सर्वर से कनेक्ट करना पड़ता है। सर्वर पर, मैं स्क्रीन चलाता हूं, इसलिए यदि मैं डिस्कनेक्ट हो जाता हूं, तो मैं स्क्रीन सत्र को फिर से कनेक्ट और फिर से शुरू कर सकता हूं, और जहां मैंने छोड़ा था, वहां से उठा सकता हूं, लेकिन कनेक्शन का नुकसान अभी भी एक प्रमुख समय सिंक है: यदि कनेक्शन मैं बाहर निकल जाता है सर्वर पर, टर्मिनल विंडो जम जाती है। मुझे उस टैब को मारना है, एक नया खोलना है, फिर से सर्वर पर भेजना है और स्क्रीन सेशन फिर से शुरू करना है। मैंने सर्वर पर स्क्रीन चलाने और स्थानीय स्तर पर स्क्रीन के साथ इसकी कोशिश की है। किसी भी तरह से जब कनेक्शन बाहर निकल जाता है तो यह जम जाता है।

क्या मेरे पास स्क्रीन के समान कोई चीज हो सकती है, या हो सकता है कि स्क्रीन ही हो, जो स्वचालित रूप से फिर से कनेक्ट करने और सत्र को चालू रखने का प्रयास करेगा, इसलिए मुझे मैन्युअल रूप से पुन: कनेक्ट करने की आवश्यकता नहीं है? अक्सर जब मैं कनेक्शन खो देता हूं तो मुझे लगता है कि यह केवल बहुत ही संक्षिप्त अवधि के लिए है - शायद एक सेकंड से भी कम।

मैं Ubuntu 14.04 LTS, MATE संस्करण का उपयोग कर रहा हूं। धन्यवाद

Comments

"शेल विंडो फ्रीज हो जाती है": ऐसा इसलिए है क्योंकि आपके स्थानीय ssh को पता नहीं है कि कनेक्शन मृत है। हिट <Enter>और ~.कनेक्शन छोड़ने के लिए अपना पक्ष बताने के लिए टाइप करें, और आप बस फिर से कनेक्ट करने के लिए अंतिम ssh कमांड को दोहरा सकते हैं (जैसे कि अप-एरो के साथ !!)।

— एलेक्सिस

@alexis जो फिर से जोड़ने के लिए एक तेज़ तरीके की तरह लगता है, धन्यवाद! मैं इसे स्वचालित रूप से हालांकि प्यार करता हूँ ...

— मैक्स विलियम्स

Answer 1

आप का उपयोग कर देख सकते हैं mosh: https://mosh.org/

आप एक विश्वसनीय इंटरनेट कनेक्शन के साथ 'जंप' सर्वर सेट कर सकते हैं जिसे आप moshकनेक्ट करने के लिए उपयोग करते हैं, फिर sshआपके द्वारा प्रबंधित प्रत्येक सर्वर पर सत्र होते हैं। मेरे द्वारा जंप सर्वर का उपयोग करने का कारण यह है कि आप moshउन सर्वरों पर इंस्टॉल नहीं करना चाहते हैं जिन्हें आप प्रबंधित कर रहे हैं।

इसका एक और फायदा moshयह है कि यह टीसीपी के बजाय यूडीपी पर आधारित है, और आपका सत्र आईपी पते के परिवर्तन से बच सकता है, उदाहरण के लिए वाईफाई से मोबाइल इंटरनेट कनेक्शन पर जाना।

बस इसे स्पष्ट करने के moshलिए screen, प्रतिस्थापन के लिए नहीं है , बल्कि ssh। यह अभी भी screenइसके साथ उपयोग करने के लिए एक अच्छा विचार है , क्योंकि moshयदि ग्राहक किसी कारण से मर जाता है, तो अपने सत्र को फिर से जोड़ने का एक तरीका प्रदान नहीं करता है।

Comments

धन्यवाद, यह सिर्फ एक सर्वर है (ज्यादातर समय) और हम इसके मालिक हैं इसलिए मुझे Mosh इंस्टॉल करने में सक्षम होना चाहिए। मैं इसे देख लूँगा।

— मैक्स विलियम्स

वास्तव में यह पता चला है कि क्योंकि हमारे सर्वर काफी पुराना है (या एक पुराने Ubuntu मैं कहना चाहिए) यह स्थापित करने के लिए बहुत मुश्किल है। :(

— मैक्स विलियम्स

@MaxWilliams कितना पुराना है? यहां तक ​​कि एलटीएस 12.4 भी समर्थन से बाहर हो गया है। और सिर्फ खुद को संकलित करने का प्रयास क्यों न करें

— phuclv

जैसा कि मैंने mosh डॉक्स पढ़ा है, आपको प्रत्येक होस्ट पर mosh-server की आवश्यकता है जिसे आप दूरस्थ रूप से प्रबंधित करना चाहते हैं। फिर भी, निश्चित रूप से दिलचस्प है।

— वाइल्डकार्ड

Mosh पर एक tmux टर्मिनल से कनेक्ट करना मेरे लिए सबसे स्थिर समाधान है।

— निमो

Answer 2

मैं tmuxअब कुछ वर्षों से उपयोग कर रहा हूं और मेरे अनुभव में, यह स्वचालित रूप से फिर से जुड़ता है। कम से कम जब कनेक्शन केवल अपेक्षाकृत संक्षिप्त समय के लिए विफल हो जाता है। ध्यान दें कि मैं वास्तव byobuमें बैकएंड के रूप में tmux का उपयोग करता हूं । मुझे नहीं पता कि यह मजबूती दोनों के संयोजन की या यहां तक ​​कि एक विशेषता है tmuxया नहीं byobu, लेकिन मेरा सुझाव है कि आप दोनों को एक कोशिश दें।

मैं अपने स्थानीय आर्क से एक वीपीएन के माध्यम से विभिन्न दूरस्थ उबंटू सर्वरों से जोड़ता हूं। जब मैंने रिमोट से कनेक्ट किया था, तब मैंने अपने नेटवर्क केबल को अनप्लग करके अभी-अभी इसका परीक्षण किया था। सत्र लटका दिया गया, लेकिन जैसे ही मेरी केबल को फिर से प्लग किया गया, यह निर्बाध रूप से फिर से शुरू हो गया।

हालांकि, जब मैंने अपने राउटर को पुनरारंभ करके परीक्षण किया, तो कनेक्शन वापस नहीं आया। मुझे लगता है कि यह कुछ समय के लिए नेटवर्क के साथ क्या करना है, लेकिन यह केवल कुछ सेकंड नीचे है, तो फिर से कनेक्ट करने के लिए लगता है।

यदि यह प्रासंगिक है, तो मैं terminatorअपने टर्मिनल एमुलेटर के रूप में इसका उपयोग करता हूं।

तीनों उबंटू रिपॉजिटरी में उपलब्ध हैं:

sudo apt-get install tmux terminator byobu

हालांकि, मैं सभी को यकीन है पर नहीं कर रहा हूँ कि या तो tmuxया byobussh डिस्कनेक्शन से निपटने में बेहतर कर रहे हैं। मुझे केवल इतना पता है कि मेरे अनुभव में, वे अक्सर छोटे कनेक्शन के नुकसान से वापस आते हैं। हालांकि मेरे विन्यास के अन्य पहलुओं के लिए नीचे हो सकता है।

Comments

जब आप अपने राउटर को फिर से शुरू करते हैं तो आपको एक अलग सार्वजनिक आईपी पता दिया जा सकता है, जिससे tcpकनेक्शन टूट गया होगा । मेरे अनुभव sshसे आंतरायिक नेटवर्क ड्रॉप आउट के लिए बहुत लचीला हो सकता है, मुझे नहीं लगता कि इस तथ्य से कोई लेना-देना नहीं है कि आप खिड़की के tmuxअंदर उपयोग कर रहे sshहैं।

— जंग खाए शेलकेफोर्ड

मैं भी यही कहने जा रहा था: यहां तक ​​कि सादे एसएसएच के साथ, आप एक छोटे से डिस्कनेक्शन से निपट सकते हैं, जब तक कि टीसीपी कनेक्शन मर नहीं जाता है। जो यह हो सकता है, यदि आपका इंटरफ़ेस शटडाउन हो जाता है, या कुछ अति उत्साही राउटर इसे मारता है (NAT रूटर्स रिबूट पर NAT राज्य भूल सकता है, और मौजूदा कनेक्शन तोड़ सकता है), या ClientAlive/ ServerAliveट्रिगर, या ... मुझे नहीं पता कि क्या byobuकरता है, हालांकि ।

— इलकाचू ०

हां, लेकिन ओपी किसी भी कनेक्शन विफलता पर ठंड का अनुभव कर रहा है, जबकि मैं नहीं। लेकिन हां, आप सही कह रहे हैं, मैं इसे साधारण ssh और नो tmux के साथ भी देखता हूं। फिर भी, शायद स्क्रीन इसके साथ सौदा नहीं कर सकती है?

— terdon

@ मैक्सविलियम्स tmuxमूल रूप से screenहां के लिए एक अधिक आधुनिक विकल्प है । जब मैंने पहली बार काम करना शुरू किया, तो मुझे अब इस तरह की जरूरत थी, मेरे सरसरी तौर पर पढ़ने का सुझाव था कि tmuxइन दिनों बेहतर विकल्प है। मैं यह भी नहीं 100% यकीन है कि यह खो कनेक्शन का बेहतर प्रबंधन है, मुझे पता है कि यह मेरे अनुभव में संक्षिप्त आउटेज से उबरता है। चाहे वह नीचे हो tmuxया कुछ और, मुझे नहीं पता। लेकिन यह कोशिश करने लायक लगता है :)। बायोबू मूल रूप से स्क्रीन / tmux का एक दृश्य है, न कि GUI टर्मिनल एमुलेटर। यह बहुत उपयोगी है, हालांकि: byobu.org

— terdon

कनेक्शन रुकावट के बारे में tmux कुछ नहीं करता है। यह ssh द्वारा प्रदत्त टर्मिनल डिवाइस के साथ काम करता है। यह सब ssh कनेक्शन के साथ खड़ा है और गिरता है।

— जोनास श्फर

Answer 3

ServerAliveकनेक्शन विफल होने पर पता लगाने के लिए ssh के विकल्पों का उपयोग करें ।

ServerAliveCountMax
सर्वर जीवित संदेशों की संख्या निर्धारित करता है (नीचे देखें) जो ssh (1) के बिना भेजा जा सकता है जो सर्वर से कोई संदेश प्राप्त करता है। यदि सर्वर लाइव संदेश भेजे जा रहे हैं, तो यह सीमा समाप्त हो गई है, तो सत्र समाप्त करते हुए, सर्वर से ssh डिस्कनेक्ट हो जाएगा। यह ध्यान रखना महत्वपूर्ण है कि सर्वर जीवित संदेशों का उपयोग TCPKeepAlive (नीचे) से बहुत अलग है। एन्क्रिप्टेड चैनल के माध्यम से सर्वर जिंदा संदेश भेजे जाते हैं और इसलिए यह खराब नहीं होगा। TCPKeepAlive द्वारा सक्षम टीसीपी रखने का विकल्प स्पूफ है। सर्वर जीवित तंत्र मूल्यवान है जब ग्राहक या सर्वर यह जानने पर निर्भर करता है कि कनेक्शन कब निष्क्रिय हो गया है।

डिफ़ॉल्ट मान है 3. यदि, उदाहरण के लिए, ServerAliveInterval (नीचे देखें) 15 पर सेट है और ServerAliveCountMax डिफ़ॉल्ट पर छोड़ दिया जाता है, यदि सर्वर अप्रतिसादी हो जाता है, तो ssh लगभग 45 सेकंड तक डिस्कनेक्ट हो जाएगा।

ServerAliveInterval
सेकंड में टाइमआउट अंतराल सेट करता है जिसके बाद यदि सर्वर से कोई डेटा प्राप्त नहीं हुआ है, तो ssh (1) सर्वर से प्रतिक्रिया का अनुरोध करने के लिए एन्क्रिप्टेड चैनल के माध्यम से एक संदेश भेजेगा। डिफ़ॉल्ट 0 है, यह दर्शाता है कि ये संदेश सर्वर पर नहीं भेजे जाएंगे।

यदि आप ServerAliveInterval5 पर सेट करते हैं, sshतो नेटवर्क 15 सेकंड के लिए बाहर निकलता है, तो स्वचालित रूप से डिस्कनेक्ट हो जाएगा।

Comments

बल द्वारा SSH सत्र को तोड़ने के लिए, मैं दबाता हूं ~.(या पहले दर्ज करें, फिर ~.): जिसमें से बचने के चरित्र ~और सत्र को तोड़ने की आज्ञा हो.

— imz - Ivan Zakharyaschev

@ imz - IvanZakharyaschev यह मानता है कि आप बता सकते हैं कि कनेक्शन लटका हुआ है। SSH के रखवाले का उपयोग करने से विफलता का स्वतः पता चल जाएगा।

— बमर

यह वास्तव में उपयोगी लगता है, धन्यवाद, मैं निश्चित रूप से कोशिश करूंगा कि अगली बार मैं "परतदार क्षेत्र" में हूं।

— मैक्स विलियम्स

@ बरमार हां, सच। मैंने यह निर्धारित करने की समस्या के बारे में भी सोचा है कि क्या कनेक्शन वास्तव में लटका हुआ है, या मुझे कुछ दबाने से गलती से इन कुंजियों को दूरस्थ पक्ष में भेजा जा सकता है ... और मुझे एक अच्छा समाधान नहीं पता है।

— इम्ज़ - इवान ज़खरीशेव

Answer 4

इसी तरह की स्थितियों में, मैं eshellEmacs के अंदर TRAMP (ssh) के साथ उपयोग करता हूं। रिमोट शेल के लिए वांटेड कमांड्स देने के लिए ट्रम्प ने आवश्यकता पड़ने पर फिर से कनेक्ट करने का ध्यान रखा।

हालाँकि, एक टर्मिनल के रूप में eshell अच्छा नहीं है, अर्थात, रनिंग कमांड के लिए जो टर्मिनल के साथ कुछ विशेष करता है, या जो कि महत्वपूर्ण समय के लिए लगातार (वृद्धिशील) कुछ प्रिंट कर रहा है।

असल में, यह Emacs में TRAMP के साथ उपयोग करना शुरू करने के लिए काफी सरल है:

M-x eshell
cd /user@host:

Answer 5

अस्वीकरण

यदि आपका SSH कनेक्शन संक्षिप्त नेटवर्क आउटेज से नहीं बच रहा है, तो कुछ और चल रहा है जो sshटीसीपी को अपनी सामान्य बात नहीं करने देता है।

जानकारी के लिए नीचे देखें। वैसे भी:

सबसे तेज और सबसे गंदा नहीं निर्भरता समाधान

इस तरह एक शेल स्क्रिप्ट बनाएं:

#!/bin/sh -

# Tune these numbers depending on how aggressively
# you want your SSH session to get reconnected.
timeout_options='-o ServerAliveInterval=4 -o ServerAliveCountMax=2'

# 255 is the status OpenSSH uses to signal SSH errors, which
# means we want to connect. All other exit statuses suggest
# an intentional exit.
status=255

# Keep opening the SSH connection and immediately dropping into
# `screen` until an intentional exit happens.
while [ "$status" = 255 ]
do
    ssh $timeout_options -t "$@" screen -dR
    status=$?
    # You can add a `sleep` command here or a counter or whatever
    # you might need as far as rate/retry limiting.
done
exit "$status"

यह सिर्फ एक बेवकूफ-सरल लूप चलाएगा जो कि के साथ जुड़ने sshऔर संलग्न करने की कोशिश करता रहता है screen। होस्ट या जो कुछ भी आप सामान्य रूप से अपने sshमंगलाचरण को कमांड-लाइन तर्क के रूप में पास करेंगे।

पुन: कनेक्ट बस इस बात पर आधारित है कि क्या SSH कनेक्शन के साथ कोई त्रुटि रिपोर्ट करता है, जिसका अर्थ है कि इसमें गैर-SSH त्रुटियों का पता लगाने के लिए कोई बुद्धिमत्ता नहीं है जैसे "आप का शाब्दिक रूप से WiFI चालू नहीं है" या जो भी हो, लेकिन वह संभवतः इसके लिए कोई मायने नहीं रखता है। आप।

मैं मान रहा हूँ कि आपके पास ssh-agentया एक नो-पासफ़्रेज़ SSH कुंजी है जो आपको अतिरिक्त इनपुट के बिना बस काम करने के लिए पुन: संयोजन की अनुमति देगा।

एक छोटी दौड़ की स्थिति होने जा रही है, जहां अगर आप ^Cएक पुन: कनेक्ट के दौरान बस दूसरे के सही मानव-अगोचर अंश के दौरान हिट ^Cकरते हैं, तो आप क्लाइंट टर्मिनल से गुजरने के बजाय स्क्रिप्ट को मार सकते हैं , इसलिए यदि आपको एक कनेक्शन लटका हुआ है। ^Cबहुत उत्साह से मैश न करें ।

सरलतम अतिरिक्त सॉफ्टवेयर समाधान

आप प्रोग्राम ऑटोस को आज़मा सकते हैं , जो आपके उबंटू पैकेज रिपॉजिटरी में उपलब्ध होना चाहिए।

यदि आपको स्रोत से निर्माण करने या इसे ऑडिट करने की आवश्यकता है, तो यह एक एकल सी प्रोग्राम है जो बिना किसी अतिरिक्त पुस्तकालयों के निर्भरता के रूप में संकलित करता है, लगता है कि मेरे हैक के मुकाबले कनेक्शन आजीविका की जाँच करने के बारे में अधिक बुद्धिमत्ता है, और यह एक सुविधाजनक rscreenस्क्रिप्ट कमांड के साथ भी काम करता है जो ऑटो -करना screen।

विवरण

कैसे sshसामान्य रूप से ठीक हो जाता है

बस सत्यापित करने के लिए, क्योंकि मुझे खुद को जांचे बिना चीजें कहना पसंद नहीं है, मैंने जवाब देने से पहले थोड़ा परीक्षण किया:

मैंने लिनक्स डिवाइस के साथ अपने वाईफाई पर प्रवेश किया, अपने लैन पर एक अन्य डिवाइस के लिए एसएसएच कनेक्शन बनाया, सत्यापित किया कि मेरे पास sshदूसरे छोर पर काम करने का कनेक्शन है (कमांड आदि चला सकता है), फिर क्लाइंट पर वाईफाई डिस्कनेक्ट कर दिया (इंटरफ़ेस के कारण) डी-कॉन्फ़िगर किया जाना: कोई और आईपी पते नहीं), ssh सत्र में एक अधिक वर्णों को टाइप किया (कोई प्रतिक्रिया नहीं, निश्चित रूप से), और फिर मेरे वाईफाई से पुन: कनेक्ट किया गया - खराब सिग्नल और अन्य कारकों के कारण कम से कम एक बार पुन: संयोजन विफल हो गया , फिर अंत में फिर से जुड़ गया: मैंने sshसत्र के ठीक होने में लगभग पांच सेकंड इंतजार किया , ऐसा कुछ नहीं हुआ जिससे मैंने एक और कुंजी को मारा, और sshसत्र तुरंत फिर से जीवित हो गया, सभी कुंजियों के साथ जो मैंने कमांड लाइन पर दिखाई देने वाले डिस्कनेक्ट के दौरान टाइप किया था।

देखें, sshबस टीसीपी नेटवर्क सॉकेट में लिखता है / पढ़ता है जब तक कि ओएस यह नहीं बताता कि कुछ गलत हुआ है, और टीसीपी वास्तव में लंबे समय तक कनेक्शन की बूंदों के प्रति बहुत सहिष्णु है।

डिफ़ॉल्ट कर्नेल सेटिंग्स के साथ अपने उपकरणों के लिए छोड़ दिया लिनक्स में टीसीपी स्टैक खुशी से कनेक्शन को मृत घोषित करने से पहले कई मिनटों के लिए पूरी तरह से चुपचाप सहन करेगा और एक त्रुटि की रिपोर्ट करेगा ssh- जब तक यह अंत में हम ballpark में बात कर रहे हैं ~ 30 मिनट का, या कम से कम निश्चित रूप से लंबे समय तक पर्याप्त है एक दूसरे या एक मिनट तक चलने वाली हिचकी।

कवर के नीचे, लिनक्स टीसीपी स्टैक धीरे-धीरे संदेशों को लंबे और लंबे समय तक देरी से हटाता है, हालांकि, जिसका अर्थ है कि जब तक आपका कनेक्शन वापस नहीं आता है, तब तक आप अपने sshसत्र को फिर से "जीवित" आने से पहले अतिरिक्त अंतराल देख रहे होंगे ।

यह कभी-कभी क्यों टूटता है

अक्सर कुछ सक्रिय रूप से उस कनेक्शन को बंद करने का कारण बनता है जो टीसीपी स्टैक को बर्दाश्त करने वाली राशि की तुलना में कुछ हद तक निष्क्रियता के बाद बंद हो जाएगा, और फिर उस कनेक्शन को अपने sshक्लाइंट को रिपोर्ट करने में विफल हो सकता है।

संभावित उम्मीदवारों में शामिल हैं:

1. फायरवॉल या नेटिंग राउटर, जिन्हें प्रत्येक लाइव टीसीपी कनेक्शन को याद रखने के लिए मेमोरी का उपयोग करना पड़ता है - एक अनुकूलन और डॉस हमलों के खिलाफ कुछ शमन के रूप में, वे कभी-कभी आपके कनेक्शन को भूल जाएंगे , और फिर चुपचाप इसके लिए परिणामी पैकेटों को अनदेखा करेंगे, क्योंकि पैकेट में एक कनेक्शन के बीच में जब आपको कनेक्शन याद नहीं है तो मौजूदा लुक अमान्य है।

2. बेहतर व्यवहार करने वाले फायरवॉल / राउटर एक टीसीपी आरएसटी पैकेट को इंजेक्ट करेंगे, जो आम तौर पर एक connection reset by peerत्रुटि संदेश के रूप में प्रकट होता है , लेकिन रीसेट पैकेट आग और भूल जाता है, इसलिए यदि आपके क्लाइंट का कनेक्शन अभी भी उस पल में समस्या हो रही है और गिरता है पैकेट रीसेट करें, आपके ग्राहक को लगेगा कि कनेक्शन अभी भी जीवित है।

3. सर्वर ही अपने ग्राहक संबंध जारी रखने के लिए कोशिश कर रखता है, लेकिन सर्वर ने सिर्फ यह है: एक फ़ायरवॉल नीति चुपचाप अप्रत्याशित पैकेट, जो ग्राहक के संबंध बहाली के प्रयास टूट जाएगा ड्रॉप करने के लिए जब भी सर्वर ने कनेक्शन बंद सोचता है लेकिन ग्राहक नहीं है हो सकता है इसे अनदेखा करना क्योंकि इन पैकेटों का सर्वर के फ़ायरवॉल स्थिति में कोई लाइव कनेक्शन नहीं है।

   चूंकि आप लिनक्स चला रहे हैं, अपने सर्वर iptables/ ip6tables(या nftयदि आप नए सामान का उपयोग कर रहे हैं) को ध्यान से देखें कि क्या आप बनाम छोड़ने की अनुमति दे रहे हैं। यह अनुमति देने के लिए बहुत ही आम है नई / स्थापित / संबंधित टीसीपी SSH बंदरगाह पर पैकेट, लेकिन नहीं "अवैध" लोगों - आप चुपचाप सब कुछ है कि अनुमति नहीं है छोड़ने कर रहे हैं, यह आम सेटअप संक्षिप्त कनेक्शन समस्याओं के बाद फ्रीज़ इन प्रकार के कारण हो सकता है ।

4. टीसीपी या एसएसएच क्लाइंट कीपैलिव पैकेट के लिए ओपनएसएसएच विकल्पों में से एक का उपयोग करने के बाद, आपके एसएसएच सर्वर को निष्क्रियता की अवधि के बाद कनेक्शन बंद करने के लिए कॉन्फ़िगर किया जा सकता है। अपने आप से यह अनिश्चित हैंग का कारण नहीं होगा, लेकिन यह आपको ऊपर वर्णित राज्यों में से एक में डाल सकता है।

5. यह संभव है कि आप अपने राज्य में आने के बाद इसे "अनहंग" के लिए पर्याप्त समय नहीं दे रहे हों, जहां आपका sshसत्र लटका हुआ है।