This diagnostic message apparently gets printed for a lot of different reasons, which makes debugging it annoyingly difficult. It's shown up on SO before:
ssh-agent on MAC os which was more about general ssh-agent usage, with the disappointing advice "According to a hearsay, it's only a warning" which doesn't help us solve whatever problem is causing the warning.
sign_and_send_pubkey: signing failed: agent refused operation (ePass2003) was mostly a "how to enable agent forwarding" combined with some advice on restricting file permissions. I've checked the latter (see below) with no luck.
The error shows up in Git SSH Not Working after installing new Dev Shell because the actual error about host keys changing was being ignored.
a github issue boiled down to PuTTY, Pageant, and WSL fighting amongst themselves. Not using WSL here, and while PuTTY does get used it's not in this scenario.
My local host is Cygwin running OpenSSH_9.0p1, and I do the bog standard ssh-agent dance from my Bash profile, followed by ssh-add privkey1 privkey2 .... Running ssh-add -L locally prints the keys with no errors.
There is no /etc/ssh/ssh_config or equivalent on this Cygwin installation. Relevant lines of ~/.ssh/config:
IdentitiesOnly yes
ForwardAgent yes
# There are multiple remote hosts, but they all use identical
# configurations (and different keys)
Host remote-host
Hostname 12.34.56.78, User, etc, elided
IdentityFile path/to/private/key
ForwardAgent yes # redundant, I know
AddKeysToAgent yes
Connecting to a remote host in verbose mode shows the correct identity being offered and accepted
debug1: identity file path/to/private/key type -1
debug1: identity file path/to/private/key-cert type -1
... [all the host key exchange stuff]
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: path/to/private/key
debug1: identity added to agent: path/to/private/key
Authenticated to 12.34.56.78 ([12.34.56.78]:22) using "publickey".
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching known_hosts for 12.34.56.78 / (none)
debug1: Requesting authentication agent forwarding.
debug1: client_global_hostkeys_private_confirm: server used untrusted RSA signature algorithm ssh-rsa for key 0, disregarding
I included the final line because it's the only diagnostic message printed during the login; as it's to do with host keys I don't believe it's related to the agent problem, but am open to advice there.
Some of the remote hosts are running Ubuntu 22.04 and OpenSSH_8.9p1, and there's no problems:
$ ssh-add -L
ssh-rsa AAAAB3Nza...ZyzLVJ3ylFeGDMfb path/to/private/key
However, the other remote hosts are running Amazon Linux 2 (knockoff of CentOS) and OpenSSH_7.4p1:
$ ssh-add -L
error fetching identities for protocol 1: agent refused operation
ssh-rsa AAAAB3Nza...ZyzLVJ3ylFeGDMfb path/to/private/key
The OpenSSH_7.4p1 version is a little older than I'd prefer in a perfect world. I looked at https://www.openssh.com/releasenotes.html for all mentions of ssh-add/ssh-agent and nothing since the 7.4 release looks like it would have fixed this. So maybe it's something on my end.
The ssh_config and sshd_config files on the remote servers are the same (extremely simplistic) settings, other than
Protocol 2
GSSAPIAuthentication no
AllowAgentForwarding yes
nothing jumps out as affecting the below. In particular, note that we restrict clients to using SSH Protocol 2.
On my local host, ~/.ssh is 0700 and no Windows ACLs are present. All the private key files use Windows ACLs to lock down permissions so that PuTTY/Pageant won't complain that the domain administrators can see the keys, oh noes; that folder location is mounted inside Cygwin using the 'acl' mount option, so they all appear inside Cygwin as 0400 with no additional getfacl permissions. So I don't think it's a permissions issue, as they're all pretty restricted the way SSH in general likes them to be.
On the remote hosts, ~/.ssh is 0700 and ~/.ssh/authorized_keys is 0600.
I launched the local ssh-agent with -d to watch its debugging messages, added the appropriate key, and then logged into the AWS Linux / CentOS box. Tracing the ssh-add -L process on the remote box yielded this snippet:
socket(AF_UNIX, SOCK_STREAM, 0) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_UNIX, sun_path="/tmp/ssh-5uCspahMpL/agent.27042"}, 110) = 0
write(3, "\0\0\0\1", 4) = 4
write(3, "\1", 1) = 1
read(3, "\0\0\0\1", 4) = 4
read(3, "\5", 1) = 1
write(2, "error fetching identities for pr"..., 66error fetching identities for protocol 1: agent refused operation) = 66
and ssh-agent locally printed this:
debug1: new_socket: type = CONNECTION
debug3: fd 5 is O_NONBLOCK
debug1: process_message: socket 1 (fd=5) type 27
debug2: process_extension: entering
debug2: process_ext_session_bind: entering
debug1: process_ext_session_bind: recorded ED25519 SHA256:wKemf...long...VaNY (slot 0 of 16)
debug1: process_message: socket 1 (fd=5) type 1
Unknown message 1
debug1: process_message: socket 1 (fd=5) type 11
debug2: process_request_identities: entering
debug3: identity_permitted: entering: key RSA comment "path/to/private/key", 1 socket bindings, 0 constraints
debug2: process_request_identities: replying with 1 allowed of 1 available keys
I've been googling around trying to figure out what that "Unknown message 1" indicates, but not a lot of explanation out there. So something from ssh-add to ssh-agent triggers an unknown message response, which then results in the "agent refused connection".
Is this something I can fix/workaround, or is the answer really just "something silently changed between 7.4 and 8.9, and Amazon Linux 2 doesn't upgrade major packages so there will be spurious warnings and life is just shitty like that sometimes"?
