인증 후 SSH가 정지됨


10

ssh를 통해 내 서버 중 하나에 로그인하면 인증 후에 정지됩니다. 이 클라이언트의 출력입니다 -v.

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host1 [10.6.27.64] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host1' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:172
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = C
debug1: Sending env LC_ALL = C
Last login: Wed May 21 10:24:14 2014 from host2
This machine has been configured with kickstart
host1 in bcinf17 in bay 3 in rack D10-Mid

그리고 /var/log/secure서버에서 이것을 볼 수 있습니다 (행운이 여전히 열려 있습니다).

May 21 10:27:31 host1 sshd[12387]: Accepted publickey for user from 1.1.11.239 port 34135 ssh2
May 21 10:27:31 host1 sshd[12387]: pam_unix(sshd:session): session opened for user user by (uid=0)

따라서 명백한 잘못은 없습니다. 클라이언트와 서버가 통신 할 수있는 것 같습니다. 에 없습니다 /var/log/messages.

디스크 공간이 충분합니다. 일부 경로 (홈 영역 포함)가 마운트되어 있지만 여전히 활성 상태 인 쉘이 해당 경로에 액세스 할 수 있습니다.

다른 서버에 연결할 수 있습니다. 이것 만이 문제가 있습니다. 다시 시작하려고했습니다 sshd. 에 대한 구성 파일 sshd은 기본값처럼 보이므로 아무것도 없습니다. 내가 아는 한 최근에는 아무것도 바뀌지 않았습니다.

명령 ( ssh host1 -t bash, 또는 -t vi) 을 실행하려고하면 중단 된 것처럼 보이므로 로그인 스크립트와 관련이 있다고 생각하지 마십시오.

같은 위치와 다른 위치에있는 다른 호스트 또는 Putty를 통해 Windows에서 로그인하고 키 대신 암호를 사용하여 로그인을 시도했습니다.

볼 곳이나 시도 할 것이 확실하지 않습니다.

RHEL 6.4 서버, 64 비트입니다.


가장 먼저 할 일은 모든 사용자 로그인 스크립트를 제거하는 것입니다.
user9517

답변:


3

SSH 인증 직후 중단 될 수있는 몇 가지 사항이 있습니다.

그러나 이들 중 대부분은 다른 증상을 나타냅니다 (SSH 인증 직후 중단이 가장 눈에 띄는 증상 임)

  1. Iain이 언급했듯이 모든 사용자 로그인 스크립트.
    • ~/.bashrc, ~/.bash_profile, ~/.profile, ~/.kshrc전후 정도로
  2. 실행 / 다시 시작하는 프로세스가 너무 많습니다.
    • 뭔가가 fork()'D 너무 많은 아이 프로세스와 부하 ( 1/5/15 점수를 너무 높다).
  3. I / O 대기 문제가 있습니다.
    • 일반적으로 죽어가는 하드 드라이브 (일반) 또는 잘못 작동하는 NIC (희귀)로 인해 발생합니다.
  4. 타사 PAM 모듈이 정지됨 (예 : 비표준 Kerberos 구성)
    • 항상 모듈 자체는 아니지만 전체 로그 서버가있는 서비스 (예 : 감사)가 있습니다.

2

또 다른 문제점 소스는 ssh 클라이언트가 ssh-agent (물론이를 사용하도록 구성된 모든 에이전트)를 기다리는 것입니다. ssh'ing이 어디 에서 멈 추면

debug1 : SSH2_MSG_NEWKEYS 수신

그런 다음 ps auxw | grep askpass주의를 피할 수있는 대화 상자 를 확인하십시오 .

PS :이 오히려입니다 하지 여기 범인 그러나 나는 관련성 봤하지 않은 질문에 지금까지까지.


2
이것은 내가 겪고있는 문제를 해결했습니다. 감사!
geeth

에 오신 것을 환영합니다 :-) 그것은 ... 꽤 몇 분 동안 모든 날에 분명 아니었다
마이클 Shigorin

이것이 저에게 근본적인 문제인지 확실하지 않지만 WSL에서 위의 명령을 실행하는 동안 다음 오류가 표시되는 것을 알았습니다. 이로 인해 같은 문제가없는 Windows 용 git-bash에 의존하게되었습니다. ```신호 11 (SEGV)이 ps (3.3.12)에 의해 포착되었습니다. ps : ps / display.c : 66 :이 버그를보고 해주세요```
jpierson

1

사용하면 직접 연결됩니까 ssh -o GSSAPIAuthentication=no user@host?

그렇다면 시스템이 GSSAPI 방법을 결정하는 특정 시점에 중단 된 것일 수 있습니다. 나를 위해 하나의 호스트만이 작업을 수행 했으므로 ~/.ssh/config해당 호스트 에 대해 GSSAPI를 비활성화했습니다 .

Host badHostName
    GSSAPIAuthentication no

나는 이것을 http://germanrumm.eu/fixing-ssh-login-delay-how-to-disable-gssapi-with-mic-on-ubuntu-linux/ 에서 배웠지 만 그 원인을 결코 배운 적이 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.