☰

이상한 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 연결(config,...)
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, 당신이 하고 있는 일은 시작되는 것입니다.some_user의 쉘(에 정의된 대로 /etc/passwd)some_host) 그런 다음 /bin/bash해당 셸 내에서 주어진 명령을 실행합니다.

지금,some_user의 셸(역시 이라고 가정 bash)이 대화형으로 시작되지 않습니다(대신 주어진 명령을 실행함). 따라서 pty를 할당하지 않습니다(a의사 터미널) 이는 실행된 명령이 사용할 pty가 없으므로 비대화형으로 시작됨을 의미합니다.

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

ssh쉘과 그 하위 프로세스에 사용할 수 있는 pty가 있도록 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( 어쨌든 사용자의 기본 셸 경로에 있어야 하므로 명령으로 전달할 수 있습니다 .)

관련 정보