İşten çeşitli SSCB tünelleri kullanıyorum (çeşitli patronlar için sorun yok). Sorun, bir süre sonra ssh bağlantısı genellikle askıda kalıyor ve tünel kırılıyor.
En azından tüneli otomatik olarak izleyebilseydim, kilitlendiğinde tüneli yeniden başlatabilirdim, ama bunu yapmanın bir yolunu bile bulamadım.
Elbette ssh bağlantımın asılı kalmasını nasıl önleyeceğimi söyleyebilecek olanlara bonus puanları!
Durum bilgisi olan tüm güvenlik duvarları bir süre bu bağlantı için bir paket görmedikten sonra bağlantıyı unutur (durum tablolarının, her iki ucun bağlantıyı kapatmadan öldüğü bağlantılarla dolmasını önlemek için). TCP uygulamaları, uzun bir süre sonra diğer taraftan haber alınmadan bir kalıcı paket gönderir (2 saat ortak bir değerdir). Bununla birlikte, kalıcı paketler gönderilmeden önce bağlantıyı unutan durumsal bir güvenlik duvarı varsa, uzun ömürlü fakat boşta bir bağlantı kesilecektir.
Bu durumda, çözüm bağlantının boşta kalmasını önlemektir. OpenSSH, ServerAliveInterval adlı bir seçeneğe sahiptir ve/bu bağlantının çok uzun süre boşta kalmasını engellemek için kullanılabilir (bir bonus olarak, eş boşta olsa bile, eşin ne zaman öldüğünü tespit eder).
Kendi mac veya linux makinenizde ssh sunucunuzu her 3 dakikada bir sunucunun ssh olmasını sağlayın. Bir terminal açın ve evinizde görünmez .ssh'nize gidin:
cd ~/.ssh/
sonra 1 satırlı config dosyası oluşturun:
echo "ServerAliveInterval 180" >> config
ayrıca eklemelisiniz:
ServerAliveCountMax xxxx (high number)
varsayılan değer 3'dür, yani ServerAliveInterval 180, 9 dakika sonra göndermeyi durduracaktır (ServerAliveInterval tarafından belirtilen 3 dakikalık aralığın 3'ü).
Birincisi öldüğünde yeni ssh tünellerinin ortaya çıkmasını sağlamak için aşağıdaki Bash komut dosyasını kullandım. Komut dosyası kullanmak istemediğinizde veya ek paketler kuramadığınızda veya derleyici kullanamadığınızda kullanışlıdır.
while true
do
ssh <ssh_options> [[email protected]]hostname
sleep 15
done
Bunun, bağlantıyı otomatik olarak kurmak için bir anahtar dosya gerektirdiğini, ancak autossh için de geçerli olduğunu unutmayın.
Systemd bunun için idealdir.
Bir servis dosyası /etc/systemd/system/sshtunnel.service
içeren bir servis dosyası oluşturun:
[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 komutunu uyacak şekilde değiştirin)
sshtunnel
işlevi olarak çalışır, bu yüzden önce kullanıcının var olduğundan emin olunsystemctl enable sshtunnel
sorunusystemctl start sshtunnel
sorunuJan 2018 Güncellemesi : bazı dağıtımlar (örneğin, Fedora 27), SSH'nin sistem girişinden kullanılmasını önlemek için SELinux politikasını kullanabilir; bu durumda, özel bir politikanın oluşturulması gerekir. gerekli muafiyetleri sağlayın.
Bana öyle geliyor ki hepiniz ServerAliveCountMax’ı yanlış yorumluyorsunuz. Belgeleri anladığım gibi, bağlantı sonlandırılmadan cevaplanamayan sunucu canlı mesaj sayısıdır. Bu yüzden burada tartıştığımız gibi durumlarda, bunu yüksek bir değere ayarlamak sadece asılı bir bağlantının algılanmamasını ve sonlandırılmamasını sağlayacaktır!
Basitçe ServerAliveInterval ayarının, bağlantıyı unutan bir güvenlik duvarı ile sorunu çözmek için yeterli olması gerekir ve ServerAliveCountMax'ı düşük bırakmak, kaynak bağlantının yine başarısız olması durumunda kaynak sonun farkına varmasına ve sonlandırılmasına izin verecektir.
İstediğiniz şey, 1) normal şartlar altında bağlantının sürekli açık kalması için, 2) bağlantı hatası tespit edildiğinde ve kaynak tarafın arızada çıkması durumunda, 3) ssh komutunun her seferinde yeniden yayınlanması için çıkın (nasıl yaptığınız platforma bağımlı, Jawa tarafından önerilen "gerçek olsa" betiği bir yoludur, aslında OS XI'da bir fırlatma öğesi hazırlamıştır).
Tünel sorunlarının süresi dolmuş NAT oturumları tarafından oluşturulmuş olması durumunda, daima ServerAliveInterval
SSH seçeneğini kullanın.
Bağlantının tamamen kesilmesi durumunda her zaman bir yeniden doğuş yöntemi kullanın, burada en az üç seçeneğiniz vardır:
while true do ssh ...; sleep 5; done
) uyku komutunu kaldırmaz, ssh
hızlı bir şekilde başarısız olabilir ve çok fazla işlemi yeniden resmedersiniz/etc/inittab
, NAT'ın arkasından başka bir ülkeye gönderilen ve kurulan bir kutuya erişebilmek için, kutuya bağlantı noktası yönlendirmeden, size bir ssh tüneli oluşturmak üzere yapılandırabilirsiniz:
tun1:2345:respawn:/usr/bin/ssh -i /path/to/rsaKey -f -N -o "ServerAliveInterval 180" -R 55002:localhost:22 [email protected] 'sleep 365d'
ubuntu'da komut dosyası başlat, burada /etc/inittab
kullanılamıyor:
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
veya her zaman iki yöntemi de kullanın.
Bu sorunu bununla çözdüm:
Düzenle
~/.ssh/config
Ve Ekle
ServerAliveInterval 15
ServerAliveCountMax 4
man sayfasına göre ssh_config için:
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
, diğer önerilere iyi bir yardımcıdır. Bağlanır ancak bağlantı noktası yönlendirmeyi kuramazsa, hiç bağlantınız yokmuş gibi kullanışsızdır.
Biraz kesmek, ama bunu korumak için ekranı kullanmak istiyorum. Şu anda haftalardır çalışan bir uzaktan ileri.
Yerel olarak başlayan örnek:
screen
ssh -R ......
Uzaktan iletme uygulandığında ve uzak bilgisayarda bir Shell var:
screen
Ctrl + a + d
Artık kesintisiz bir uzaktan kumandaya sahipsiniz. Hile iki ucunda ekranı çalıştırmak için
Son zamanlarda bu sorunu kendim yaşadım, çünkü bu çözümler parola girişini kullanırsanız her seferinde parolayı tekrar girmenizi gerektirir çünkü sshpass komutunu toplu iş dosyasında parolaya sahip olmaktan kaçınmak için bir metin istemiyle birlikte kullanılır.
Başkalarının da aynı sorunu yaşayabilmesi için çözümümü bu konuda paylaşacağımı düşündüm:
#!/bin/bash
read -s -p "Password: " pass
while true
do
sshpass -p "$pass" ssh [email protected] -p port
sleep 1
done
Uzun süredir SSH tüneli tutmaya ihtiyacım vardı. Çözümüm bir Linux sunucusundan çalışıyordu ve ssh'yi anahtar tabanlı kimlik doğrulamasını kullanarak yeniden başlatan küçük bir C programı.
Asıldığından emin değilim, ama zaman aşımına uğrayan tüneller ölmüştü.
Yeniden doğuranın kodunu vermeyi çok isterdim ama şu anda bulamıyorum.
ssh oturumunu yeniden başlatmaya yardımcı olan autossh gibi araçlar varken ... gerçekten yararlı bulduğum şey 'screen' komutunu çalıştırmak. Bağlantıyı kestikten sonra bile ssh oturumlarına devam etmeni sağlar. Özellikle bağlantınız olması gerektiği kadar güvenilir değilse kullanışlıdır.
... eğer size yardım ederse, bunun 'doğru' cevap olduğunu işaretlemeyi unutmayın! ;-)
autossh
bizim ihtiyaçlarımızı karşılamadığı için (ilk denemede sunucuya bağlanamazsa hatayla var olur), saf bir bash uygulaması yazdık: https://github.com/aktos-io/sunucuyla bağlantı
Varsayılan olarak NODE'nin sshd portu (22) için sunucuda ters bir tünel oluşturur. Başka bir işlem yapmanız gerekiyorsa (ek bağlantı noktaları iletme, bağlantıya posta gönderme, vb ...) komut dosyalarınızı on-connect
ve on-disconnect
klasörlerine yerleştirebilirsiniz.
Önceki ISS'mde de benzer problemler yaşadım. Benim için tcp ile bağlantı kurmak, web sitelerini ziyaret etmek veya posta göndermek ile aynıydı.
Çözüm, UDP üzerinden bir VPN bağlantısı yapılandırmaktı (OpenVPN kullanıyordum). Bu bağlantı, bağlantı kopmalarına neden olana daha toleranslıdır. Daha sonra bu bağlantı üzerinden herhangi bir servisi çalıştırabilirsiniz.
Bağlantıda hala sorunlar olabilir, ancak tünel daha toleranslı olacağından, herhangi bir ssh oturumu bağlantısı kesilmek yerine kısa bir bekletme hissedecektir.
Bunu yapmak için çevrimiçi olarak kendi sunucunuzda ayarlayabileceğiniz bir VPN servisine ihtiyacınız olacak.