openssh unix dev - Mar 2018 - [PATCH] Set KRB5PRINCIPAL in user environment

On Fri, 2018-03-16 at 19:07 +1030, David Newall wrote:
> > There is no reply about this demand since the firt proposition
> > has  if nobody in dev team cares about it :(
> 
> I'm curious about the first section of the diff, which exports 
> SSH_GSSAPI_DISPLAYNAME to PAM.  Is that useful?  Am I right that the
> PAM 
> environment forms no part of the client session?  Does PAM not work
> for GSS?
Yes, the PAM environment is separate from the environment, where the
new user session is created.

PAM works fine with GSS, but you might have PAM modules, that might use
this variable to do some further decisions while setting user session,
but I do not see if this is used in practice anywhere at this moment.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.

Jakub,

There are two things that you've said which strike a chord with me.

First is the patch which exports SSH_GSSAPI_DISPLAYNAME.? The reason why 
this strikes a chord with me is that I've had a similar need, but 
exporting the client's public key.? I developed a small patch and have 
been patching servers on the machines on which I have that need.? It 
never occurred to me that it might be something that I should seek to 
share with the wider community. Should I?? The patch is attached (unless 
this is a "strip all mime" list.)? It could be neater, for example by 
removing the debug statements.? Note that it exports the client's public 
key regardless of whether the session was authenticated using the 
corresponding private key.? (I'm happy to discuss why that was useful to 
me, but it's not really germane at this juncture.)

The second important thing that you said is that this is something: a) 
useful; b) for which a patch has been developed; c) years ago; and d) 
has been ignored.? Does OpenSSH need more people with write access to 
the source?

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-pubkey-env.patch
Type: text/x-patch
Size: 4227 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180317/c6647276/attachment.bin>

On Sat, 2018-03-17 at 00:52 +1030, David Newall wrote:
> Jakub,
> 
> There are two things that you've said which strike a chord with me.
> 
> First is the patch which exports SSH_GSSAPI_DISPLAYNAME.  The reason
> why 
> this strikes a chord with me is that I've had a similar need, but 
> exporting the client's public key.  I developed a small patch and
> have 
> been patching servers on the machines on which I have that need.  It 
> never occurred to me that it might be something that I should seek
> to 
> share with the wider community. Should I?  The patch is attached
> (unless 
> this is a "strip all mime" list.)  It could be neater, for
example
> by 
> removing the debug statements.  Note that it exports the client's
> public 
> key regardless of whether the session was authenticated using the 
> corresponding private key.  (I'm happy to discuss why that was useful
> to 
> me, but it's not really germane at this juncture.)
That is how opensource should work -- when something is useful for you,
it will most probably be useful for others and if you provide it back
to the community, also more people might find it useful and start using
it, improve it and build other awesome things on top of that.

Specially for this case, I believe something more generic was recently
implemented in current OpenSSH 7.6 based on the bug #2408 [1], which
exports to PAM and session what ALL authentication methods were
successful. There is a good news for you, you might no longer need to
patch your machines and use what works out of the box (it is not
exporting the whole public keys, but just the fingerprints, but you
should be able to adjust your environment).
> The second important thing that you said is that this is something:
> a) 
> useful; b) for which a patch has been developed; c) years ago; and
> d) 
> has been ignored.  Does OpenSSH need more people with write access
> to 
> the source?
Well ... that would be a question for others than myself. I am in the
same situation as you -- I have things that match similar criteria
(mostly in openssh bugzilla) and frequently see the similar results. I
can only assume that OpenBSD team has different priorities than we have
at this moment, for better or worse.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2408

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.