RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2127970 - Inconsistent behaviour when using -i and -J options
Summary: Inconsistent behaviour when using -i and -J options
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: openssh
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Dmitry Belyavskiy
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-19 13:48 UTC by Dr. Stephan Wonczak
Modified: 2022-11-30 11:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-30 11:22:28 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenSSH Project 3490 0 None None None 2022-10-24 13:53:22 UTC
Red Hat Issue Tracker CRYPTO-8593 0 None None None 2022-10-24 10:45:44 UTC
Red Hat Issue Tracker RHELPLAN-134326 0 None None None 2022-09-19 13:54:20 UTC

Description Dr. Stephan Wonczak 2022-09-19 13:48:20 UTC
Description of problem:
Keys explicitly provided by "-i /path/to/keyfile" is ignored when -J <jumphost> is on the command line

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

openssh-8.7p1-22.el9.x86_64

How reproducible:
always

Steps to Reproduce:
1. ssh -i /path/to/ssh-key -J user@jumphost user@targethost

Actual results:
ssk-key is ignored, login fails

Expected results:
ssh-key should be used, login succeeds

Additional info:
Detailed description and observations. 

In the process of setting up a jumphost I noticed what I would classify as a bug in ssh.

I set up a jumphost which knows userA, which then passes the connection though to userA@targethost. The jumphost does not allow password-login of userA, just key-login. A special key was generated for this connection chain, which is stored in /path/to/ssh-key. The public key was put into the authorized_keys-file of userA on both jumphost and targethost.

I can login into the jumphost by

ssh -i /path/to/ssh-key userA@jumphost

I can also directly login to the targethost:

ssh -i /path/to/ssh-key userA@jumphost

This will be disallowed later, hence the requirement for a jumphost. The jumphost will also disallow direct logins of users later; direct login is only allowed for debugging right now. Now for the weird part:

ssh -i /path/to/ssh-key -J userA@jumphost userA@targethost

fails with 

userA@jumphost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

checking with "ssh -v", the key provided by the -i option is not even read (keys replaced by #### for privacy):

(...)
debug1: Will attempt key: /home/localuser/.ssh/id_rsa RSA SHA256:####  agent
debug1: Will attempt key: user,11.11.2008,linux mgr user RSA SHA256:#### agent
debug1: Will attempt key: /home/localuser/.ssh/id_dsa 
debug1: Will attempt key: /home/localuser/.ssh/id_ecdsa 
(...)
debug1: Next authentication method: publickey
debug1: Offering public key: /home/localuser/.ssh/id_rsa RSA SHA256:#### agent
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Offering public key: user,11.11.2008,linux mgr user RSA SHA256:#### agent
d
(...)

If I place /path/to/ssh-key into the .ssh-folder of localuser, the key -is- offered automatically (no -i option this time), and login to targethost works

(...)
debug1: Will attempt key: /home/localuser/.ssh/id_rsa RSA SHA256:####  agent
debug1: Will attempt key: user ECDSA SHA256:#### agent
debug1: Will attempt key: user,11.11.2008,linux mgr user RSA SHA256:#### agent
debug1: Will attempt key: /home/localuser/.ssh/id_dsa 
debug1: Will attempt key: /home/localuser/.ssh/id_ecdsa 
(...)
debug1: Next authentication method: publickey
debug1: Offering public key: /home/localuser/.ssh/id_rsa RSA SHA256:#### agent
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Offering public key: user ECDSA SHA256:#### agent
debug1: Server accepts key: user ECDSA SHA256:#### agent
debug1: Offering public key: user,11.11.2008,linux mgr user RSA SHA256:#### agent
d
(...)

If I remove the key from localuser's .ssh-folder again, but add it to ssh-agent: (ssh-add /path/to/ssh-key), login again works (no -i option):

(...)
debug1: Will attempt key: /home/localuser/.ssh/id_rsa RSA SHA256:####  agent
debug1: Will attempt key: user ECDSA SHA256:#### agent
debug1: Will attempt key: user,11.11.2008,linux mgr user RSA SHA256:#### agent
debug1: Will attempt key: /home/localuser/.ssh/id_dsa 
debug1: Will attempt key: /home/localuser/.ssh/id_ecdsa 
(...)
debug1: Next authentication method: publickey
debug1: Offering public key: /home/localuser/.ssh/id_rsa RSA SHA256:#### agent
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Offering public key: /path/to/ssh-key ECDSA SHA256:#### agent
debug1: Server accepts key: /path/to/ssh-key ECDSA SHA256:#### agent
(...)

At one point I had forgotten to remove the -i from the command line after adding the key to ssh-agent, and the last to lines changed to:

(...)
debug1: Offering public key: /path/to/ssh-kedebug1: Offering public key: /path/to/ssh-key ECDSA SHA256:#### agent
debug1: Server accepts key: /path/to/ssh-key ECDSA SHA256:#### agent
y ECDSA SHA256:#### explicit agent
debug1: Server accepts key: /path/to/ssh-key ECDSA SHA256:#### explicit agent
(...)

So it seems that the -i option -is- evaluated, but not used in all cases. Very strange, and IMHO inconsistent behaviour indeed.

Comment 1 Dr. Stephan Wonczak 2022-10-12 13:00:13 UTC
No comments? This issue is severly hampering testing/debugging when creating a new jumphost.

Comment 2 Dmitry Belyavskiy 2022-10-12 13:19:18 UTC
Sorry for the delay. I didn't have a chance to investigate it yet :(

As I'm not aware of any difference between our code and upstream here, it's probably worth raising this issue upstream.

Comment 3 Dr. Stephan Wonczak 2022-10-18 11:14:18 UTC
I think if this is brought upstream by a RedHat-Engineer, this would probably get a bit more attention than if it came from me.
In any case the behaviour is easily reproducible, as described above.

Comment 4 Dmitry Belyavskiy 2022-10-20 14:15:31 UTC
I'm sorry but at first (and second) glance I don't see any code that could cause this behavior.
 
As the questions will be definitely raised, I strongly prefer you to report this problem because only you can answer those questions.

Comment 5 Dr. Stephan Wonczak 2022-10-24 13:49:17 UTC
OK, I followed you suggestion and reported this issue in the OpenSSH-bugtracker.
Bug-ID for reference: https://bugzilla.mindrot.org/show_bug.cgi?id=3490
If there are news I will update here, too.

Comment 6 Dmitry Belyavskiy 2022-10-24 13:53:08 UTC
Thank you very much!

Comment 7 Dmitry Belyavskiy 2022-11-30 11:22:28 UTC
Upstream considers this behavior as correct, closing.


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