공개 키 인증은 sshd가 데몬 인 경우에만 실패합니다


33

나는 이것이 어떻게 일어나는지 전혀 모른다. 배포판은 Scientific Linux 6.1이며 공개 키를 통해 인증을 수행하도록 모든 것이 설정되었습니다. 그러나 sshd가 데몬 (서비스 sshd start)으로 실행 중이면 공개 키를 허용하지 않습니다. (이 로그 조각을 얻기 위해 -ddd 옵션을 추가하도록 sshd 스크립트를 변경했습니다)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

sshd가 디버그 모드에서 실행 /usr/sbin/sshd -ddd되면 인증은 매력처럼 작동합니다.

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

어떤 아이디어 ?? 누구든지 이런 것을 본 적이 있습니까?

노트:

파일 권한이 두 번 확인되었습니다.

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

sshd가 "데몬 모드"에서 루트 파일에 액세스 할 수 있는지 묻습니다. 이 질문에 가장 가까운 대답은 다음과 같습니다.

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

sshd가 루트로 실행 중이면 자체 파일에 액세스하는 방법을 모르겠습니다. SELinux가 원인 일 수 있습니까?


1
sshd init 스크립트가 흥미로운 작업을 수행합니까? (/etc/init.d/sshd?) 명령 행에서 수행하지 않는 것이 있습니까? 'service sshd start'대신 'sh -x /etc/init.d/ssh start'를 시도하십시오.
PT

답변:


42

예, SELinux가 원인 일 수 있습니다. .sshDIR은 아마 잘못 표시됩니다. 을보십시오 /var/log/audit/audit.log. 라벨이 붙어 있어야합니다 ssh_home_t. 로 확인하십시오 ls -laZ. restorecon -r -vv /root/.ssh필요한 경우 실행하십시오 .


1
그렇습니다. SELinux가 원인이었습니다. type = AVC msg = audit (1318597097.413 : 5447) : avc : pid = 19849 comm = "sshd"name = "authorized_keys"에 대해 {read}가 거부되었습니다. dev = dm-0 ino = 262398 scontext = unconfined_u : system_r : sshd_t : s0-s0 : c0.c1023 tcontext = unconfined_u : object_r : admin_home_t : s0 tclass = file "restorecon -r -vv /root/.ssh"를 실행 한 후에 작동합니다. 고마워
user666412

1
감사합니다 selinux 명령 줄 수정에 감사드립니다 .ssh 키 인증을 사용하여 redhat enterprise 6.2 서버에 루트로 ssh 할 수 있었지만 루트가 아닌 사용자로 ssh 할 수 없었던 이유를 오랜 세월 동안 찾으려고 노력했습니다. 비밀번호를 입력하지 않아도됩니다. "ssh -v"는 전혀 이상한 것을 나타내지 않았습니다. /home/example/.ssh에서 파일 보호를 확인하고 다시 확인했습니다. "/ usr / sbin / sshd -d"를 실행할 때까지는 아니었고 정상적으로 작동하는 다른 이유로 인해 다른 일이 일어나고 있음을 깨달았습니다. 다른 Google 검색을 시도하고 이것을 찾았습니다. 그래서 증상은 내가 로로 ssh 수 있었다
폴 M

1
전체 파일 시스템, 즉 restorecon -r /YMMV 에서이 작업을 수행해야했습니다 .
Irfy

1
나는 이것을 시도했지만 여전히 작동하지 않는다. 감사 로그에 type=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir무슨 의미인지 모르겠습니다
Yehosef

1
대답은 ~에 있습니다 name="/"- restorecon -r /@Irfy가 제안한대로 실행 해야했습니다.
Yehosef 2016 년

3

나는 같은 문제가 있었다. 제 경우에는 restorecon과 chcon이 작동하지 않았습니다.

selinux를 비활성화하고 싶지 않았습니다. 많은 연구 끝에 마침내 홈 디렉토리가 다른 곳 (NFS)에서 마운트 되었기 때문이라고 생각했습니다. 나는 이 버그 보고서 를 발견 했다.

나는 달렸다 :

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

use_nfs_home_dirs가 꺼져 있는지 확인한 후 다음을 수행하십시오.

sudo setsebool -P use_nfs_home_dirs 1

켜십시오.

이제 비밀번호를 입력하지 않고 키를 사용하여 내 컴퓨터로 ssh 할 수 있습니다. use_home_nfs_dirs 부울을 전환하면 나에게 필요한 것이 었습니다.


1

Mark Wagner의 답변에 추가하려면 사용자 정의 홈 디렉토리 경로를 사용하는 경우 (예 :) /homeSELinux 보안 컨텍스트를 설정해야합니다. 이를 위해 예를 들어에 사용자 홈 디렉토리가있는 경우 다음을 /myhome실행하십시오.

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

CentOS를 사용하는 경우 다음을 수행하기 위해이를 실행해야합니다 semanage.sudo yum install policycoreutils-python
sm4rk0

0

연결을 테스트 할 때 다른 키를 사용하는 것 같습니다 (0x7f266e1a8840 vs 0x7f85527ef230). 'ssh -v example.com'을 사용하여 데몬으로 실행되고 디버그 모드에서 sshd에 연결하고 "RSA 공개 키 제공"문자열에서 ssh가 사용하는 키를 찾으십시오.


예, id_rsa와 id_dsa가있었습니다. DSA 키가 사라졌으며 테스트를 다시 실행할 것입니다.
user666412

언급 된 값 debug3: mm_answer_keyallowed: key 0xFFFFFFFFFF은 sshd가 새로운 연결을 수신 할 때마다 변경됩니다. 이를 확인하려면 SSH가 작동하는 서버를 찾고 sshd LOGLEVEL을 debug3으로 크랭크하고 sshd를 다시 시작한 tail -f /var/log/secure |grep mm_answer_keyallowed후 실행 한 다음 몇 번 로그인하여 각 연결 사이에 몇 초 (또는 몇 분) 동안 기다리십시오. 매번 값이 변경되는 것을 볼 수 있습니다. 그리고 실제로 그것은 나에게 카운터처럼 보입니다.
Stefan Lasiewski
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.