--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

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

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

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

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

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

-----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

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

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

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

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

> 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

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