SSH 키를 사용하여 새 Digital Ocean 물방울 구성. 내가 실행 ssh-copy-id하면 이것이 얻는 것입니다.
ssh-copy-id user@012.345.67.89
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.
그러나 ssh를 시도하면 다음과 같은 일이 발생합니다.
ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password:
암호를 입력하면 로그인 상태가 좋지만 이것은 당연히 처음에 SSH 키를 만드는 목적에 위배됩니다. 나는 ssh-agent 서버 측을 살펴보기로 결정했으며 여기에 내가 얻는 것이 있습니다.
user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.
user / .ssh / authorized_keys에는 ssh-rsa 키 항목도 포함되어 있지만 find -name "keynamehere"아무것도 반환하지 않습니다.
답변
ssh-add클라이언트 머신에서 실행 하면 에이전트에 SSH 키가 추가됩니다.
ssh-add -l(클라이언트에서 다시) 실제로 추가 되었는지 확인 합니다.
답변
Fedora 26을 28로 업그레이드 한 후에도 동일한 문제가 발생했습니다. 그리고 다음 로그가 누락되었습니다.
/var/log/secure
/var/log/messages
발행물:
antop@localmachine ~ ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:
오류 메시지가 실제 문제를 가리 키지 않습니다. 해결 된 문제
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
답변
Linux Ubuntu 18 에서 동일한 문제가 발생했습니다 . Ubuntu 17.10 에서 업데이트 한 후 모든 git 명령이 해당 메시지를 표시합니다.
이 문제를 해결하는 방법은 사용자에게 올바른 권한이 있는지 확인하는 것입니다. id_rsa 및id_rsa.pub 입니다.
를 사용하여 현재 chmod 번호를 확인하십시오 stat --format '%a' <file>. 이 있어야 600 대 id_rsa 및 644 에 대한id_rsa.pub .
파일 사용 권한을 변경하려면
chmod 600 id_rsa
chmod 644 id_rsa.pub
업데이트로 내 문제가 해결되었습니다.
답변
이 문제를 해결하려면 아래 명령을 실행하십시오.
그것은 나를 위해 일했습니다.
chmod 600 ~/.ssh/id_rsa
답변
gpg-agent를 ssh-agent로 사용하고 gpg 하위 키를 ssh 키로 사용할 때 오류가 발생했습니다 https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .
내 sway 구성에 사용 된 sleep + lock 명령으로 인해 gpg에 대한 잘못된 핀 항목 tty가 발생하여 문제가 발생한 것으로 의심됩니다.
bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"
또는 잠자기 / 일시 중지
핀 항목 tty를 재설정하여 문제를 해결하십시오.
gpg-connect-agent updatestartuptty /bye > /dev/null
내 sway sleep + lock 명령 수정 :
bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"
답변
이 오류에 대해 :
# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Github 계정> 프로필> ssh에서 공개 키를 확인하거나 다시 추가합니다.
나는 다음과 같이 해결했다.
# chmod 400 ~/.ssh/id_rsa
# ls ~/.ssh/id_rsa -ls
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26 2017 /home/reinaldo/.ssh/id_rsa
# git pull
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.
감사합니다.
답변
SSH 오류가 발생하는 데는 여러 가지 이유가있을 수 있습니다.
sign_and_send_pubkey : 서명 실패 : 에이전트가 작업을 거부했습니다.
그들 중 일부는 다른 답변 (이 스레드 답변 참조)에 의해 강조된 문제와 관련이있을 수 있으며, 일부는 숨겨 질 수 있으므로 면밀한 조사가 필요합니다.
제 경우에는 다음과 같은 오류 메시지가 나타납니다.
sign_and_send_pubkey : 서명 실패 : 에이전트가 작업을 거부했습니다.
user@website.domain.com : 권한 거부 됨 (publickey, gssapi-keyex, gssapi-with-mic)
실제 문제를 찾는 유일한 방법은 -v verbose 옵션 을 호출하여 많은 디버깅 정보를 인쇄하는 것입니다.
debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1
줄은 key_load_public: No such file or directory 은 이전 행이 아니라 다음 행을 참조하는 것입니다.
그래서 SSH가 실제로 말하는 것은 이름이 지정된 공개 키 파일을 찾을 수 없으며 id_rsa.website.domain.com-cert내 공개 키 파일에 -cert접미사가 포함되어 있지 않기 때문에 내 경우에는 문제가 된 것 같습니다 .
간단히 말해서, 제 경우의 수정 사항은 공개 키 파일의 이름이 예상대로 지정되었는지 확인하는 것이 었습니다. 연결을 디버깅하지 않고서는 결코 의심 할 수 없었습니다.
결론은 SSH VERBOSE 모드 (-v 옵션)를 사용하여 무엇이 잘못되었는지 파악하는 것입니다. 다양한 이유가있을 수 있으며이 / 다른 스레드에서 찾을 수있는 것은 없습니다.
