Batas multiplexing SSH

Saya memiliki entri berikut di .ssh/configfile saya

Host AAA
    User BBB
    HostName CCC
    ControlMaster auto
    ControlPath ~/.ssh/%r@%h:%p

Di atas memungkinkan saya untuk multiplex beberapa sesi ssh melalui koneksi ssh yang sama tanpa harus mengetikkan kata sandi setiap kali saya membutuhkan sesi baru (selama koneksi master tetap terbuka).

Namun, saya perhatikan bahwa ketika saya memiliki # koneksi multiplexing yang relatif tinggi (~ 7), saya tidak bisa menambahkan sesi lagi ke koneksi multiplexed yang sama, dan saya mulai mendapatkan kesalahan berikut:

> ssh -X AAA

mux_client_request_session: session request failed: Session open refused by peer
Password:

Pertanyaan saya:

Mengapa saya mendapatkan kesalahan ini? Apakah ada batasan dalam # sesi ssh yang dapat saya multiplekskan dalam koneksi yang sama? Bisakah saya mengubah batas itu? Apakah itu ide yang buruk?

ssh openssh

— Amelio Vazquez-Reina
sumber

Saya tidak dapat menjawab pertanyaan secara langsung, tetapi dapat menawarkan beberapa saran untuk melacak masalahnya. Karena rekan menolak koneksi, saya akan mulai dengan melihat log pada sistem yang Anda hubungkan. Lihat apakah sshd memberikan kesalahan. Jika tidak, tambah LogLevel dan coba lagi. Jika Anda menemukan pesan log yang tidak segera jelas dan mencari frasa tidak membantu, Anda dapat menggunakan grep pada kode sumber. Pesan kesalahan sering dikelilingi oleh serangkaian kondisi - satu (atau beberapa) dari mereka tidak terpenuhi, dan itulah sebabnya pesan ini muncul.

— Shawn J. Goff

Jawaban:

The sshddaemon di server membatasi jumlah sesi per koneksi jaringan. Ini dikendalikan oleh MaxSessionsopsi di /etc/ssh/sshd_config. Juga MaxStartupsopsi mungkin perlu ditingkatkan jika Anda menggunakan banyak sesi. (Lihat man sshd_configuntuk perincian lebih lanjut.) Opsi untuk mengubah MaxSessionsbatas telah diperkenalkan di OpenSSH 5.1 dan kelihatannya angka itu sebelumnya telah diperbaiki pada 10. Jika Anda melebihi MaxSessionspada server, Anda akan melihat sshd[####]: error: no more sessionsdi log server.

— rozcietrzewiacz
sumber

Saya mengalami masalah ini pada server dengan versi OpenSSH sebelumnya. Saya mengontrol server, dan saya memecahkan masalah dengan membuat dua CNAME dalam konfigurasi bernama saya:

realhost.myexample.com.      IN  A       XXX.XXX.XXX.XXX
realhost2.myexample.com.     IN  CNAME   realhost.myexample.com.
realhost3.myexample.com.     IN  CNAME   realhost.myexample.com.

Kemudian, dalam konfigurasi klien ssh lokal saya:

ControlMaster auto
ControlPath ~/.ssh/%r_%p_%h

host realhost
hostname realhost.myexample.com

host realhost2
hostname realhost2.myexample.com

host realhost3
hostname realhost3.myexample.com

Pernyataan ControlPath adalah agar nama soket kontrol tidak saling menginjak.

Itu saja, tetapi untuk membuatnya mudah dikelola, saya menulis skrip wrapper untuk 'ssh' di sisi klien. Ia memahami bahwa ada 'grup' host (dalam hal ini realhost, realhost1, realhost2 terdiri dari satu grup). Saat mengeluarkan 'sshwrapper realhost', jika tidak ada saluran terbuka, ketiganya dibuka, dan satu sesi dimulai. Lain kali dijalankan, ini menghitung koneksi terbuka per saluran, dan membuka sesi baru di saluran dengan koneksi paling sedikit.

Dengan satu host nyata, dan dua host 'palsu', saya dapat terhubung 30 kali sebelum menerima kesalahan. Masuk sangat cepat, kecuali waktu awal membutuhkan satu atau dua detik, karena ketiga saluran kontrol dibuka pada waktu itu.

— joe
sumber

Script terdengar seperti penghemat waktu nyata dan itu akan sangat berguna. Jika Anda masih memilikinya, maukah Anda membaginya dengan publik?

— thethourtheye

Saya tidak yakin itu pantas di sini, karena itu bukan jawaban untuk pertanyaan. Juga, saya hanya menulisnya sendiri, dan itu berjalan pada klien Mac (untuk login ke server Linux saya). Kode mem-parsing output 'ps', dan perlu diubah untuk dijalankan di Linux, karena sintaks 'ps' yang berbeda.

— joe

Cukup adil. Terima kasih telah berbagi gagasan umum.

— thethourtheye

Saya telah menempatkan skrip di moosiefinance.com:8081/sshm.zip.

— joe

Luar biasa ... Terima kasih banyak ... Biarkan saya melewati itu

— theouroureye