Vấn đề SSH kỳ lạ, ssh hoạt động với -t nhưng đóng băng mà không có nó

Khi tôi sshvào một trong các máy chủ của mình, nó dường như đăng nhập, nhưng sau đó bị treo trước khi đưa cho tôi lời nhắc ( message debug2: shell request accepted on channel 0 is the last log entry).

Mặc dù điều kỳ lạ là ssh -t "/bin/bash"hoạt động khi sshkhông.

Những gì tôi đã tìm ra cho đến nay

• Tôi có thể đăng nhập tốt từ các máy chủ ở cùng một vị trí địa lý thông thường
• Nếu tôi ssh -t '/bin/bash'- tôi có thể đăng nhập hoàn hảo từ bất kỳ vị trí nào.
• Nếu tôi sử dụng rsync để máy chủ, nó dường như làm việc, và sau đó khóa
• Nếu tôi sử dụng rsync từ máy chủ, nó hoạt động mà không có vấn đề

Những gì tôi đã cố gắng

• xóa hoặc thay đổi tất cả các tùy chọn đăng nhập .profile,.bashrc /etc/profile
• Thay đổi ssh_config và / hoặc sshd_config thành một từ một máy chủ giống hệt hoạt động tốt
• Tôi đã kiểm tra định tuyến
• Tôi đã có một chuyên gia mạng kiểm tra tcpdumpvô ích (mặc dù dường như có rất nhiều truyền lại)

Tôi thực sự không thể nghĩ gì khác

Ngoài một trình điều khiển / phần mềm thẻ mạng tinh ranh.

Điều đó có thể đến từ một vấn đề trong hồ sơ.
Khi bạn kết nối với ssh -t /bin/bash vỏ của bạn sẽ không 'đăng nhập', nó sẽ không nguồn sự /etc/profilelẫn ~/.profilevà ~/.bashrc...

Vì vậy, sau khi kết nối, đặt shell ở chế độ gỡ lỗi, sau đó nguồn từng tệp để tìm những gì đang chặn bên trong:

set -x 
. /etc/profile 
...and so on

BIÊN TẬP

Lưu ý rằng tôi đã sai, tệp .bashrc sẽ có nguồn gốc bởi bất kỳ shell tương tác nào (vì vậy chỉ có các tệp profile, profile.d ở đây).

Cố gắng tạo danh sách các giai đoạn khác nhau của quá trình kết nối. Một cái gì đó như thế này

1) ssh kết nối (config, ...)
2) đăng nhập (PAM, tty, wtmp, ...)
3) bắt đầu shell (hồ sơ, truy cập thư mục nhà, ...)

Để kiểm tra (1), bạn có thể khởi động sshd daemon ở chế độ gỡ lỗi. Cho rằng bạn cần bắt đầu một sshd khác, lắng nghe một cổng chuyên dụng (không phải trên cổng 22 vì vậy không cần phải dừng trình nền sshd thông thường).

# /usr/sbin/sshd -p 2222 -ddd 

Sshd đó sẽ chỉ chấp nhận một kết nối và sẽ không đi vào nền. Mở một thiết bị đầu cuối khác và kết nối với phiên ssh đó.

# ssh -vvv -p 2222 user@host

Bạn có thể so sánh các tin nhắn bạn nhận được với một trong những máy chủ khác có cùng thương hiệu. Sau đó, bạn sẽ biết nếu vấn đề là ở phía ssh hay không.

(-ddd và -vvv là mức gỡ lỗi tối đa, bạn có thể điều chỉnh mức đó)

Tôi có liên kết đó , chi tiết hơn nhiều.

Câu trả lời cho vấn đề của tôi Hóa ra đó là một vấn đề về mạng. Cuối cùng tôi phát hiện ra rằng bằng cách giảm MTU của tất cả các card mạng xuống một chút, vấn đề đã biến mất.

Rất có thể một cái gì đó được định cấu hình sai cho mạng đó, nhưng bây giờ tôi có thể chứng minh điều đó và giao nó cho nhóm mạng (người tiếp tục nói với tôi rằng đó là sự cố máy chủ).

Mặc dù vậy, hãy lưu ý, đây là giải pháp cuối cùng Điều đặc biệt tôi có là máy chủ ssh hoạt động từ cùng một mạng con nhưng không phải bên ngoài nó và ssh -t '/ bin / bash' hoạt động từ bất cứ đâu.

Tôi cũng có rsyncs sẽ bắt đầu tốt, nhưng tại một số điểm chỉ cần treo hoặc thả kết nối.

Vì vậy, nếu bạn đang xem câu trả lời này, trước tiên hãy thử những câu hỏi khác và CHỈ nếu bạn nhận được những điều kỳ lạ như của tôi, điều này có khả năng giúp ích không.

Vì vậy, cảm ơn tất cả sự giúp đỡ. Tôi đã thử tất cả mọi thứ, và nó dạy tôi tải, và để tôi xác nhận nó không liên quan gì đến máy chủ (đó là tất cả mọi thứ tôi đã hy vọng).

Cảm ơn mọi người đã giúp đỡ.

Khi bạn làm ssh some_user@some_host /bin/bash, những gì bạn đang làm là tung ra some_user 's vỏ (theo quy định tại /etc/passwdtrên some_host ) và sau đó thực hiện lệnh được đưa ra, /bin/bashtừ bên trong vỏ đó.

Bây giờ, shell của some_user (giả sử nó cũng vậy bash) sẽ không được khởi chạy tương tác (thay vào đó, nó thực thi lệnh đã cho). Vì vậy, nó không phân bổ một pty (một thiết bị đầu cuối giả ) và điều này có nghĩa là không có một pty nào cho lệnh được ban hành để sử dụng để nó bắt đầu không tương tác.

Trong ví dụ này, /bin/bashlệnh được yêu cầu được khởi chạy nhưng nó dường như bị treo.

Bạn có thể khắc phục điều này bằng cách yêu cầu sshtạo một pty bằng mọi cách để có một cái có sẵn cho shell và các tiến trình con của nó. Đây là những gì -tkhông.

    $ ssh -t some_user@some_host bash

Bạn cũng có thể sửa lỗi này bằng cách buộc lệnh tạo pty. Đối với bash, bạn làm điều này bằng cách thông qua một -iđối số. Dòng lệnh sau cũng sẽ hoạt động:

$ ssh some_user@some_host bash -i

Lưu ý, tuy nhiên trong trường hợp sau này, shell không thể truy cập /dev/ttyvà điều này dẫn đến một cảnh báo:

bash: no job control in this shell

Những lý do cho điều này được giải thích ở đây . Điều này có thể hoặc không thể là một vấn đề tùy thuộc vào những gì bạn dự định làm trong trình bao nhưng sử dụng ssh -tcó lẽ là lựa chọn tốt hơn.

(lưu ý rằng bạn chỉ có thể chuyển bashdưới dạng lệnh vì dù sao nó cũng phải nằm trên đường dẫn của shell mặc định của người dùng)

Tôi có vấn đề tương tự khi tôi sử dụng một nền tảng ảo hóa lồng nhau gần đây.

Nó hoạt động sau khi giảm MTU từ 1500 xuống 1400 trên máy chủ nguồn hoặc đích.

/sbin/ip link set dev eth0 mtu 1400