Bug 1574188 - The ssh client ignores identity file set on command-line or in config, walks all keys in agent first
Summary: The ssh client ignores identity file set on command-line or in config, walks ...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 28
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-02 18:36 UTC by Mark R.
Modified: 2018-05-02 18:39 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-02 18:39:49 UTC
Type: Bug


Attachments (Terms of Use)

Description Mark R. 2018-05-02 18:36:22 UTC
Description of problem:

If you have multiple keys loaded into your ssh-agent, and connect to a host where you specify a key to use via '-i' or IdentityFile in your config, the ssh client will walk all of the keys found in your agent first before trying your explicity set key.  On hosts with a lowered MaxAuthTries or in cases where a user has numerous keys, this can lead to the connection being rejected altogether.

Version-Release number of selected component (if applicable):

"OpenSSH_7.7p1, OpenSSL 1.1.0h-fips  27 Mar 2018", default in Fedora 28

How reproducible:

Create several keys, load them into ssh-agent, then make a connection where you specify it should use a key that comes later in lexicographical search order. You'll see the client try to walk through all keys from your agent before it tries your manually specified key.



Steps to Reproduce:

# Created four temp keys, loaded them into ssh-agent
$ ssh-add -l
2048 SHA256:g3BZ2UTCNR+zCqLt4JMAAYIa5KhMmVLZY/tORRWR1Wc k1 (RSA)
2048 SHA256:0GGpBzlNgJ4w49d9LFoVqG1vkrcpkaRuiPn0oqSFsz4 k2 (RSA)
2048 SHA256:MPC3YJYq54W6oKdCHXqqyb6rvTkOeBlNzMEiAyDGp/s k3 (RSA)
2048 SHA256:TdlvzFJZeToIQ+8GHXMu4PCANn+hZ+EwyrTrXO0JF6Q k4 (RSA)

# Attempt a connection, specifying that ssh should use k4 and not the others
ssh -vvv -i ~/.ssh/k4 guest@a.host.here

# Output shows that ssh walks all the keys in the agent
# instead of using only the one specified with '-i'
...
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:TdlvzFJZeToIQ+8GHXMu4PCANn+hZ+EwyrTrXO0JF6Q /home/guest/.ssh/k4
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:g3BZ2UTCNR+zCqLt4JMAAYIa5KhMmVLZY/tORRWR1Wc k1
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:0GGpBzlNgJ4w49d9LFoVqG1vkrcpkaRuiPn0oqSFsz4 k2
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:MPC3YJYq54W6oKdCHXqqyb6rvTkOeBlNzMEiAyDGp/s k3
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
...


Actual results:

Unable to login if you hit MaxAuthRetries before your key is reached (if loaded in the agent) or tried after agent keys exhausted.

Expected results:

SSH client signs in using only the specified key.

Additional info:

Comment 1 Mark R. 2018-05-02 18:39:49 UTC
Argh, close this my test case is bogus... I need to go back to the client where I had the issue and replicate there.


Note You need to log in before you can comment on or make changes to this bug.