시스템에서 Ubuntu 15 파티션을 완전히 삭제하여 Ubuntu 시스템을 15.10에서 16.04로 업그레이드했습니다.

우분투 16.04를 설치 한 후 백업을 잊어 버렸을 때 ssh 키를 다시 만들었지 만 ssh를 사용하려고 할 때마다 sign_and_send_pubkey: signing failed: agent refused operationssh 서버로 연결할 수 있기 때문에 약간 성가 시지만 git은 ssh를 사용하여 코드 푸시를 거부합니다.

를 사용하여 키를 서버에 이미 푸시했습니다 ssh-copy-id.

내가 연결하는 서버는 do-release-upgrade명령을 통해 업그레이드 된 Ubuntu 16.04 서버 입니다. 어떤 도움이라도 대단히 감사하겠습니다.

ssh-agent이미 실행중인 것처럼 보이지만 연결된 키를 찾을 수 없습니다. 이를 해결하려면 개인 키 ID를 인증 에이전트에 다음과 같이 추가하십시오.

ssh-add

그런 다음 ssh서버에 들어갈 수 있습니다 .

또한 현재 다음에 의해 추가 된 모든 신원의 지문 목록을 볼 수 있습니다.

ssh-add -l

간단한 솔루션

우분투 18.04에서 같은 문제가있었습니다. 이것이 클라이언트 측 개인 키 권한에 관한 것 입니다.

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

파일 권한이 너무 열려 있습니다 (0644).

다음 명령으로 해결되었습니다.

chmod 600 ~/.ssh/id_rsa

나는 같은 문제가 있었다 (같은 증상)

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

...하지만 해결책은 달랐습니다.

그놈 키링을 사용하여 문제가 발생했습니다. 해결책을 언급하는 게시물은 여기에서 읽을 수 있습니다 .

한마디로 :

1. ssh 명령 앞에 SSH_AUTH_SOCK = 0을 추가하여 문제점을 감지하십시오. sam @ xxxxx : ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. 연결에 성공한 경우 응용 프로그램 시작 응용 프로그램 (예 : 데스크탑의 검색 기능을 사용하여)을 열고 그놈 키링 사용을 비활성화하십시오.
3. 재부팅

이 페이지는 다른 솔루션으로 비슷한 문제가 발생할 경우 다른 세부 정보를 제공합니다.

나는를 얻고 있었다 sign_and_send_pubkey: signing failed: agent refused operation여러 서버에 로그인 할 때, 읽기 스택 오버플로 VonC의 답변을 나를 위해 솔루션 SSH 에이전트 및 재부팅에서 ID를 삭제 그놈 키링을 제거하는 것이었다 관련 버그에 대한 자세한 내용은.

sudo apt-get autoremove gnome-keyring
ssh-add -D

그런 다음 모든 키가 완벽하게 작동하기 시작했습니다.

최신 정보:

키링을 제거하지 않는 임시 솔루션

그놈 키링을 유지하고 agent refused operation오류가 발생하면 다음을 사용하십시오.

eval `ssh-agent -s`
ssh-add

또는 사용 SSH_AUTH_SOCK=0 ssh your-server

키링을 제거하지 않고 영구적 인 솔루션

가능하면 gnome-keyring은 4096 비트 RSA 키와 호환되므로 다음을 사용하여 새 키를 생성하십시오.

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

서버에 공개 키 업로드

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

에이전트에 ssh 키 추가

ssh-add ~/.ssh/your-key-name

이것은 추가 해킹없이 작동하며 그놈 키 링은 설치된 상태로 유지 될 수 있습니다.

(-C [사용자 이름]은 선택 사항이지만 Google Cloud와 같은 제공 업체는 필수입니다)

Ubuntu 18.04로 업그레이드 한 후에도 같은 오류가 발생했습니다 sign_and_send_pubkey: signing failed: agent refused operation. ssh 키의 권한이 너무 열려 있기 때문에 발생했습니다. 다음 명령으로 문제가 해결되었습니다. chmod 600 .ssh/id_rsa

내 시스템 (Ubuntu 16.04, github에 연결하려고 함)에서 .ssh 폴더에 id_ed25519 파일이있어 ssh-add실패했습니다.

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

