> On 26 Jul 2015, at 7:41 pm, Vadim Zhukov <persg...@gmail.com> wrote: > > 2015-07-26 12:19 GMT+03:00 David Gwynne <da...@gwynne.id.au>: >> >>> On 26 Jul 2015, at 7:07 pm, Nicholas Marriott <nicholas.marri...@gmail.com> >>> 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. dlg > > -- > WBR, > Vadim Zhukov
