Hello,
One possible solution is to have an alternate home directory and
have SSH look there.. e.g look in /afs/home/$USER/.ssh first . If that
fails
then try an alternate tree /home/$USER/.ssh on local disk. It is true that
you can't distribute the keys in AFS/DFS but If you login into one box
you could probably forward keys around.
I used this method for .forward files for sendmail. Sendmail
doens't like DFS acls so I have an alternate homedir .. In sendmail it is
set with.. $u = user, $z is homedir,forgot what $w&$h was..
define(`confFORWARD_PATH',
`$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward:/home/$u/.for
ward.$w+$h:/home/$u/.forward+$h:/home/$u/.forward.$w:/home/$u/.forward')dnl
some people might consider this pretty ugly, but the workarounds people
use to get this working at equally ugly..
EdGy
Atro Tossavainen <[EMAIL PROTECTED]> on 09/07/2001 03:37:03
Please respond to [EMAIL PROTECTED]
To: Bruce Foster <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: SSH configuration with AFS
Bruce,
> Atro -- I'm thinking about SSH configuration for my DFS cell, which
> has similar issues to your AFS cell. Reading your note below, I'm a
> bit uncertain as to what you really did here, and what worked. Can
> you briefly outline (for me) your final (working) solution for
> configuring the user ssh configuration directories?
What I was saying generally was that when I create users' home
directories, I also pre-create the configuration directories for
certain programs that expect to be able to create them mode 0700.
I set $HOME permissions to user all group rl system:anyuser l, and
group none system:anyuser none for the special directories I create.
I do this because UNIX programs usually don't know how to deal with
[AD]FS permissions. When the user starts (ssh, Netscape, elm, whatever)
for the first time and the program creates its $HOME/.directory mode
0700, it will mistakenly assume files are safe in this directory even
though UNIX permissions are ignored and the real permissions in effect
would be whatever the parent directory had, which may very well not be
the [AD]FS equivalent of mode 0700.
However, the [AD]FS equivalent of mode 0700 is problematic in the SSH
case. sshd runs as root, which allows it to read the authorized_keys
file in a user's home directory prior to the user having logged in.
This is fine on local disks and NFS, but because UNIX local root users
are nobodies on [AD]FS, the authorized_keys files can't be read and
public key authentication becomes impossible.
There's several solutions that come to mind right away:
1. Make .ssh system:anyuser rl, or mode 0755 equivalent (or worse, since
it would be readable by anybody in the world, not just at your site).
You probably don't want to do this.
2. Create a special sshd [AD]FS user and always start sshd's with the
token of this special user. Give the sshd user no other permissions
but to read users' .ssh directories. Setting this up on n+1 systems
will be a lot of hassle, and if you're not the only root user on all
of the participating boxes, this is equivalent to making .ssh mode
0755, because you would need to store the password to the sshd
account in a root-readable location for the scheme to work at all.
3. Just live with the fact that public key authentication and [AD]FS
don't mix. This is probably the best idea, since allowing public key
authentication on file systems that absolutely require the existence
of a token that can be gained with the password only means that your
users will be able to log in but be unable to access their files,
which will lead to confusion and endless support calls.
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my
own.
< URL : http : / / www . iki . fi / atro . tossavainen / >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