파일을 제거한 후 ~/.ssh/id_ed25519*(더 이상 필요하지 않았지만 이전 테스트에서 얻은 것임) 모든 것이 다시 정상적으로 진행되었습니다.

개인 키에 암호가 있었기 때문에 나에게 일어났다. 실행 ssh-add한 다음 암호 문구를 요청하고 올바르게 추가했습니다. 그러나 이제 컴퓨터에 ssh 할 때 암호 문구를 요구하지 않습니다.

Ubuntu16.04를 새로 설치했는데 비슷한 문제가 발생했습니다. github에 공개 키를 복사 한 후 ( github.com의 지침에 따라 ) github에서 저장소를 복제하려고 할 때 ( github.com에서 권장되는 ) 다음 검사를 수행 한 후 :

ssh -T git@github.com

나는 다음과 같이 인사했다.

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

아무것도 제거하거나 시작 구성을 변경하지 않고 신속하게 수정하기 위해 터미널에 다음을 입력했습니다.

killall gnome-keyring-daemon

그런 다음 클론이 작동했습니다. 그런 다음 다음을 입력하여 중지 된 데몬을 다시 시작했습니다.

gnome-keyring-daemon

나중에보다 영구적 인 방식으로 사물을 변경하기 위해 여기에 있는 조언을 따랐습니다 .

Fedora 26을 28로 업그레이드 한 후에도 같은 문제에 직면했습니다. 그리고 로그 파일이 없습니다

