On Mon, Jan 25, 2016 at 12:28:20PM +0100, Jan Bramkamp wrote: > > > On 24/01/16 15:50, Dag-Erling Smørgrav wrote: > > Slawa Olhovchenkov <slw_at_zxy.spb.ru> writes: > >> Can you do some small discurs about ssh+kerberos? > >> I am try to use FreeBSD with $HOME over kerberoized NFS. > >> For kerberoized NFS gssd need to find cache file "called > >> /tmp/krb5cc_<uid>, where <uid> is the effective uid for the RPC > >> caller" (from `man gssd`). > >> > >> sshd contrary create cache file for received ticket called > >> /tmp/krb5cc_XXXXXXX (random string, created by krb5_cc_new_unique). Is > >> this strong security requirement or [FreeBSD/upstream] can be patched > >> (or introduce option) to use /tmp/krb5cc_<uid> as cache file for > >> received ticket? > > > > I wasn't aware of that. It should be easy to patch, but in the > > meantime, you can try something like this in .bashrc or whatever: > > > > krb5cc_uid="/tmp/krb5cc_$(id -u)" > > if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then > > if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then > > export KRB5CCNAME="${krb5ccuid}" > > else > > echo "Unable to rename krb5 credential cache" >&2 > > fi > > fi > > unset krb5ccuid > > If $KRB5CCNAME is set during PAM session setup than the pam_exec module > might allow a reliable implementation along those lines: > > - Stop if $KRBCCNAME is invalid (klist -t) > - Stop if /tmp/krb5cc_$UID is already valid and has enough time left > - Copy the ticket to /tmp and rename it to /tmp/krb5cc_$UID. > > Keep in mind that this approach leaves valid tickets in /tmp after the > SSH session ends while OpenSSH normally does its best to tie forwarded > tickets to a SSH session. Please check me: you propose to add to /etc/pam.d/sshd string like session required pam_exec.so /patch/to/some/scripts and do above checks in this scripts? 'session' executed after 'account' phase, on 'account' phase NFS must be already accessed (for checks presents some files in $HOME and importing/executing/interpretating, like .login_conf, .k5login and etc).Received on Mon Jan 25 2016 - 16:08:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC