2015-07-26 13:06 GMT+03:00 David Gwynne <[email protected]>:
>
>> On 26 Jul 2015, at 7:41 pm, Vadim Zhukov <[email protected]> wrote:
>>
>> 2015-07-26 12:19 GMT+03:00 David Gwynne <[email protected]>:
>>>
>>>> On 26 Jul 2015, at 7:07 pm, Nicholas Marriott 
>>>> <[email protected]> wrote:
>>>>
>>>> Hi
>>>>
>>>> I can't say I know a lot about bsdauth so maybe this is a stupid
>>>> question, but could this work as a login_* authentication method instead
>>>> of doas doing it?
>>>
>>> i had a look at that.
>>>
>>> the biggest technical problem is that the bsd_auth framework filters all 
>>> environment variables from the caller before calling the actual auth 
>>> handler. if i wrote a login_sshagent thing for bsdauth, i cant get at the 
>>> SSH_AUTH_SOCK env var to be able to talk to the agent. doas (and other 
>>> programs) would have to be modified to explicitly pass the sockets location 
>>> as an argument somehow. threading that needle doesnt look like much fun.
>>>
>>> it was pointed out to me that this isnt that useful anywhere except for 
>>> doas and sudo, so generalising it has limited benefit. most bsd_auth uses 
>>> are to authenticate remote users, you dont have a local agent socket to 
>>> connect to in that situation.
>>
>> Probably a stupid question, but I see the auth_setoption() function
>> that allows to pass parameters to the login script. Can't it be used?
>
> yes, that's what i alluded to above.
>
> doas would have to be modified to manage the bsd auth session itself rather 
> than simply calling auth_userokay. it would have to check or specify the auth 
> style and provide the extra information as you suggested.
>
> getting the list of authorized_keys would have to be rethought too.
>
> im still not sure what the general benefit is though. what else could sanely 
> make use of an sshagent bsdauth backend apart from doas? the only thing i can 
> think of is sudo, and it would need to be modified like i described above for 
> doas too. without modification and code specific for this backend, bsd_auth 
> users can't take advantage of it.

Now I got it, thank you for explanation. I try to find a reliable and
non-intrusive solution but can't, too. :(

--
  WBR,
  Vadim Zhukov

Reply via email to