Kesintisiz ssh bağlantısını otomatik olarak sürdürmek için ekran veya benzeri


18

Genellikle güvenilmez bir wifi ortamında ssh üzerinden bir sunucuya bağlanmak zorundayım. Sunucuda, ekranı çalıştırırım, bu yüzden bağlantı kesilirsem, ekran oturumunu yeniden bağlayabilir ve devam ettirebilirim ve kaldığım yerden devam edebilirim, ancak bağlantı kaybı hala büyük bir zaman alıcıdır: sunucudayım, terminal penceresi donma eğilimindedir. Bu sekmeyi öldürmek, yeni bir sekme açmak, sunucuya tekrar ssh ve ekran oturumuna devam etmek zorundayım. Ben sunucu ve ekran yerel olarak çalışan ekran ile bunu denedim. Her iki durumda da bağlantı düştüğünde donma eğilimindedir.

Ekrana benzer bir şeye sahip olabileceğim herhangi bir yol var mı, yoksa ekranın kendisi otomatik olarak yeniden bağlanmaya ve oturumu çalışmaya devam etmeye çalışacak, bu yüzden manuel olarak yeniden bağlanmaya devam etmeme gerek yok mu? Çoğunlukla bağlantıyı kaybettiğimde bunun çok kısa bir süre için olduğunu düşünüyorum - belki bir saniyeden az.

Ubuntu 14.04 LTS, MATE sürümünü kullanıyorum. Teşekkürler


4
Re "kabuk penceresi donma eğilimindedir": Çünkü yerel ssh bağlantınızın öldüğünü bilmiyor. Hit <Enter>ve tip ~.(-yukarı ok veya örneğin bağlantıyı kesmek için tarafını anlatmaya ve sadece tekrar bağlanma son ssh komutu tekrarlayabilirsiniz !!).
alexis

@alexis yeniden bağlanmak için daha hızlı bir yol gibi geliyor, teşekkürler! Yine de otomatik olarak olmasını isterdim ...
Max Williams

Yanıtlar:


23

Şunu kullanarak görebilirsiniz mosh: https://mosh.org/

moshBağlanmak için kullandığınız güvenilir bir internet bağlantısına sahip bir 'atlama' sunucusu kurabilir , ardından sshyönettiğiniz her sunucuda oturumlar yapabilirsiniz. Bir atlama sunucusu kullanmanızı öneririm mosh, yönettiğiniz sunuculara yüklemek istemeyebilirsiniz .

Diğer bir avantajı, moshTCP yerine UDP'ye dayanması ve oturumunuzun IP adresindeki bir değişiklikten kurtulabilmesidir, örneğin WiFi'den mobil internet bağlantısına gitmek.

Sadece açıklığa kavuşturmak moshiçin screen, bunun yerine değil ssh. Bununla screenbirlikte kullanmak hala iyi bir fikirdir , çünkü moshmüşteri bir nedenden ötürü ölürse oturumunuza yeniden bağlanmanın bir yolu yoktur.


Teşekkürler, sadece bir sunucu (çoğu zaman) ve biz kendi Mosh yüklemek gerekir böylece sahibi. Onu ben kontrol edecegim.
Max Williams

Aslında, sunucumuz oldukça eski olduğu (veya söylemeliyim ki eski bir Ubuntu çalıştırdığı için) kurulumu çok zor olduğu ortaya çıkıyor. :(
Max Williams

@MaxWilliams kaç yaşında? LTS 12.4 bile destek dışı kaldı. Ve neden sadece kendiniz derlemeye
çalışmıyorsunuz

Ben mosh belgelerini okurken, uzaktan yönetmek istediğiniz her ana bilgisayarda mosh-sunucuya ihtiyacınız var. Yine de, kesinlikle ilginç.
Wildcard

1
Bir tmux terminaline mosh üzerinden bağlanmak benim için en kararlı çözüm.
Nemo

3

tmuxBirkaç yıldır kullanıyorum ve tecrübelerime göre, otomatik olarak yeniden bağlanıyor. En azından bağlantı nispeten kısa bir süre için başarısız olduğunda. Aslında byobuarka uç olarak tmux ile kullandığımı unutmayın . Bu sağlamlık bir özelliği olup olmadığını bilmiyorum tmuxya byobuhatta ikisinin kombinasyonu, ama ikisi de bir deneyin öneririz.

Yerel Arch kurulumumdan bir VPN üzerinden çeşitli uzak Ubuntu sunucularına bağlanıyorum. Uzaktan kumandaya bağlıyken ağ kablosunu çıkararak test ettim. Oturum kapatıldı, ancak kablonuz tekrar takılır takılmaz sorunsuz bir şekilde devam etti.

Ancak, yönlendiricimi yeniden başlatarak test ettiğimde bağlantı geri dönmedi. Ağın ne kadar süre kapalı kaldığıyla ilgili bir şey olduğunu varsayıyorum, ancak sadece birkaç saniye azalırsa yeniden bağlanıyor gibi görünüyor.

İlgili olması durumunda, tüm bunları terminatorterminal öykünücüm olarak kullanarak yaparım .

Üçü de Ubuntu depolarında mevcuttur:

sudo apt-get install tmux terminator byobu

Ancak, ya ssh bağlantılarını ele almakta ya tmuxda byobudaha iyi olduğundan hiç emin değilim . Sadece deneyimlerime göre, genellikle kısa bağlantı kayıplarından kaynaklandıklarını biliyorum. Bu benim konfigürasyonumun diğer yönlerine bağlı olabilir.


1
Yönlendiricinizi yeniden başlattığınızda, bağlantıyı kesecek farklı bir genel IP adresi verilmiş olabilir tcp. Deneyimlerimden ssharalıklı ağ çıkışlarına çok dirençli olabileceğinden, bunun pencerenin tmuxiçinde kullandığınız gerçeği ile ilgisi olduğunu düşünmüyorum ssh.
paslı shackleford

3
Aynı şeyi söyleyecektim: Düz SSH ile bile, TCP bağlantısı kesilmediği sürece kısa bir bağlantı kopmasıyla başa çıkabilirsiniz. Hangisi Arayüz kapatma alır veya bazı hevesli yönlendirici bunu öldürürse, (NAT router yeniden başlatma üzerinde NAT devlet unutabilir ve mevcut bağlantıları kırmak) olabilecek veya ClientAlive/ ServerAliveI fikrim yok ... tetikleyicileri ya byobuda, does .
ilkkachu

Evet, ancak OP, herhangi bir bağlantı arızasında donma yaşıyor gibi görünüyor, ben yokken. Ama evet, haklısın, bunu basit ssh ve tmux ile de görüyorum. Yine de, belki ekran bununla başa çıkamaz?
terdon

2
@MaxWilliams tmuxtemel olarak daha modern bir alternatiftir screen, evet. Şimdi yaptığım gibi çalışmaya başladığımda ve bu tür bir şeye ihtiyaç duyduğumda, el yazısı okumam tmuxbu günlerde daha iyi bir seçim olduğunu önerdi . Ayrıca, kayıp bağlantıların daha iyi yönetimine sahip olduğundan% 100 emin değilim, tek bildiğim, deneyimimdeki kısa kesintilerden kurtuluyor. Bu tmuxya da başka bir şey olsun, bilmiyorum. Ama denemeye değer gibi görünüyor :). Byobu temelde bir GUI terminal emülatörü değil, ekran / tmux'un bir ön ucudur. Yine de son derece yararlıdır: byobu.org
terdon

2
tmux bağlantı kesintileri hakkında hiçbir şey yapmaz. Ssh tarafından sağlanan terminal cihazı ile çalışır. Her şey durur ve ssh bağlantısı ile düşer.
Jonas Schäfer

2

ServerAliveBağlantının ne zaman başarısız olduğunu tespit etmek için ssh seçeneklerini kullanın .

ServerAliveCountMax
Ssh (1) sunucudan herhangi bir ileti almadan gönderilebilen sunucu canlı ileti sayısını (aşağıya bakın) ayarlar. Sunucu canlı iletileri gönderilirken bu eşiğe ulaşılırsa, ssh sunucunun bağlantısını keserek oturumu sonlandırır. Sunucu canlı iletileri kullanımının TCPKeepAlive'den (aşağıda) çok farklı olduğuna dikkat etmek önemlidir. Sunucu canlı iletileri şifrelenmiş kanal üzerinden gönderilir ve bu nedenle kimlik sahtekarlığı yapılmaz. TCPKeepAlive tarafından etkinleştirilen TCP tutma seçeneği taklit edilebilir. Sunucu canlı mekanizması, istemci veya sunucu bir bağlantının ne zaman devre dışı kaldığını bilmeye bağlı olduğunda değerlidir.

Varsayılan değer 3'tür. Örneğin, ServerAliveInterval (aşağıya bakın) 15 olarak ayarlanırsa ve ServerAliveCountMax varsayılan olarak bırakılırsa, sunucu yanıt vermezse, ssh yaklaşık 45 saniye sonra bağlantı kesilir.

