공개 키 인증을 사용하여 ssh로 비밀번호 프롬프트가 계속 표시되는 이유는 무엇입니까?

내가 찾은 URL에서 일하고 있습니다.

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

내 ssh 클라이언트는 Ubuntu 64 비트 11.10 데스크톱이고 서버는 Centos 6.2 64 비트입니다. 지시를 따랐습니다. 여전히 ssh에서 비밀번호 프롬프트가 표시됩니다.

다음에 무엇을해야할지 모르겠습니다.

~/.ssh디렉토리 및 해당 컨텐츠 에 대한 권한이 올바른지 확인하십시오 . ssh 키 인증을 처음 설정할 때 ~/.ssh폴더가 제대로 설정 되지 않았고 나에게 소리 쳤다.

• 여러분의 홈 디렉토리 ~, 사용자 ~/.ssh디렉토리와 ~/.ssh/authorized_keys: 원격 컴퓨터의 파일 만 쓸 수 있어야 rwx------하고 rwxr-xr-x잘하지만, rwxrwx---(: 당신이 숫자 모드를 선호하는 경우에 당신은 당신의 그룹에서 유일한 사용자 인 경우에도, 어떤 good¹가 없다 700거나 755,하지 775) .
  만약 ~/.ssh또는 authorized_keys심볼릭 링크입니다 (확장 심볼 링크) 정식 경로를 확인합니다 .
