☰

SSH: "서버가 아무 이유 없이 키를 거부했습니다."

tag-icon • tag-icon ssh putty key-authentication public-key-authentication puttygen
SSH: "서버가 아무 이유 없이 키를 거부했습니다."

SSH를 통해 Windows 시스템에서 Linux 시스템으로 파일을 복사하기 위해 자동으로 실행되는 간단한 백업 스크립트를 설정하려고 합니다.

많은 간단한 온라인 튜토리얼에서 알 수 있듯이 pscp생성된 개인 키를 사용 puttygen하고 해당 공개 키(퍼티 자체에 의해 복사/붙여넣기 형식으로 표시됨)를 authorized_keysLinux의 파일에 배치했습니다. 동일한 구성을 가진 2개의 다른 Windows 시스템과 다른 Linux 시스템에서 실행되고 있다는 점을 고려하면 매우 간단해 보입니다.

Linux 상자에 루트로 로그인할 수 있다는 점을 고려하면 AFAICS에는 연결 문제가 없으며 SSH도 마찬가지입니다. 프로필( sshd_config) AuthorizedKeysFile이 로 설정되었습니다 ~/.sshd/authorized_keys.

아무리 해도 "서버가 키를 거부했습니다"라는 오류가 계속 뜹니다... 로그에는 인증 문제가 표시되지 않습니다...

좀 더 테스트를 해보고 값을 or logLevel로 설정할 예정이지만 , 문제의 시급성과 실제 머신에서 테스트하기 위해서는 많은 어려움을 겪어야 할 것이라는 점을 고려하면, 기계 상태입니다. 제가 일하는 곳이랑은 너무 멀어서...VERBOSEDEBUG23

질문

  • 누구든지 어떤 아이디어가 있습니까?
  • 이런 상황에 처한 사람이 있습니까?

이것은 실제로 ssh 버전이나 이와 유사한 문제와 관련된 문제인 것 같습니다.

또한 루트 폴더에 공개 키를 배치하는 것 외에도 authorized_keys사용자 디렉터리 내부의 파일에 공개 키를 삽입해야 할 가능성도 고려했습니다 ( in 값으로 인해 의미가 없음)..ssh/user/.ssh/AuthorizedKeysFilesshd_config

SSH 서버에 o를 설정하여 LogLevel몇 가지 테스트를 수행했지만 VERBOSE정보(책임 문제)를 검색할 수 없으므로 여기에 동일한 오류를 표시하는 것으로 보이는 다른 소스의 출력/디버그 로그가 있습니다.

Connection from 192.168.0.101 port 4288
debug1: Client protocol version 2.0; client software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug1: permanently_set_uid: 22/22
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user dcowsill service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "dcowsill"
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM: setting PAM_RHOST to "192.168.0.101"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 2 failures 2
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
Connection closed by 192.168.0.101

프로그램이 소유자의 권한으로 파일을 열려고 시도하는 것 같지만 authorized_keys문제의 원인에 대한 정보가 더 이상 없습니다. 마지막으로 파일 및 폴더 권한을 확인하고 다시 확인했는데 모두 괜찮습니다.

답변1

내가 아는 가능한 이유 중 일부는 파일 권한과 관련이 있으며 대부분은 너무 광범위합니다. 특히 두 가지 이유를 기억할 수 있습니다.

  1. 소유자가 아닌 다른 사람에게 /home/user 디렉토리를 노출합니다.
  2. .ssh및/또는 Authorized_keys 파일 권한(이 값을 초과하는 경우 각각 700/600으로 설정)

서버에 대한 루트 액세스 권한이 있는 경우 디버그 및 비데몬 옵션을 사용하여 다른 포트에서 추가 sshd 서버를 시작하여 키가 거부되는 정확한 이유를 파악할 수 있습니다.

sudo `which sshd` -p 2020 -Dd

서버에서

실행 상태를 종료한 후 ssh를 실행합니다.

ssh -p 2020 -i /path/to/refusedkey

서버 출력에서 ​​거부 이유를 알려줍니다.

답변2

달리기:

sudo `which sshd` -p 2020 -Dd

한 세션에서는 루트로 실행하고 다른 세션에서는 실행합니다.

ssh -p 2020 -i /path/to/refusedkey refusedkeyusername@hostname

이유를 알아내기 위해 나를 위해 일했습니다. 내 사용자 ID 권한이 700으로 설정되어 있지 않습니다. 내가 얻은 O/P는 다음과 같습니다

debug1: trying public key file /home/userid/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: **bad ownership** or modes for directory /home/sapadmin
debug1: restore_uid: 0/0
Failed publickey for userid from 172.31.2.12 port 27382 ssh2: RSA 
Connection closed by 172.31.2.12 [preauth]

답변3

몇 가지 확실한 확인 사항

  • Authorized_keys ssh-rsa AA...long_line_of_char commentputty gen의 형식은 때때로 다른 형식으로 제공됩니다.

  • 권한 부여:

  • ~user/.ssh/authorized_keys는 -rw-r--r--입니다.

  • ~user/.ssh/는 drwx입니다------

  • ~사용자는 전역적으로 쓸 수 없습니다.

  • 연결하려는 사용자에 따라 키는 ~root 또는 ~user ID에 배포되어야 합니다.

덜 명확한 확인 사항:

  • SSH를 통한 루트 액세스는 허용되지 않습니다. ( PermitRootLogin no또는 댓글)

  • 인증 키의 기본 위치AuthorizedKeysFile %h/.ssh/authorized_keys

  • 그것은 사용자의 홈 디렉토리에 있는 ~ .ssh입니다.

  • Authorized_keys의 사용자 정의 위치 예AuthorizedKeysFile /foo/bar/authorized_keys.%h

  • 즉, 키는 /foo/bardir에 있습니다.

  • authorized_keys.root루트 파일에

  • 사용자 파일에서 authorized_keys.user파일은 루트가 소유합니다.

답변4

좋아요! 한 가지 이유는 passwd 파일에 있는 사용자의 홈 디렉터리가 파일을 복사하려는 디렉터리가 아니기 때문입니다. 루트만 각 소프트웨어에서 복사할 수 있으며 다른 사용자는 복사할 수 없습니다!

예를 들어 /backup 디렉터리에서 복사하는 경우 scp가 인증 키 "/backup/.ssh"에 대한 올바른 경로를 찾을 수 있도록 인증하려는 사용자의 홈 디렉터리가 /backup으로 설정되어 있는지 확인하세요. /"

둘째: Putty 키 생성기의 "ssh-rsa AA...."가 포함된 텍스트를 Authorized_keys 파일의 정확히 한 줄에 복사했는지 확인하세요. "rsa-key-xxx.."와 같이 끝 부분의 설명을 제거할 수 있습니다. Authorized_keys 파일은 사용자/그룹을 소유해야 합니다. 행운을 빕니다!

관련 정보