ServerAliveInterval
Sunucudan veri alınmazsa, ssh (1), sunucudan yanıt istemek için şifreli kanal üzerinden bir mesaj gönderecek saniye cinsinden zaman aşımı aralığını ayarlar. Varsayılan değer, bu iletilerin sunucuya gönderilmeyeceğini belirten 0'dır.

ServerAliveInterval5'e ayarlarsanız ssh, ağ 15 saniye boyunca kesilirse otomatik olarak bağlantı kesilir.


Bir SSH oturumunu zorla kırmak için ~., aşağıdakilerden ~.oluşan (veya önce Enter, sonra ) tuşuna ~.
basarım

@ imz - IvanZakharyaschev Bu bağlantının asılı olduğunu söyleyebileceğinizi varsayar. SSH'nin tutma özelliğini kullanmak hatayı otomatik olarak algılar.
Barmar

Kulağa gerçekten yararlı geliyor, teşekkürler, kesinlikle bir sonraki sefere "lapa lapa bölgesinde" olduğumu deneyeceğim.
Max Williams

@Barmar Evet, doğru. Ayrıca bağlantının gerçekten asılıp asılmadığını belirleme problemini de düşündüm, yoksa bir şeye basmak yanlışlıkla bu tuşları uzak tarafa gönderebilir ... Ve iyi bir çözüm bilmiyorum.
imz - Ivan Zakharyaschev

2

Benzer koşullarda, eshellEmacs içindeki TRAMP (ssh üzeri) ile kullanma eğilimindeyim . TRAMP, uzak kabuk için istenen komutları vermede benim için fazla sorun yaratmadan gerektiğinde yeniden bağlanmaya özen gösterir.

Bununla birlikte, eshell bir terminal olarak iyi değildir, yani terminal ile özel bir şey yapan veya sürekli olarak (kademeli olarak) bir şeyi yazdırmak için önemli bir süre boyunca çalışan komutları çalıştırmak için iyi değildir.

Temel olarak, TRAMP ile Emacs'da kullanmaya başlamak oldukça basittir:

M-x eshell
cd /user@host:

1

feragat

SSH bağlantınız kısa ağ kesintilerinden kurtulamıyorsa, izin vermeyen başka bir şey var sshve TCP normal şeylerini yapıyor.

Ayrıntılar için aşağıya bakın. Neyse:

En Hızlı ve En Direk Bağımlılık Yok Çözümü

Bunun gibi bir kabuk komut dosyası oluşturun:

#!/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"

Bu sadece bağlanmaya sshve bağlanmaya çalışan aptal-basit bir döngü çalıştıracaktır screen. Ana bilgisayarı veya normalde sshkomut satır bağımsız değişkenleri olarak çağrınıza ilettiğiniz her şeyi iletin.

Yeniden bağlanma yalnızca SSH'nin bağlantıda bir hata rapor edip etmediğine dayanır, bu da "kelimenin tam anlamıyla WiFI'nız açık değil" veya başka bir şey gibi SSH olmayan hataları tespit etmek için zekası olmadığı anlamına gelir, ancak bu muhtemelen önemli değildir. sen.

ssh-agentYeniden bağlantıların yalnızca sizden ek girdi olmadan çalışmasına izin verecek bir parola olmayan SSH anahtarınız olduğunu varsayıyorum .

^CYeniden bağlanma sırasında bir saniyenin sadece insan tarafından algılanamayan fraksiyonu sırasında vurursanız ^C, istemci terminaline geçmek yerine komut dosyasını öldürmek zorunda kalacağınız küçük bir yarış koşulu olacaktır , bu nedenle bir bağlantı askıda kaldığından şüphelenirseniz püre yok ^Cçok şevkle.

En Basit Ek Yazılım Çözümü

Ubuntu paket deponuzda bulunması gereken autossh programını deneyebilirsiniz .

Kaynaktan derlemeniz veya denetlemeniz gerekiyorsa, bağımlılık olarak herhangi bir ek kitaplık olmadan derleyen, bağlantı canlılığını kontrol etme konusunda yukarıdaki hack'imden daha fazla zekaya sahip gibi görünen tek bir C programı ve aynı zamanda rscreenotomatik -birine bağlanır screen.

ayrıntılar

sshNormalde nasıl iyileşir

Sadece doğrulamak için, kendimi kontrol etmeden bir şey söylemekten hoşlanmam, cevaplamadan önce küçük bir test yaptım:

