Bug 2054 - Environment fails to provide cryptographic identity of remote party
Summary: Environment fails to provide cryptographic identity of remote party
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 5.9p1
Hardware: All All
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords: low-hanging-fruit, needs-release-note
: 1821 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-24 01:50 AEDT by walter.stanish
Modified: 2022-02-25 13:59 AEDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description walter.stanish 2012-12-24 01:50:09 AEDT
I am implementing a system that has a number of near-identical cloud nodes connect back to a single system.  Each node has the central system's host key pre-loaded, and the central system likewise has the remote host keys pre-loaded.  This basic key distribution and network connectivity all works fine, and as expected.

The problem is that the 'shell' program that executes when the cloud nodes connect needs to reliably determine the identity of the remote party, and the obvious place to do this is from sshd-initialized environment variables.  Unfortunately, it seems that there is no way to determine the remote party's cryptographic identity using environment variables at present. This causes issues in my application, which needs to relay the identity information to the application but does not wish to either (1) create separate unix-level users for each remote host, or (2) trust the remote host's application-level claims to a given identity.

I am therefore requesting that the OpenSSH development team consider adding a new environment variable, eg. SSH_REMOTE_KEY, that corresponds to some kind of public key identifier for the remote party.
Comment 1 walter.stanish 2012-12-24 01:59:11 AEDT
Further note: the classic SSH_CONNECTION environment variable is not useful in our deployment as the cloud nodes will move about frequently (thus IP and port combination are too temporary to be meaningful).
Comment 2 Darren Tucker 2012-12-24 10:45:37 AEDT
Assuming you're using public-key authentication (it's not clear if you're that or hostbased) you can use the "environment=" key directive in authorized_keys to implement something like this already, eg:

environment="SSH_KEY=key1" AAAA[...]1
environment="SSH_KEY=key2" AAAA[...]2

see the section on "AUTHORIZED_KEYS FILE FORMAT" in sshd(8).  Note that you'll need to enable PermitUserEnvironment in sshd_config for this to work.
Comment 3 walter.stanish 2012-12-24 11:27:19 AEDT
Thanks, that method worked.

Given the implicit overhead of maintaining a modified authorized keys file, perhaps some kind of public key identifier environment variable might still be a useful (if optional) feature.

Happy holidays :)
Comment 4 Darren Tucker 2012-12-24 12:01:46 AEDT
actually I'd like to see something a bit more general: now that we have AuthenticationMethods, expose which ones were actually used as a comma-separated list with some optional identifying information, something like:

SSH_AUTH_METHODS=password
SSH_AUTH_METHODS=publickey(RSA;md5;11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee)
SSH_AUTH_METHODS=keyboard-interactive,publickey(RSA;md5;11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee)

not sure how much work this would be, though.
Comment 5 walter.stanish 2012-12-24 12:07:11 AEDT
How about a single environment variable that represents the most unique identifier available for the remote party, as viewed in terms of the authentication subsystem?

This could be a hash like:
 <local_sshd_keyid_as_salt>:<scheme>:<scheme-specific data>

Or perhaps simply:
 <scheme>:<scheme-specific data>

In addition, detailed data such as that you suggest could be made available in separate, authentication-scheme-linked variables.
Comment 6 Damien Miller 2013-10-10 12:10:26 AEDT
*** Bug 1821 has been marked as a duplicate of this bug. ***
Comment 7 Damien Miller 2022-01-14 15:39:38 AEDT
This has been possible since the addition of the sshd_config ExposeAuthInfo directive, added in OpenSSH 7.6
Comment 8 Damien Miller 2022-02-25 13:59:39 AEDT
closing bugs resolved before openssh-8.9