• ~/.ssh/authorized_keys원격 컴퓨터 의 파일을 읽을 수 있어야합니다 (최소 400). 키를 더 추가하려면 쓰기 가능해야합니다 (600).
• (로컬 컴퓨터) 귀하의 개인 키 파일을 읽을 수 있고 당신 만 쓰기 가능해야합니다 rw-------, 즉 600.
• 또한 SELinux가 적용되도록 설정되어 있으면 실행해야 할 수도 있습니다 restorecon -R -v ~/.ssh(예 : Ubuntu 버그 965663 및 데비안 버그 보고서 # 658675 ; CentOS 6에 패치되어 있음 ).

¹ _{그룹의 유일한 사용자 인 경우 그룹 쓰기 권한을 허용하도록 코드를 패치 한 일부 배포 (Debian 및 파생 상품)를 제외하십시오.}

서버에 대한 루트 액세스 권한이있는 경우 이러한 문제를 해결하는 쉬운 방법은 서버에서와 같은 것을 실행 /usr/sbin/sshd -d -p 2222하여 (sshd 실행 파일에 대한 전체 경로가 필요하며 which sshd도움을 줄 수 있음) 디버그 모드에서 sshd를 실행 한 다음을 사용하여 클라이언트에서 연결하는 것입니다 ssh -p 2222 user@host. 그러면 SSH 데몬이 포 그라운드로 유지되고 모든 연결에 대한 디버그 정보가 표시됩니다. 같은 것을 찾으십시오

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

대체 포트를 사용할 수없는 경우 SSH 디먼을 일시적으로 중지하고 디버그 모드에서이를 대체 할 수 있습니다. SSH 데몬을 중지해도 기존 연결이 끊어지지 않으므로 원격 터미널을 통해이 작업을 수행 할 수 있지만 다소 위험합니다. 디버그 교체가 실행되지 않을 때 연결이 끊어지면 시스템에서 잠 깁니다. 다시 시작할 수있을 때까지 필요한 명령 :

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(Linux 배포판에 따라 첫 번째 / 마지막 줄은 systemctl stop sshd.service/ 일 수 있습니다 systemctl start sshd.service.)

집 디렉토리가 암호화되어 있습니까? 그렇다면 첫 번째 ssh 세션의 경우 비밀번호를 제공해야합니다. 동일한 서버에 대한 두 번째 ssh 세션이 인증 키로 작업 중입니다. 이 경우 authorized_keys암호화되지 않은 디렉토리 로 이동하여 에서 경로를 변경할 수 있습니다 ~/.ssh/config.

내가 한 일은 /etc/ssh/username올바른 권한으로 사용자 이름이 소유 한 폴더를 만들고 authorized_keys거기에 파일을 저장하는 것입니다. 그런 다음 AuthorizedKeysFile 지시문을 다음으로 변경하십시오 /etc/ssh/config.

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

이를 통해 여러 사용자가 권한을 손상시키지 않고이 ssh 액세스 권한을 가질 수 있습니다.

원격 컴퓨터에 키를 복사하고 내부에 넣은 authorized_keys후에는 다음과 같이해야합니다.

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

다음 명령을 시도해보십시오.

1. ssh-keygen

   프롬프트가 표시 될 때까지 Enter 키를 누르십시오

2. ssh-copy-id -i root@ip_address

   (한 번 호스트 시스템의 비밀번호를 요구합니다)

3. ssh root@ip_address

   이제 비밀번호없이 로그인 할 수 있어야합니다

원격의 홈 디렉토리에 올바른 권한이없는 경우 문제가 발생했습니다. 필자의 경우 사용자 는 팀에서 로컬 액세스를 위해 홈 디렉토리를 777 로 변경했습니다 . 머신이 더 이상 ssh 키로 연결할 수 없습니다. 권한을 744로 변경하고 다시 작동하기 시작했습니다.

RedHat / CentOS 6의 SELinux 에는 pubkey 인증에 문제가 있습니다 . 아마도 일부 파일이 생성 될 때 selinux가 ACL을 올바르게 설정하지 않았을 것입니다.

루트 사용자의 SElinux ACL을 수동으로 수정하려면 다음을 수행하십시오.

restorecon -R -v /root/.ssh

우리는 같은 문제에 부딪 쳤고 대답의 단계를 따랐습니다. 그러나 여전히 우리에게는 효과가 없었습니다. 우리의 문제는 로그인이 한 클라이언트에서 작동했지만 다른 클라이언트에서는 작동하지 않았다는 것입니다.

그래서 한 걸음 더 나아가 야했습니다. 상세 모드에서 ssh 명령을 실행하면 많은 정보를 얻을 수 있습니다.

ssh -vv user@host

우리가 발견 한 것은 기본 키 (id_rsa)가 받아 들여지지 않고 ssh 클라이언트가 클라이언트 호스트 이름과 일치하는 키를 제공한다는 것입니다.

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

분명히 이것은 다른 클라이언트에서는 작동하지 않습니다.

따라서 우리의 해결책은 기본 rsa 키를 user @ myclient를 포함하는 키로 전환하는 것이 었습니다. 키가 기본값이면 클라이언트 이름을 확인하지 않습니다.

그런 다음 스위치 후 다른 문제가 발생했습니다. 분명히 키는 로컬 ssh 에이전트에 캐시되어 있으며 디버그 로그에 다음 오류가 발생했습니다.

'Agent admitted failure to sign using the key'

이것은 키를 ssh 에이전트에 다시로드하여 해결되었습니다.

ssh-add

서버 끝에서 SSH 누락 구성입니다. 서버 측 sshd_config 파일을 편집해야합니다. 에 위치하고 있습니다 /etc/ssh/sshd_config. 해당 파일에서 변수를 변경하십시오.

• ChallengeResponseAuthentication, PasswordAuthentication, UsePAM의 경우 'yes'에서 'no'

• PubkeyAuthentication의 경우 '아니오'에서 '예'

http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/ 기반

AuthorizedKeysFile올바른 위치 를 가리키고 %u사용자 이름의 자리 표시 자로 사용하십시오 .

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

행의 주석을 해제해야 할 수도 있습니다.

AuthorizedKeysFile .ssh / authorized_keys

변경 사항을 적용하려면 ssh 서비스를 다시로드해야합니다.

service sshd reload

두 개의 주석 : 원본 파일을 덮어 씁니다. 생성 된 공개 키를 복사하고 다음과 같은 작업을 수행합니다.

cat your_public_key.pub >> .ssh/authorized_keys

기존 키 목록에 사용하려는 키가 추가됩니다. 또한 일부 시스템은 파일을 사용 authorized_keys2하므로 경우를 위해 authorized_keys와 사이를 가리키는 하드 링크를 만드는 것이 좋습니다 authorized_keys2.

내 해결책은 계정이 잠겨 있다는 것입니다. / var / log / secure에있는 메시지 : 계정이 잠겨 있기 때문에 사용자가 허용되지 않습니다. 해결책 : 사용자에게 새 암호를 제공하십시오.

비슷한 문제가 발생하여 디버그 모드를 사용하여 단계를 수행했습니다.

/usr/sbin/sshd -d

이것은 다음과 같은 결과를 보여 주었다

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

정말 혼란 스러웠다

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

루트 디렉토리에 모든 권한이 있음을 보여줍니다. 다른 사람이 권한을 갖지 않도록 변경했습니다.

[root@sys-135 ~]# chmod 750 /root

키 인증이 작동하기 시작했습니다.

/ etc / selinux / config 파일에서 SELINUX를 disabled로 변경하면 암호없는 ssh가 성공적으로 작동합니다.

이전에는 한 가지 방법으로 할 수 있습니다. 이제는 양방향으로 암호가없는 ssh를 수행 할 수 있습니다.

내가 틀린 한 가지는 서버 시스템의 홈 디렉토리에 대한 소유권이었습니다. 서버 시스템은 default : default로 설정되었으므로 I :

chown -R root:root /root

그리고 효과가있었습니다. 또 다른 저렴한 해결 방법은 엄격한 모드를 비활성화하는 것입니다. StirctModes no. sshd_config에서. 적어도 키 교환 및 연결 프로토콜이 좋은지 알려줍니다. 그런 다음 나쁜 권한을 사냥 할 수 있습니다.

나를 위해,이 솔루션은 반대였다 보이 테크 Rzepala의 : 나는 아직도 사용하고 있었다 통지를하지 않았다 authorized_keys2, 이는 사용되지 않습니다 . 아마도 서버가 업데이트되었을 때 내 ssh 설정이 어느 시점에서 작동을 멈췄습니다. 이름 변경 .ssh/authorized_keys2으로 .ssh/authorized_keys문제를 해결.

도!

과거에는 ssh 암호가없는 설정을 얻는 방법을 설명하는 자습서를 보았지만 슬프게 잘못되었습니다.
다시 시작하고 모든 단계를 확인하십시오.

1. FROM CLIENT- 키 생성 : ssh-keygen -t rsa
   공개 및 개인 키 ( id_rsa.pub및 id_rsa)가 ~/.ssh/디렉토리에 자동으로 저장됩니다 .
   빈 암호를 사용하면 설치가 더 쉬워집니다. 그렇게하지 않으려면이 가이드를 계속 따르고 아래 글 머리 기호도 확인하십시오.
   
   
2. 클라이언트에서 공개 키- 서버에 공개 키 복사 : ssh-copy-id user@server
   클라이언트 공개 키가 서버 위치에 복사됩니다 ~/.ssh/authorized_keys.
   
   
3. 클라이언트에서 -서버에 연결 :ssh user@server
   
   

설명 된 3 단계 후에도 여전히 작동하지 않으면 다음을 시도해보십시오.

• 클라이언트 및 서버 컴퓨터 ~/ssh에서 폴더 권한을 확인하십시오 .
• 확인 /etc/ssh/sshd_config에 서버 을 보장하기 위하여 RSAAuthentication, PubkeyAuthentication그리고 UsePAM옵션이 비활성화되지 않습니다, 그들은 기본적으로 활성화 할 수 있습니다 yes.
• 클라이언트 키를 생성하는 동안 암호를 입력 한 경우에, 당신은 시도 할 수 ssh-agent및 ssh-add세션의 암호없는 연결을 달성하기 위해.
• 의 내용을 확인 /var/log/auth.log상의 서버 키 인증이 모두 생략 왜 문제를 찾을 수 있습니다.

Pubunty가 Ubuntu 16.04 시스템에 연결하는 것과 똑같은 문제가 발생했습니다. PuTTY의 pscp 프로그램이 동일한 키를 사용하여 제대로 작동했기 때문에 다른 호스트에 연결하기 위해 PuTTY에서 동일한 키가 작동했기 때문에 당황했습니다.

@UtahJarhead의 소중한 의견 덕분에 /var/log/auth.log 파일을 확인하고 다음을 발견했습니다.

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

최신 버전의 OpenSSH는 기본적으로 DSA 키를 허용하지 않습니다. DSA에서 RSA 키로 전환하면 정상적으로 작동했습니다.

또 다른 방법 :이 문제는 DSA 키를 허용하도록 SSH 서버를 구성하는 방법에 대해 설명합니다 : https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

이 단계는 도움이 될 것입니다. 나는 이것을 많은 64 비트 우분투 10.04 컴퓨터에서 정기적으로 사용합니다.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

프롬프트가있는 스크립트에 이것을 넣고 다음과 같이 호출 할 수 있습니다

script_name username remote_machine

ssh와 비슷한 문제가있었습니다. 내 경우에는 문제는 hadoop cloudera (centos 6의 rpm에서)를 설치하고 홈 디렉토리로 hdfs 사용자를 생성했다는 것입니다

/var/lib/hadoop-hdfs(표준 /home/hdfs아님).

나는 / etc / passwd에의 변경 /var/lib/hadoop-hdfs을 /home/hdfs새로운 위치로 홈 디렉토리를 이동하고 지금은 공개 키 인증으로 연결할 수 있습니다.

방금이 같은 문제가 있었고 해결책은로 설정 UsePAM되었습니다 no. 로 PasswordAuthentication설정해 도 no여전히을 얻을 수 keyboard-interactive있으며 제 경우에는 로컬 ssh 프로그램이 어떤 이유로 든 기본 설정을 유지했습니다.

동일한 상황을 가진 사람을 돕기위한 추가 배경 : Dropbear를 실행하는 호스트에서 OpenSSH를 실행하는 호스트로 연결하고 있습니다. 로 PasswordAuthentication와 UsePAM모두 설정 no원격 시스템에서 내가 입력하면, 나는 다음과 같은 메시지가 나타납니다 ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

로 ID 파일을 제공하면 -i모든 것이 예상대로 작동합니다.

여기에 약간의 정보가 더있을 수 있습니다.

권한을 확인하고 여기에 나열된 몇 가지 다른 솔루션을 시도한 후 마침내 서버의 ssh 디렉토리를 제거하고 공개 키를 다시 설정했습니다.

서버 명령 :

# rm -rf ~/.ssh

로컬 명령 :

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

서버에서 :

$ ls -lh /home
$ sudo chmod 700 /home/$USER

이었다 directory permission issue. 서버에서 777이었습니다 I changed it back to 700. 이 fixed문제는 서버에 ssh password less login failure복사 한 후에도 발생 $USER/.ssh/id_rsa.pub합니다 $USER/.ssh/authorized_keys.

또 다른 옵션은 @Jagadish의 답변 : stracessh 데몬에 대한 변형입니다 .

그것은 우리가 sshd를 멈출 필요가 없다는 중요한 이점을 가지고 있습니다. 무언가가 잘못되면 완전한 잠금이 발생할 수 있습니다.

먼저 주요 sshd 프로세스의 pid를 찾습니다. 여기에서를 실행하여 볼 수 있습니다 pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

pid가 633이라는 것을 알면 strace자식을 따라 할 수 있습니다 .

strace -p 633 -s 4096 -f -o sux

결과적 으로이 sshd 및 해당 하위 프로세스가 수행 한 모든 작업이 sux로컬 디렉토리에 이름이 지정된 파일로 추적됩니다 .

그런 다음 문제를 재현하십시오.

커널 호출 로그의 방대한 목록을 가질 것입니다.이 목록은 대부분 이해하기 어렵거나 관련이 없지만 어디에서나 아닙니다. 필자의 경우 중요한 것은 다음과 같습니다.

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

그것은 sshd 가 계정이 잠겨 있기 때문에 User cica not allowed 메시지를 기록하려고 시도한 것 입니다. 로깅이 그다지 장황하지 않기 때문에 불가능했습니다. 그러나 우리는 이미 계정이 잠겨 있기 때문에 pubkey가 거부되었음을 알고 있습니다.

아직 해결책이 아닙니다. 이제 sshd의 경우 "잠금 계정"을 의미하는 Google이 필요합니다. 그것은 가장 가능성이 몇 가지 사소한 것 /etc/passwd, /etc/shadow마법,하지만 중요한 것은 이루어집니다 - 문제가 신비한 아니다, 그러나 googlable / 쉽게 디버깅 하나.

제 경우에는 모든 권한을 가지고 있었고 -vvv 플래그로 ssh를 실행할 때도 문제가 무엇인지 알 수 없었습니다.

그래서 원격 호스트 에서 새 인증서를 생성했습니다.

ssh-keygen -t rsa -C "your_email@example.com"

생성 된 키를 로컬 시스템에 복사하고 새 공개 키를 원격 호스트의 ~ / .ssh / authorized_keys에 추가했습니다.

cat id_rsa.pub >> authorized_keys

원격 호스트 시스템 연결에서 생성 된 키 사용이 이제 작동합니다. 따라서 다른 솔루션이 실패하면 시도해야 할 또 다른 것입니다.

내 시나리오는 backupbot기본 계정을 만든 후 사용자를 생성 한 NAS 서버를 가지고 있었고, 처음에 backupbot사용자를 생성하기 위해 로그인 할 수있었습니다 . 손보는 후 sudo vim /etc/ssh/sshd_config1, 및 생성 backupbot사용자를 vim적어도 우분투 16.04에, 만들 수 있습니다, 당신을 기반으로 ~/.vimrc설정하는 스왑 파일은 당신의 정력 세션의 편집에서 왼쪽 /etc/ssh/sshd_config.

/etc/ssh/.sshd_config.swp존재 여부를 확인하고 이를 제거하고 sshd디먼을 다시 시작 하는지 확인하십시오 .

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

이것은 마술처럼 내 문제를 해결했습니다. 이전에 모든 권한과 공개 및 개인 키의 RSA 지문을 확인했습니다. 이것은 이상하고 아마도, 특히이 sshd버전 의 버그 일 것입니다 .

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 2016 년 3 월 1 일