> This message is in MIME format
> --_=XFMail.1.3.p0.NetBSD:990117232038:498=_
> Content-Type: text/plain; charset=us-ascii
>
> On 17-Jan-99 Reagan Blundell wrote:
> >> Create a file in .ssh owned by root with owner write only. Change the
> >> owner of .ssh to root and set it owner write only. Now the user cannot
> >> delete the directory.
> >
> > They might not be able to delete it, but they can still re-name it.
>
> It seems like it would be pretty easy to change sshd to use
> /var/ssh/$user/ instead of $home/.ssh/. Make each /var/ssh/$user and
> contents owned by a non-login account (or root). You may be able to make
> them owned by a "sshadmin" group for easy maintenance, though I seem to
> recall sshd being unhappy with group-write privs on those files.
>
> This way, the users don't have write access to any part of the tree above
> their ssh directory and so cannot muck with it. The admin can set up the
> files.
>
> I haven't actually tested this, but it seems straightforward enough. I
> don't know if sshd wants write access to the ssh dir for known_hosts and
> random_seed; I think only ssh (not the daemon) cares.
Or even a modification of this: make the entries in /var/ssh/
symbolic links to the users conventional ~/.ssh directories and
modify only the ssh and sshd programs to refer via this directory
and these links, leaving ssh-keygen &c to use the conventional
path to the names.
OTOH, these schemes are all subverted by someone who compiles (or
otherwise imports) their own copy of the ssh programs...
OTOH, lets go back to the original message. It's not actually crystal
clear but reads as if he wants to restrict *incoming* ssh access
to his host. If so, then he's in luck because incoming connections
are handled by the sshd daemon which is run by the system manager.
(Unless, of course, someone nasty runs a second copy of the sshd
daemon and listens on a more specific IP address than the system one,
so he has to make sure the system one is running on a specific IP
address.) So in these cases he can use "AllowGroups" or "AllowUsers"
in the (system) configuration file for sshd.
And in this case we don't need to junp through all the hoops with
trying to stop people creating ~/.ssh directories. Just stop them
from doing anything *useful* with them!
But it's much more difficult to stop people with general shell
accounts building their own version of the ssh client programs
and using them. Non shell accounts can, of course, be prevented
from doing this.
--
David Pick