Bir SSH tüneli nasıl güvenilir bir şekilde korunur?

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)

• bu kullanıcı sshtunnel işlevi olarak çalışır, bu yüzden önce kullanıcının var olduğundan emin olun
• önyükleme sırasında başlayacak şekilde ayarlamak için systemctl enable sshtunnel sorunu
• hemen başlamak için systemctl start sshtunnel sorunu

Jan 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:

• autossh programı
• bash betiği (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.

• http://www.howtogeek.com/howto/ubuntu/keep-your-ssh-session-running-when-you-disconnect/

... 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.