no /var/log/secure
no /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/*

ed25519 키와 동일한 문제가 있었으므로 주석 추가. 문제는 실제로 그놈 키링입니다. 이 문제를 해결하기 위해 다음을 수행했습니다.

• "시작 응용 프로그램"에서 확인되지 않은 ssh-key-agent (그놈 키링)
• ssh-agent 및 gnome agent를 종료 (killall ssh-agent; killall gnome-keyring-daemon)
• 데몬을 다시 시작했습니다 : (eval ssh-agent -s)
• 키 추가 : $ ssh-add id_ed25519 id_ed25519의 암호 입력 : ID 추가 : id_ed25519
• 이익!!

2018 년 말 이며이 버그 또는 그 변형은 여전히 ​​Xubuntu 16.04 및 다른 Xenial 풍미보다 더 많이 전염됩니다. 18.04에도 존재한다면 놀라지 않을 것입니다! 2009 년 이후로 어떤 형태로 있었으며 Karmic Koala. Redhat, Debian 및 Ubuntu에 영향을 미쳤습니다. 내 말을 들지 말고 공개 버그 추적기를 참조하십시오.

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

그리고 그 버그에서, 당신은 또한 다른 3에 대한 목록을 찾습니다 :

참고 문헌 :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

필자의 경우 가장 명백한 증상은 암호문과 함께 ssh 키를 사용할 수 없다는 것입니다. 오작동으로 인해 ssh 키가 전혀로드되지 않으므로 영향을 미치지 않을 수 있습니다! 그리고 권한 문제가 없었습니다. 모두 그놈 키링이었습니다. 내 키 (예, 다른 SSH 서버의 경우 여러 개를 거부했습니다!) 권한은 모두 600 개 (소유자에게는 rw, 그룹 또는 기타는 없음)였습니다. 그래서 나는 거기에서 아무것도 바꿀 수 없었습니다.

Xubuntu에는 시작 항목을 비활성화하는 방법이 있습니다. 일반적으로 Unity / Gnome / KDE에서도 가능하지만 설치되어 있지 않으므로 특정 단계를 수행 할 수 없습니다. 다른 데스크탑을 잘 모릅니다. Gnome의 SSH 에이전트, GPG 에이전트 및 기타 항목 및 기타 관련 버그를 비활성화하는 대신 모든 Gnome 시작 항목을 해제했습니다. 과도하거나 일부 옵션이 아닐 수 있지만 다음에 다시 부팅 할 때 SSH가 완벽하게 작동합니다!

1. Whisker 기본 메뉴-> 설정-> 세션 및 시작을여십시오.
2. 오른쪽에있는 고급 탭을 클릭하십시오.
3. 시작시 Gnome Services 시작을 선택 취소 (끄기)합니다.
4. 닫고 재부팅하십시오. 로그 아웃해도 가능하지만 재부팅해야합니다.

위에서 설명한 GUI의 스크린 샷 :

따라서 위의 수정 사항을 제공했기 때문에 누군가가 수정하기를 바랍니다.

우분투는 여러 릴리스에 대한 티켓이 많기 때문에 수정에 실패하고 "회귀"라고 말하는 티켓이 많기 때문에 아마 그것을 스쿼시하지 못했습니다.

데비안은 아마도 그들이 아니기 때문에 펀트를하고 싶을 것입니다 (그들의 손을 씻으십시오). 상류는 그놈입니다.

Redhat은 유료 고객 만 사용할 수있는 수정 프로그램이있을 수 있습니다. 역사적으로 Redhat은 유료 Gnome 개발자의 가장 큰 고용주이기 때문에 언뜻보기에 관대합니다. 그 사실을 알기 전까지는 Redhat 구독을 계속 판매하기 위해 이와 같은 수정 프로그램을 무료 버전에 넣지 마십시오.

Gnome은 아마도 업스트림에서 가장 쉽게 고칠 수 있고 다른 코드는 직접 작성하지 않고도 테스트하고 패키징 할 수 있습니다. 그러나 내가 읽은 티켓은 패키지가 공식 관리자가 아니라 몇 년 동안 고생했다고 말합니다! 그리고 자발적으로 그렇게 한 두 사람 (감사합니다)은 대체물을 설계하는 데 거의 바쁩니다. 휠을 먼저 재창조하는 대신 1 년이 걸리더라도 (10 년이 지났음) 플랫 타이어를 수리 해보십시오.

ssh-add

나를 위해 작동합니다. 그러나 반드시

ssh- 에이전트

실행 중입니다.

제 경우에는 그놈 키링으로 인해 문제가 발생했습니다. gnome-keyring의 SSH 기능을 완전히 제거 하지 않고 비활성화 하려면 (많은 것들이 깨짐) 다음 지침을 따르십시오 .

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

세션을 다시 시작하십시오. 이제 그놈 키링 방해없이 ssh-agent를 실행할 수 있습니다.

나는 ssh-add, SSH 재설정 (서버에서 .ssh / 삭제 등)을 시도했지만 운이 없었기 때문에 밤새 잠을 자야한다는 것이 밝혀졌습니다. 서버에서 실행되는 ssh-agent가 캐시에 무언가 적절한 값으로 오늘 밤에 새로 고쳐 졌다고 생각합니다. 어쨌든 이제는 매력처럼 작동합니다. 14.04 서버).

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)

알려진 호스트 파일을 삭제하고 작동했습니다. 비밀번호를 다시 입력해야했지만 마침내 올바른 비밀번호를 수락했습니다. 새로 설치 한 후에였습니다.

ssh 명령이 도움이되기 전에 SSH_AUTH_SOCK = 0을 추가하면 키링 오류가 발생하지 않습니다. 제공된 솔루션 및 문제를 제외하고 문제는 암호와 관련이있을 수 있습니다. 키에 대한 암호가있는 경우 gnome keyring은 처음 로그인 할 때 묻고 오류로 인해 비어 있거나 입력 창을 예기치 않게 닫으면 gnome은 암호를 빈 암호로 가정하여 영원히 기억합니다. 암호를 다시 입력하라는 메시지가 표시되지 않습니다. 열린 ssh 키링 앱을 해결하고 비밀번호 카테고리 아래의 로그인 섹션으로 이동하십시오. 문제가있는 키에 해당하는 레코드를 찾아 속성에 입력하고 올바른 암호를 입력하십시오.

아직 답변이없는 또 다른 원인이 있습니다. 키 파일의 PEM 형식은 ssh-keygen우분투 gnome-keyring-daemon가 새로운 RFC4716 형식을 지원하는 형식으로 이동하기 전에 기본값이 아닙니다.

새 키를 생성하거나 키에서 암호를 추가 / 제거하면 키가 깨질 수 있습니다. 열쇠는 ssh-keygen -m PEM다른 작업을 실행하기 전에 사용 하고 있습니다. 예를 들어, ssh-keygen -m PEM -p이전 비밀번호 문구를 새 비밀번호 문구 (비밀번호가 없으면 비어 있음)로 사용 하고 입력 하여 이전 형식으로 다시 변환 할 수 있습니다 .