Why can I access my server when I have: Warning: Identity file .ssh/key-file not accessible

Yosko asked:

Why can I still connect to my server when the keys I am using are clearly not accessible?

From my PC, to connect to the server:

ssh -l myLogin -i .ssh/key-file <SERVER_IP>

I have tried this in these 2 configurations :

  • key-file doesn’t exists on my PC, and key-file.pub doesn’t exist on the server
  • key-file doesn’t exists on my PC, but key-file.pub content is in the .ssh/authorized_keys on the server

Both times, I get the following message, but I am still connected to the server:

Warning: Identity file .ssh/key-file not accessible: No such file or directory.

Note: I have already properly used this same PC to connect to the same server, using another proper key that I deleted locally

Is there a bad configuration on my server that allows connections without proper authentication? Or might there be any sort of cache on my PC that remembers how to access the server?

SSH in verbose

When adding -v to the SSH commands, I get the following output:

Warning: Identity file .ssh/key-file not accessible: No such file or directory.
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to <SERVER_IP> [<SERVER_IP>] port 22.
debug1: Connection established.
debug1: identity file /home/localLogin/.ssh/id_rsa type -1
debug1: identity file /home/localLogin/.ssh/id_rsa-cert type -1
debug1: identity file /home/localLogin/.ssh/id_dsa type -1
debug1: identity file /home/localLogin/.ssh/id_dsa-cert type -1
debug1: identity file /home/localLogin/.ssh/id_ecdsa type -1
debug1: identity file /home/localLogin/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/localLogin/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/localLogin/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/localLogin/.ssh/id_ed25519 type -1
debug1: identity file /home/localLogin/.ssh/id_ed25519-cert type -1
debug1: identity file /home/localLogin/.ssh/id_ed25519_sk type -1
debug1: identity file /home/localLogin/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/localLogin/.ssh/id_xmss type -1
debug1: identity file /home/localLogin/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to <SERVER_IP>:22 as 'login'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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:tgcwk2j/SwDF2TGpteN5ITcT7o4JJGCAyJ9ygkXCQAU
debug1: Host '<SERVER_IP>' is known and matches the ECDSA host key.
debug1: Found key in /home/localLogin/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: [email protected] RSA SHA256:0DH/97OKekTIjdeuc2jO2Ixig9VVTpB7morVj2/GVJw agent
debug1: Will attempt key: [email protected] RSA SHA256:6l0joGtcoJv2yvia82zAtXK8PqBLQkesOOwDaCutc20 agent
debug1: Will attempt key: /home/localLogin/.ssh/id_rsa 
debug1: Will attempt key: /home/localLogin/.ssh/id_dsa 
debug1: Will attempt key: /home/localLogin/.ssh/id_ecdsa 
debug1: Will attempt key: /home/localLogin/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/localLogin/.ssh/id_ed25519 
debug1: Will attempt key: /home/localLogin/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/localLogin/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: [email protected] RSA SHA256:0DH/97OKekTIjdeuc2jO2Ixig9VVTpB7morVj2/GVJw agent
debug1: Server accepts key: [email protected] RSA SHA256:0DH/97OKekTIjdeuc2jO2Ixig9VVTpB7morVj2/GVJw agent
debug1: Authentication succeeded (publickey).
Authenticated to <SERVER_IP> ([<SERVER_IP>]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: /home/login/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/login/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-28-generic x86_64)

My answer:


The ssh key you say you removed from your local filesystem is still being used because your ssh agent has cached it and is providing it when you try to log in to the remote host.

You can just log out of your local system and log back in, and the ssh agent will also restart and forget your old key.


View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.