Openssh + AFS - openssh

This is a discussion on Openssh + AFS - openssh ; The native authentication methods of openssh are (not counting insecure RhostsRSAAuthentication) 1) public key 2) password For users with home dirs in AFS space, method 1) does not work. Except with (non foolproof) fiddling on the access controls within the ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Openssh + AFS

  1. Openssh + AFS

    The native authentication methods of openssh are
    (not counting insecure RhostsRSAAuthentication)
    1) public key
    2) password
    For users with home dirs in AFS space, method 1) does not work.
    Except with (non foolproof) fiddling on the access controls within
    the home directory. This might lead to security issues when done
    by inexperienced users.

    Without some work, only 2) remains. Being forced to send the most
    intimate credential instead of an ssh-key is not that nice.

    The use of Krb5 ticket passing with GSS-API is thought to be useful.
    But the authentication is done 'under the hood'; the administrator
    has no chance to issue finer controls regarding then ticket contents.
    When the ticket is accepted but not sufficient to open up the home dir,
    the user must be forced out in the behind.

    I would like to propose an initial credential exchange phase. The client
    might send ticket, x509-creds, afs-tokens or whatever. This should not
    authenticate the user, but help in authentcation with other methods.
    If activation of these credentials allows access to the AFS home dir,
    standard ssh-key authentication can be done. So a double
    authentication is enforced: the credentials must be sufficient for AFS
    and an ssh-key (from within protected AFS space) authentication has to be
    successful.

    Patches for a working example can be found in
    /afs/rrz.uni-koeln.de/admin/public/openssh-5.0p1-PatchDir/
    It implements AFS-Token-passing and Krb5-ticket-passing for protocol-2
    (adding X509-cred-passing should be easy).
    A flag 'AllowCredPassing' in the ssh config files might increase the
    acceptability for that.

    Best regards,
    Rainer Laatsch

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: Openssh + AFS



    --On May 27, 2008 7:34:42 PM +0200 Rainer Laatsch
    wrote:

    > The native authentication methods of openssh are
    > (not counting insecure RhostsRSAAuthentication)
    > 1) public key
    > 2) password
    > For users with home dirs in AFS space, method 1) does not work.
    > Except with (non foolproof) fiddling on the access controls within
    > the home directory. This might lead to security issues when done
    > by inexperienced users.
    >
    > Without some work, only 2) remains. Being forced to send the most
    > intimate credential instead of an ssh-key is not that nice.
    >
    > The use of Krb5 ticket passing with GSS-API is thought to be useful.
    > But the authentication is done 'under the hood'; the administrator
    > has no chance to issue finer controls regarding then ticket contents.
    > When the ticket is accepted but not sufficient to open up the home dir,
    > the user must be forced out in the behind.
    >
    > I would like to propose an initial credential exchange phase. The client
    > might send ticket, x509-creds, afs-tokens or whatever. This should not
    > authenticate the user, but help in authentcation with other methods.
    > If activation of these credentials allows access to the AFS home dir,
    > standard ssh-key authentication can be done. So a double
    > authentication is enforced: the credentials must be sufficient for AFS
    > and an ssh-key (from within protected AFS space) authentication has to be
    > successful.


    I run sshd under k5start so it can obtain tokens to read public-key files
    from users. The ACLs are set by default to allow the daemon RO access.
    Users still need to use GSS-API though or they get 'forced out in the
    behind' as you call it when they can't access their homedir.

    >
    > Patches for a working example can be found in
    > /afs/rrz.uni-koeln.de/admin/public/openssh-5.0p1-PatchDir/
    > It implements AFS-Token-passing and Krb5-ticket-passing for protocol-2
    > (adding X509-cred-passing should be easy).
    > A flag 'AllowCredPassing' in the ssh config files might increase the
    > acceptability for that.
    >
    > Best regards,
    > Rainer Laatsch
    >
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev




    --
    "Genius might be described as a supreme capacity for getting its possessors
    into trouble of all kinds."
    -- Samuel Butler
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: Openssh + AFS

    On 2008-05-27 17:34, Rainer Laatsch wrote:
    > The native authentication methods of openssh are
    > (not counting insecure RhostsRSAAuthentication)
    > 1) public key
    > 2) password
    > For users with home dirs in AFS space, method 1) does not work.
    > Except with (non foolproof) fiddling on the access controls within
    > the home directory. This might lead to security issues when done
    > by inexperienced users.


    The authorized_keys file doesn't have to reside in the user's home
    directory. In many cases it is preferable if it is not. See the
    AuthorizedKeysFile directive. I often use something like:

    AuthorizedKeysFile /etc/ssh/keys/%u

    --
    Jefferson Ogata
    NOAA Computer Incident Response Team (N-CIRT)
    "Never try to retrieve anything from a bear."--National Park Service
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: Openssh + AFS

    The user cannot create that by himself. Should the admin manually fulfill
    requests if there are > 50000 users? (Current count: 50090)

    Best regards
    Rainer Laatsch


    On Tue, 27 May 2008, Jefferson Ogata wrote:
    > The authorized_keys file doesn't have to reside in the user's home
    > directory. In many cases it is preferable if it is not. See the
    > AuthorizedKeysFile directive. I often use something like:
    >
    > AuthorizedKeysFile /etc/ssh/keys/%u
    >
    >


    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  5. Re: Openssh + AFS



    Rainer Laatsch wrote:
    > The native authentication methods of openssh are
    > (not counting insecure RhostsRSAAuthentication)
    > 1) public key
    > 2) password
    > For users with home dirs in AFS space, method 1) does not work.
    > Except with (non foolproof) fiddling on the access controls within
    > the home directory. This might lead to security issues when done
    > by inexperienced users.
    >
    > Without some work, only 2) remains. Being forced to send the most
    > intimate credential instead of an ssh-key is not that nice.
    >
    > The use of Krb5 ticket passing with GSS-API is thought to be useful.


    Yes it is useful. When used with something like pam_afs_session,
    it can get a AFS token.

    > But the authentication is done 'under the hood'; the administrator
    > has no chance to issue finer controls regarding then ticket contents.


    That is a GSSAPI restriction. Delegation is a single flag. The Kerberos
    protocol allows for multiple tickets to be delegated, but with GSS
    currently a full ticket granting ticket is sent. You might want to
    bring up the issue with the IETF Kitten (GSSAPI) working group.
    There is also the Kerberos OK_TO_DELEGATE flag as an advisory to the
    client. But this too is not fine grained.


    > When the ticket is accepted but not sufficient to open up the home dir,
    > the user must be forced out in the behind.


    The k5start method as suggested by mloftis@wgops.com sounds interesting,
    as the user then sets the AFS ACLs to let selected hosts read access
    to the ~/.ssh directory...

    Or if the user sets up ACLs for the home directory, ~/.ssh directory
    and adds symlinks in the ~/.ssh directory for files that must be
    readable only by the user to some ~/.private directory the the sshd
    can read some data without a AFS token. until and AFS token is
    obtained after the authentication by pam_afs_session.

    >
    > I would like to propose an initial credential exchange phase. The client
    > might send ticket, x509-creds, afs-tokens or whatever. This should not
    > authenticate the user, but help in authentcation with other methods.
    > If activation of these credentials allows access to the AFS home dir,
    > standard ssh-key authentication can be done.


    Not clear if there is a risk here. Any delegated tickets are encrypted
    in a key contained in the the Kerberos service ticket. So in effect you have
    authenticated with Kerberos but you still want to authenticate with the
    SSH keys. If this SSH key authentication fails, you have given away the
    delegated tickets.

    > So a double
    > authentication is enforced: the credentials must be sufficient for AFS
    > and an ssh-key (from within protected AFS space) authentication has to be
    > successful.
    >
    > Patches for a working example can be found in
    > /afs/rrz.uni-koeln.de/admin/public/openssh-5.0p1-PatchDir/
    > It implements AFS-Token-passing and Krb5-ticket-passing for protocol-2
    > (adding X509-cred-passing should be easy).
    > A flag 'AllowCredPassing' in the ssh config files might increase the
    > acceptability for that.
    >
    > Best regards,
    > Rainer Laatsch
    >
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  6. Re: Openssh + AFS

    The real problem is, you need a prior authentication (e.g. ssh-key) before
    the ssh delivers needed creds (gssapi). The k5start concept brought me to
    this solution:
    I have a valid ticket in $HOME/.ssh/krb5cc.$user (protected in AFS).
    Now ssh $Buser@host
    there being put under pam;
    /etc/pam.d/sshd starts with:
    auth sufficient pam_runexec.so debug ignore_root \
    program=/afs/zaik/public/AuthScript progparams=$USER

    The AuthScript contains:
    #!/bin/ksh
    # called from PAM auth sshd
    user=$1
    KRB5CCFILE=`echo $KRB5CCNAME | sed -e 's/FILE://'`
    [ "$user" == "" ] && exit 101
    echo "$KRB5CCFILE" | grep ^/tmp/ >/dev/null || exit 102
    umask 0177
    PubKey=/afs/zaik/public/servicekey
    /usr/bin/ssh -i $PubKey root@hal.rrz.uni-koeln.de $user $KRB5CCNAME
    >$KRB5CCFILE

    rc=$?
    exit $rc

    The PubKey has a forced command:
    command="/root/noaccess/GrantKrbTkt" ......

    that contains:
    #!/bin/ksh
    [ "$1" != "UNDERPAG" ] && exec /usr/afsws/bin/pagsh -c "exec $0 UNDERPAG
    $*"
    shift
    ## hidden method to get admin token here ###
    user=`echo $SSH_ORIGINAL_COMMAND | awk '{print $1}'`
    KRB5CCNAME=`echo $SSH_ORIGINAL_COMMAND | awk '{print $2}'`
    [ "$user" == "" ] && exit 13
    rc=99
    TkFile=`getent passwd $user | cut -d: -f6`/.ssh/krb5cc.$user
    if [ -s $TkFile ] ; then
    export KRB5CCNAME=FILE:$TkFile
    /opt/krb5/bin/kinit -R ; rc=$?
    chown $user $TkFile
    [ "$rc" -eq 0 ] && cat $TkFile
    else
    echo " NO file $TkFile" >&2
    fi
    exit $rc

    Voila; admin got me a credential. Doing ssh under Pam decouples
    the admin token from the user.


    Best regards,
    Rainer Laatsch



    On Tue, 27 May 2008, Michael Loftis wrote:

    > I run sshd under k5start so it can obtain tokens to read public-key files
    > from users. The ACLs are set by default to allow the daemon RO access.
    > Users still need to use GSS-API though or they get 'forced out in the
    > behind' as you call it when they can't access their homedir.


    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  7. Re: Openssh + AFS

    On 2008-05-28 08:51, Rainer Laatsch wrote:
    > The user cannot create that by himself.


    That's one of the benefits.

    > Should the admin manually fulfill
    > requests if there are > 50000 users? (Current count: 50090)


    If the admin trusts the users to manage their own authenticators, he can
    pre-create the authorized keys file for each user. Just touch an empty
    file and chown it to the user; keep the directory 755.

    Top posting is a sign of fuzzy thinking.

    > On Tue, 27 May 2008, Jefferson Ogata wrote:
    >> The authorized_keys file doesn't have to reside in the user's home
    >> directory. In many cases it is preferable if it is not. See the
    >> AuthorizedKeysFile directive. I often use something like:
    >>
    >> AuthorizedKeysFile /etc/ssh/keys/%u


    --
    Jefferson Ogata
    NOAA Computer Incident Response Team (N-CIRT)
    "Never try to retrieve anything from a bear."--National Park Service
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  8. Re: Openssh + AFS

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    On 28 May 2008, at 17:19, Douglas E. Engert wrote:
    >>
    >> I would like to propose an initial credential exchange phase. The
    >> client
    >> might send ticket, x509-creds, afs-tokens or whatever. This should
    >> not
    >> authenticate the user, but help in authentcation with other methods.
    >> If activation of these credentials allows access to the AFS home dir,
    >> standard ssh-key authentication can be done.

    >
    > Not clear if there is a risk here. Any delegated tickets are encrypted
    > in a key contained in the the Kerberos service ticket. So in effect
    > you have
    > authenticated with Kerberos but you still want to authenticate with
    > the
    > SSH keys. If this SSH key authentication fails, you have given away
    > the
    > delegated tickets.


    OpenSSH had (almost) this behaviour, which was considered a security
    flaw, and removed. The problem is that a user can inadvertently give
    away their credentials, by allowing another user to use ssh from
    their console. For example, say that Alice allows Bob to use her
    machine to connect to a server. Bob enters his username and password,
    but ends up with Alice's credentials on the server.

    In most Kerberised envrionments, ssh public key is pretty much
    useless, as without Kerberos credentials you can't do anything at all
    - - I'm not sure what the benefit to adding significant additional
    complexity to the protocol to allow their use in these environments is.

    S.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)

    iD8DBQFIPZn+qWndc26pXmcRAnE9AJsFPp4JEdUvOx/MaEirqHBeDmjqEQCgpE3b
    //bIOF19kBcl9AwAp5xc0ps=
    =V8c6
    -----END PGP SIGNATURE-----
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  9. Re: Openssh + AFS

    Hello Mr. Engert,
    I am very glad to hear from you. I learned a lot inspectng the code of
    yourn'gssklog*' (and also 'GetToken/SetToken' of Mr. Toebbicke @ CERN).
    Though we have not switched (yet) to final usage of krb5, our testbed uses
    your 'gssklog*' effectivly.

    My latest message shows how to get credentials. It is easy to get an
    AFS token at once (instead of getting an Krb5 ticket and then struggling
    to get the AFS token).

    If the tickets reside solely in AFS space, that's good. The standard
    krb5 setup leaves ticket files (effectively equivalent to the password)
    on every server. This concept might have been enforced by
    NationakSecurityAgencies
    which I dont want to assist; except under official legal issues.

    I will contribute a PAM nodule (soon); all the base works can be found
    already in
    /afs/rrz.uni-koeln.de/admin/public/openssh-4.7p1-PatchDir/


    Best regards,
    Rainer Laatsch

    On Wed, 28 May 2008, Douglas E. Engert wrote:
    > > The use of Krb5 ticket passing with GSS-API is thought to be useful.

    >
    > Yes it is useful. When used with something like pam_afs_session,
    > it can get a AFS token.
    >
    > > But the authentication is done 'under the hood'; the administrator
    > > has no chance to issue finer controls regarding the ticket contents.

    >
    > The k5start method as suggested by mloftis@wgops.com sounds interesting,
    > as the user then sets the AFS ACLs to let selected hosts read access
    > to the ~/.ssh directory...
    >
    > Not clear if there is a risk here. Any delegated tickets are encrypted
    > in a key contained in the the Kerberos service ticket. So in effect you have
    > authenticated with Kerberos but you still want to authenticate with the
    > SSH keys. If this SSH key authentication fails, you have given away the
    > delegated tickets.


    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  10. Re: Openssh + AFS



    Rainer Laatsch wrote:
    > Hello Mr. Engert,
    > I am very glad to hear from you. I learned a lot inspectng the code of
    > yourn'gssklog*' (and also 'GetToken/SetToken' of Mr. Toebbicke @ CERN).
    > Though we have not switched (yet) to final usage of krb5, our testbed uses
    > your 'gssklog*' effectivly.
    >


    Nice to hear. We have converted all newer systems to using the OpenAFS
    aklog, but still have a few doing gssklog.

    > My latest message shows how to get credentials. It is easy to get an
    > AFS token at once (instead of getting an Krb5 ticket and then struggling
    > to get the AFS token).
    >
    > If the tickets reside solely in AFS space, that's good. The standard
    > krb5 setup leaves ticket files (effectively equivalent to the password)
    > on every server. This concept might have been enforced by
    > NationakSecurityAgencies
    > which I dont want to assist; except under official legal issues.


    You are addressing a real concern that the delegated credential by GSS
    is a full TGT. In may situations, delegating just an AFS ticket
    would be less risky. But it soulds like you are adderssing this by
    doing the delegation at the SSH level. Have you looked at
    what it would take to do this within GSS? Kerberos can forward more
    then one ticket, but no one I know of has taken advantage of this.

    >
    > I will contribute a PAM nodule (soon); all the base works can be found
    > already in
    > /afs/rrz.uni-koeln.de/admin/public/openssh-4.7p1-PatchDir/
    >
    >
    > Best regards,
    > Rainer Laatsch
    >
    > On Wed, 28 May 2008, Douglas E. Engert wrote:
    >>> The use of Krb5 ticket passing with GSS-API is thought to be useful.

    >> Yes it is useful. When used with something like pam_afs_session,
    >> it can get a AFS token.
    >>
    >>> But the authentication is done 'under the hood'; the administrator
    >>> has no chance to issue finer controls regarding the ticket contents.

    >> The k5start method as suggested by mloftis@wgops.com sounds interesting,
    >> as the user then sets the AFS ACLs to let selected hosts read access
    >> to the ~/.ssh directory...
    >>
    >> Not clear if there is a risk here. Any delegated tickets are encrypted
    >> in a key contained in the the Kerberos service ticket. So in effect you have
    >> authenticated with Kerberos but you still want to authenticate with the
    >> SSH keys. If this SSH key authentication fails, you have given away the
    >> delegated tickets.

    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  11. Re: Openssh + AFS, easy solution

    Checking out key-login further lead me to this solution.

    - Put the authorized_keys to $HOME/public/authorized_keys (read access for
    anybody)

    - Added to sshd_config:
    AuthorizedKeysFile %h/public/authorized_keys
    AuthorizedKeysfile2 %h/.ssh/authorized_keys

    - Have an id_rsa.pub line enabled in authorized_keys

    Now i could login with ssh-key. But the homedir in afs would be
    inaccessible.

    The remedy can be done in a two step approach:

    - Send my ticket by ssh/scp and key to the host's /tmp/
    - login per ssh and key:

    'pam_auth' was skipped by sshd

    'pam_account sufficient' checks my ticket by refreshing (kinit -R)
    'pam_account required' else does exec 'kinit -r 1day' to get a
    refreshable ticket

    'pam_session sufficient' now gets me a token (gssklog)

    My Pam-Module always sets a PAG for non-root accounts and throws the
    ticket away as soon as possible (just use it to get a token).

    This could also be extended to allow tickets from another realm
    without cross realm/cell setup. Pam just gets user@realm from the ticket;
    if that realm is allowed, it requests a refresh from that realms kdc.

    Best regards,
    Rainer Laatsch

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  12. Re: Openssh + AFS, ssh-key login working

    SSH key login and finally getting an AFS token can be made working like
    this. It uses the feature of the shell to include a .bashrc or .kshrc
    upon every reexec of the shell.

    - move all .profiles to a public subdir ( $HOME/public ) ;
    AFS acl's "system:anyuser rl"
    - make links from $HOME/ to these -> $HOME/public/
    - move authorized_keys from .ssh/ to $HOME/public/authorized_keys
    - make link .ssh/authorized_keys to $HOME/public/authorized_keys
    - for $HOME and $HOME/.ssh, the acl's "§LOGNAME all system:anyuser none"
    may be left like that (no change whatever).
    Thats all for the setup.

    Have a key made:
    - ssh-keygen -N '' ... (say into .ssh/id_rsa)
    - cat .ssh/id_rsa.pub >> $HOME/public/authorized_keys

    This is the point: Add in front of your .bashrc / .kshrc
    # ---
    [ "$PAGSHDONE" ==""] &&
    export PAGSHDONE=true &&
    exec /usr/afsws/bin/pagsh -c "exec $SHELL"
    [ "$TOKENDONE" == "" ] &&
    export TOKENDONE=true &&
    /opt/krb5/bin/gssklog # or aklog, whatever

    Now always ssh to $host in 2 steps:

    scp /tmp/krb5cc_$uid $host &&
    ssh $host

    To remedy the case of leftover tickets, the end of your .bashrc / .kshrc
    may read
    # ---
    tty -s || kdestroy #throw away when interactive; does not influence scp


    Best regards,
    Rainer Laatsch
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  13. [Correction] Openssh + AFS, ssh-key login working


    > Now always ssh to $host in 2 steps:
    > scp /tmp/krb5cc_$uid $host &&
    > ssh $host

    Should be:
    scp -p /tmp/krb5cc_$uid $host:/tmp/krb5cc_$uid &&
    ssh $host

    > To remedy the case of leftover tickets, the end of your .bashrc / .kshrc
    > may read
    > # ---
    > tty -s || kdestroy #throw away when interactive; does not influence scp

    Should be:
    tty -s && kdestroy #throw away when interactive; does not influence scp

    Best regards,
    Rainer Laatsch

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  14. Re+: Openssh + AFS, Script for key login without passwords

    Find it here:
    /afs/rrz.uni-koeln.de/admin/public/.bashrc
    Laatsch@uni-koeln.de
    Using it as your .bashrc or .kshrc on the target host allows you to
    - forward credentials (tickets) to /tmp/
    - logging in with ssh, these are used to get a token (under a PAG)
    if the home dir is in AFS
    - the creds are moved to $HOME/private
    - on non-private hosts, an exit trap handler is in place to (k)destroy
    the credentials.

    I would like to give this as a contribution to the SSH community.

    Best regards
    Rainer Laatsch

    On Sun, 8 Jun 2008, Rainer Laatsch wrote:
    > SSH key login and finally getting an AFS token can be made working like
    > this. It uses the feature of the shell to include a .bashrc or .kshrc
    > upon every reexec of the shell.
    >
    > - move all .profiles to a public subdir ( $HOME/public ) ;
    > AFS acl's "system:anyuser rl"
    > - make links from $HOME/ to these -> $HOME/public/
    > - move authorized_keys from .ssh/ to $HOME/public/authorized_keys
    > - make link .ssh/authorized_keys to $HOME/public/authorized_keys
    > - for $HOME and $HOME/.ssh, the acl's "§LOGNAME all system:anyuser none"
    > may be left like that (no change whatever).
    > Thats all for the setup.
    >
    > Have a key made:
    > - ssh-keygen -N '' ... (say into .ssh/id_rsa)
    > - cat .ssh/id_rsa.pub >> $HOME/public/authorized_keys
    >
    > This is the point: Add in front of your .bashrc / .kshrc
    > # ---
    > [ "$PAGSHDONE" ==""] &&
    > export PAGSHDONE=true &&
    > exec /usr/afsws/bin/pagsh -c "exec $SHELL"
    > [ "$TOKENDONE" == "" ] &&
    > export TOKENDONE=true &&
    > /opt/krb5/bin/gssklog # or aklog, whatever
    >
    > Now always ssh to $host in 2 steps:
    >
    > scp /tmp/krb5cc_$uid $host &&
    > ssh $host
    >
    > To remedy the case of leftover tickets, the end of your .bashrc / .kshrc
    > may read
    > # ---
    > tty -s || kdestroy #throw away when interactive; does not influence scp
    >
    >
    > Best regards,
    > Rainer Laatsch


    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread