xfce를 사용하여 xubuntu 16.04를 실행하면서 비밀번호와 함께 SSH 키를 사용해 보았습니다. SSH-agent에 암호 키를 추가하고 싶지만 추가할 수 없는 이유를 모르겠습니다. 시작 시 그놈 키링이나 이와 유사한 항목이 활성화되어 있지 않습니다. ssh-add privatekey, 키를 추가하지만 ssh를 다시 시도하면 오류가 두 번만 인쇄됩니다. 일부 수정에서는 시작 시 그놈 키링을 비활성화하라고 되어 있지만 저는 이를 비활성화했습니다. 이 모든 일은 Raspberry Pi에서 SSH 키를 변경할 때 일어났습니다.
> OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/potato/.ssh/config
debug1: /home/potato/.ssh/config line 1: Applying options for paj
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 111.229.105 [111.229.105] port 22253.
debug1: Connection established.
debug1: identity file /home/potato/.ssh/hplaptop_to_pi type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/potato/.ssh/hplaptop_to_pi-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 111.229.105:22253 as 'pi'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:zrjeaaHD8TjzsdsdssssA2fXnG3gxp2U
debug1: Host '[111.229.105]:22253' is known and matches the ECDSA host key.
debug1: Found key in /home/potato/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/potato/.ssh/hplaptop_to_pi
debug1: Server accepts key: pkalg ssh-rsa blen 535
sign_and_send_pubkey: signing failed: agent refused operation
debug1: Offering RSA public key: potato@potato-HP-tomato
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: potato@hplaptop
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: potato@hplaptop
debug1: Server accepts key: pkalg ssh-rsa blen 535
sign_and_send_pubkey: signing failed: agent refused operation
debug1: Offering RSA public key: rsa-key-20141222
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: potato@potatolaptop
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
답변1
그래서 몇 시간 동안 무의미한 인터넷 검색과 도움 끝에 문제가 발견되었습니다. ssh-keygen을 사용하여 SSH 키를 생성하고 새로운 형식의 openSSH용 키를 생성하는 추가 매개변수 "-o"를 추가했습니다. 문제는 이러한 키에 Ed255519 서명 체계가 있기 때문에 내 gnome-keyring이 이러한 키를 지원하지 않는다는 것입니다. 3.20부터 Gnome-keyring은 더 이상 이 기능을 지원하지 않습니다. RSA로 되돌렸는데 더 이상 문제가 없습니다!
답변2
제 경우에는 그놈 키링이 잘못된 SSH 키 비밀번호를 보유하고 있다는 것이 문제였습니다. 이것을 알아내는데 많은 시간을 보낸 후, 나는 달려가서 seahorse빈 문자열을 담고 있는 항목을 발견했습니다.
이전에 처음 사용할 때 잘못된 비밀번호를 입력한 다음 요청자 등을 취소하여 명령줄로 돌아가서 발생한 것이라고 추측할 수 있습니다.
올바른 비밀번호로 항목을 업데이트하면 문제가 즉시 해결되었습니다.
항목을 제거하고("로그인" 키링에서) 첫 번째 프롬프트에서 비밀번호를 다시 입력하고 해당 확인란을 선택하면 문제가 해결됩니다.
이제 에이전트는 "login"이라는 이름의 로그인 시 잠금 해제 키링에서 올바른 비밀번호를 가져오며 더 이상 비밀번호를 묻거나 "작업 거부"를 하지 않습니다. 물론 YMMV.
답변3
이러한 유형의 문제를 해결하기 위한 많은 제안은 ~/.ssh 디렉토리와 여기에 포함된 파일의 권한 변경을 의미합니다. 더 많은 관련 콘텐츠:https://gist.github.com/grenade/6318301
ssh-add어떤 사람들은 이것이 문제를 해결하지 못할 수도 있고 중복될 수도 있다고 제안하기도 했습니다 .
위의 두 가지 방법을 시도한 후에도 문제가 해결되지 않았습니다. 대신 문제는 내가 생성하는 SSH 키 유형에 있습니다.
@strudelj nakedlj가 언급했듯이 연결하려는 서버가 공개 키가 사용하는 암호화 유형을 지원하는지 확인하는 것이 중요합니다. 예를 들어, 제가 사용하려는 gitlab 서버는 일반적으로 다음에 저장된 키 유형을 지원하지 않습니다.~/.ssh/id_dsa.pub
대신 ed25519rsa 암호화 키가 필요합니다.
의 경우 ed25519다음을 사용할 수 있습니다. 키 생성$ssh-keygen -t ed25519 -C "[email protected]"
그런 다음 $ssh -T user@server키가 승인되고 연결이 설정될 수 있는지 다시 확인해야 합니다.