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:

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, 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 ([]: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 / (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"?


1 Answer 1


Try restricting to protocol 2 only. Add a Protocol stanza to your .ssh/config file (either in a host-specific host section or a Global stanza):

Host *
    Protocol 2

It appears that "protocol 1" is referring to the SSH protocol version itself.

You can go see where the messages might becoming from in the ssh-agent source - the printed line is from the local ssh-agent -l but the agent refused operation is coming from ssh_err printing the contents of packet received from the remote ssh-agent.

  • 1
    No difference, I'm afraid, using the config file both locally and on the remote system (where the ssh-add is being run). It's worth noting that on older OpenSSH versions, Protocol is documented as already defaulting to 2; on more recent versions it's not even present in the ssh_config(5) page, doesn't show up at all in -G output, and the syntax-highlighting editor flags it as a "deprecated/ignored/unsupported" keyword. It looks like it's been dropped, although I hadn't realized they'd made that change (I remember having to switch Protocol from 1 to 2 way back in the day).
    – Ti Strga
    Aug 26, 2022 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.