Bir Linux cihazı ile WiFi'ye girdim, LAN'ımdaki başka bir cihaza SSH bağlantısı kurdum ssh, diğer uca çalışan bir bağlantım olduğunu doğruladım (komutları çalıştırabilir, vb.), Ardından istemci WiFi'yi (arayüze neden oldu) yapılandırılacak: daha fazla IP adresi yok), ssh oturumuna bir sürü daha fazla karakter yazdı (elbette yanıt yok) ve ardından WiFi'ime yeniden bağlandım - yeniden bağlantı aslında kötü sinyal ve diğer faktörler nedeniyle en az bir kez başarısız oldu , daha sonra nihayet yeniden bağlandı: sshOturumun iyileşmesi için yaklaşık beş saniye bekledim , hiçbir şey olmadı, bu yüzden bir tuşa daha bastım ve sshoturum hemen yeniden canlandı, komut satırında bağlantı kesme sırasında yazdığım tüm tuşlarla.

Bakın, sshişletim sistemi bir şeyler ters gittiğini söyleyene kadar TCP ağ soketine yazar / okur ve TCP aslında uzun süreli bağlantı düşüşlerine karşı çok toleranslıdır.

Varsayılan çekirdek ayarlarına sahip kendi cihazlarına bırakıldığında, Linux'taki TCP yığını, bağlantıyı ölü olarak bildirmeden ve bir hata bildirmeden önce birkaç dakika boyunca tamamen sessiz kaldığı için hoş bir şekilde tolere edecek ssh- nihayet vazgeçtiğinde ballparkta konuşuyoruz ~ 30 dakika veya bir veya bir dakika süren bağlantı hıçkırıklarından daha uzun süre dayanacak kadar uzun.

Kapakların altında, Linux TCP yığını yavaş yavaş daha uzun ve daha uzun gecikmelerle mesajları yeniden dener, yani bağlantınız geri geldiğinde, sshoturumunuz tekrar "canlı" görünmeden önce ek gecikmeye bakabilirsiniz .

Neden bu bazen kırılıyor?

Genellikle bir şey, TCP yığınının tolere edeceği miktardan çok daha kısa bir süre kullanılmadığında bağlantının aktif olarak kapanmasına neden olur ve ardından bu bağlantı durumunu sshistemcinize bildirmez .

Muhtemelen adaylar şunları içerir:

  1. Her canlı TCP bağlantısını hatırlamak için bellek kullanması gereken güvenlik duvarları veya NAT' yönlendiricileri - DOS saldırılarına karşı bir optimizasyon ve bazı hafifletme olarak, bazen sadece bağlantınızı unuturlar ve daha sonra bunun için gelen paketleri sessizce göz ardı ederler. mevcut bağlantının geçersiz olduğunu hatırlamadığınızda bağlantının ortasında.

  2. Daha iyi davranan güvenlik duvarları / yönlendiricileri, genellikle bir connection reset by peerhata mesajı olarak görünen bir TCP RST paketi enjekte eder , ancak sıfırlama paketi bir ateşle ve unuttur, bu nedenle istemcinizle bağlantı o anda hala sorun yaşıyor ve paketi de sıfırlayın, istemciniz bağlantının hala hayatta olduğunu düşünecektir.

  3. Sunucunun kendisi , beklenmedik paketleri sessizce bırakmak için bir güvenlik duvarı ilkesine sahip olabilir; bu, sunucu bağlantıyı her kapattığında istemcinin bağlantı sürdürme girişimlerini keser, ancak istemci yapmaz: istemciniz bağlantıyı sürdürmeye çalışır, ancak sunucu sadece bu paketlerin sunucunun güvenlik duvarı durumuna ait olduğu canlı bir bağlantı olmadığı için yoksayılır.

    Linux çalıştırdığınız için, sunucunuzun iptables/ ip6tables(veya nftyeni şeyleri kullanıyorsanız) tam olarak izin verdiğiniz veya bıraktığınız şeyleri dikkatlice kontrol edin . Bu izin çok yaygındır yeni / kurulan / ilgili TCP SSH bağlantı noktasında paketleri, ama değil "geçersiz" olanlar - Eğer izin verilmez sessizce her şeyi bırakarak eğer, bu ortak kurulum kısa bağlantı sorunları sonra donuyor bu tür neden olabilir .

  4. SSH sunucunuzun kendisi, TCP veya SSH istemci tutma paketleri için OpenSSH seçeneklerinden birini kullanarak bir süre kullanılmadığında bağlantıyı kapatacak şekilde yapılandırılmış olabilir. Tek başına bu belirsiz asılmalara neden olmaz, ancak sizi yukarıda açıklanan durumlardan birine sokabilir.

  5. sshOturumunuzun kapandığı duruma geldikten sonra kendi başınıza "çözülmesini" sağlamak için yeterli zaman vermemeniz mümkündür .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.