☰

이상한 SSH 문제, ssh는 -t와 함께 작동하지만 그것 없이는 작동하지 않습니다.

tag-icon • tag-icon shell ssh login
이상한 SSH 문제, ssh는 -t와 함께 작동하지만 그것 없이는 작동하지 않습니다.

내 서버 중 하나에 로그인 하면 ssh로그인된 것처럼 보이지만 프롬프트( message debug2: shell request accepted on channel 0 is the last log entry)가 표시되기 전에 멈춥니다.

이상하게도 ssh -t "/bin/bash"작동하지 않을 때도 작동합니다.ssh

내가 지금까지 찾은 것

  • 동일한 지리적 위치에 있는 서버에서 정상적으로 로그인할 수 있습니다.
  • 만약 그렇다면 ssh -t '/bin/bash'- 어느 위치에서나 완벽하게 로그인할 수 있습니다.
  • 내가 사용한다면rsync 도착하다서버가 작동하는 것 같더니 잠겼습니다.
  • 내가 사용한다면rsync ~에서서버, 문제없이 실행 중

내가 시도한 것

  • 모든 로그인 옵션 제거 또는 변경 .profile,.bashrc /etc/profile
  • 변화ssh_config 그리고/또는 sshd_config정상적으로 실행되는 동일한 서버에
  • 노선을 확인해보니
  • 네트워크 전문가에게 확인을 요청했지만 tcpdump소용이 없었습니다. (재전송이 많은 것 같기는 하지만)

정말 다른 건 생각이 안 나네요

의심스러운 네트워크 카드 드라이버/펌웨어는 제외됩니다.

답변1

이는 구성 파일의 문제로 인해 발생할 수 있습니다. 쉘을
연결하면 ssh -t /bin/bash "로그인"도 되지 않고, 소스 도 /etc/profile아니고 ...~/.profile~/.bashrc

따라서 일단 연결되면 셸을 디버그 모드로 전환하고 각 파일을 소싱하여 내부적으로 차단되는 항목을 찾습니다.

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

편집하다

제가 틀렸다는 점에 유의하세요. .bashrc 파일은 모든 대화형 셸에서 선택됩니다(따라서 여기서는 프로필인 profile.d 파일만 중요합니다).

연결 프로세스의 다양한 단계를 나열해 보십시오. 이 같은

1) SSH 연결(구성,...)
2) 로그인(PAM, tty, wtmp,...)
3) 쉘 시작(구성 파일, 홈 디렉토리 액세스,...)

(1)을 확인하려면 디버그 모드에서 sshd 데몬을 시작할 수 있습니다. 이렇게 하려면 전용 포트(포트 22가 아니므로 일반 sshd 데몬을 중지할 필요가 없음)에서 수신 대기하면서 다른 sshd를 시작해야 합니다.

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

sshd는 하나의 연결만 허용하며 백그라운드로 이동하지 않습니다. 다른 터미널을 열고 SSH 세션에 연결합니다.

# ssh -vvv -p 2222 user@host

받은 메시지를 동일한 브랜드의 다른 서버에서 보낸 메시지와 비교할 수 있습니다. 그러면 문제가 SSH 측에 있는지 알 수 있습니다.

(-ddd 및 -vvv는 조정할 수 있는 최대 디버깅 수준입니다.)

알겠어요협회,자세한 세부 사항.

답변2

내 질문에 대한 답변 네트워크 문제로 확인되었습니다. 결국 모든 네트워크 카드의 MTU를 약간 낮추면 문제가 해결된다는 사실을 발견했습니다.

네트워크 구성이 잘못되었을 가능성이 높지만 이제 이를 증명하고 네트워크 팀(계속 서버 문제라고 말함)에 넘겨줄 수 있습니다.

하지만 이것은 최후의 수단이라는 점을 명심하세요. 내 특징은 ssh 서버가 동일한 서브넷에서 작동하지만 외부에서는 작동하지 않으며 ssh -t '/bin/bash'는 모든 곳에서 작동한다는 것입니다.

또한 rsync도 있는데, 잘 시작되지만 어느 시점에서 멈추거나 연결이 끊어집니다.

따라서 이 답변을 보고 있다면 위의 다른 답변을 먼저 시도해 보세요. 이는 저와 같은 이상한 문제가 있는 경우에만 도움이 될 수 있습니다.

모든 도움에 감사드립니다. 나는 모든 것을 시도했고 그것은 나에게 많은 것을 가르쳐 주었고 그것이 서버와 아무 관련이 없다는 것을 확인할 수 있게 해주었습니다(이것은 내가 바라던 모든 것입니다).

도움을 주신 모든 분들께 감사드립니다.

답변3

최근 중첩된 가상화 플랫폼을 사용하면서 동일한 문제가 발생했습니다.

원본 또는 대상 서버에서 MTU를 1500에서 1400으로 줄이는 것이 가능합니다.

/sbin/ip link set dev eth0 mtu 1400

답변4

이렇게 하면 ssh some_user@some_host /bin/bash실행만 하면 됩니다.사용자쉘(에 정의 /etc/passwd됨주인) 그런 다음 /bin/bash해당 셸에서 주어진 명령을 실행합니다.

지금,사용자쉘(우리도 가정함 bash)은 대화식으로 시작되지 않습니다(대신 주어진 명령을 실행합니다). 따라서 pty(a의사 터미널), 이는 실행된 명령에 사용할 수 있는 pty가 없으므로 비대화형으로 시작됨을 의미합니다.

이 예에서는 요청된 /bin/bash명령이 시작되었지만 정지된 것처럼 보입니다.

ssh쉘과 해당 하위 프로세스에서 사용할 수 있도록 pty를 생성하도록 요구하여 이 문제를 해결할 수 있습니다 . 그것이 바로 그 일입니다 -t.

    $ ssh -t some_user@some_host bash

pty를 생성하도록 명령을 실행하여 이 문제를 해결할 수도 있습니다. 의 경우 매개변수를 전달하여 이를 수행 bash할 수 있습니다 . -i다음 명령줄도 작동합니다.

$ ssh some_user@some_host bash -i

그러나 후자의 경우 셸에 액세스할 수 없으므로 /dev/tty경고가 발생합니다.

bash: no job control in this shell

이유는 다음과 같습니다.여기. 이는 쉘에서 수행하려는 작업에 따라 문제가 될 수도 있고 그렇지 않을 수도 있지만 ssh -t사용하는 것이 더 나은 옵션일 수 있습니다.

( bash어쨌든 사용자의 기본 셸 경로에 있어야 하므로 명령으로 전달할 수 있습니다.)

관련 정보