openssh bugs - Dec 2012 - [Bug 2054] New: Environment fails to provide cryptographic identity of remote party

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

            Bug ID: 2054
           Summary: Environment fails to provide cryptographic identity of
                    remote party
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 5.9p1
          Hardware: All
                OS: All
            Status: NEW
          Keywords: low-hanging-fruit, needs-release-note
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: walter.stanish at gmail.com

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

--- Comment #1 from walter.stanish at gmail.com ---
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).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

--- Comment #3 from walter.stanish at gmail.com ---
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 :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

--- Comment #4 from Darren Tucker <dtucker at zip.com.au> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

--- Comment #5 from walter.stanish at gmail.com ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |frbrgeorge at gmail.com

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
*** Bug 1821 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |djm at mindrot.org

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
This has been possible since the addition of the sshd_config
ExposeAuthInfo directive, added in OpenSSH 7.6

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2054

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
closing bugs resolved before openssh-8.9

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.