Bug 2054

Summary:	Environment fails to provide cryptographic identity of remote party
Product:	Portable OpenSSH	Reporter:	walter.stanish
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED FIXED
Severity:	enhancement	CC:	djm, dtucker, frbrgeorge
Priority:	P5	Keywords:	low-hanging-fruit, needs-release-note
Version:	5.9p1
Hardware:	All
OS:	All

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