Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, 30 Aug 2008, Steve Langasek wrote:
> Well, the underlying premise here is, of course, that certain routinely
> useful capabilities need to be taken out of the hands of the users because
> they won't use them responsibly[1].
> But we're already talking
> about hard policy changes to stop users from doing things they shouldn't do
> in the first place (== using passwords when logging in to Debian servers
> from their systems), so I don't think you should underestimate the capacity
> of developers to be cleverly stupid when security is concerned.
I don't think that using the password per se on debian hosts is an evil
thing to do. I have to do it dozens of time almost every day for sudo.
And I don't think nopasswd entries in the sudoers file would be all that
much better. Or we could start shipping a pam pwdfile table for use
with sudo. Maybe we should do that anyway, regardless of what comes
from this discussion.
Also I agree, if somebody willfully compromises security there's nothing
we, or anyone, can do.
> Having your inter-host file transfers sandboxed, such that you have to log
> in to the host on each end in order to get the files copied to the place you
> want them, would be a serious nuisance, and in particular, it would not
> allow for good use of rsync as a time- and bandwidth- saving technique.
> Having to start a separate ssh agent for Debian systems would also not be
> user-friendly.
How often do you do that, seriously? I can't think off-hand of the last
time I had to rsync large amounts of data as weasel between debian
hosts. I don't rule out that it happens, I would just like to know if
it's a daily routine.
> Kerberized ssh with ticket forwarding is one of the better ones in this
> regard, because it doesn't require typing a password across the wire and the
> delegated credentials have a limited lifetime.
I fail to see how this is better than ssh agent forwarding. This might
be because I never really did much with ticket forwarding but I always
thougt the idea was to forward a TGT, so it again would give you access
to all hosts, for much longer than you are logged in probably.
> RSA auth forwarding is also good by this standard, because the credentials
> are only available while the user's initial connection is active and there
> are methods for requiring user confirmation for each instance of
> authentication forwarding.
Agree on the available only temporary. I don't think many people use
the confirmation of each instance of agent use (not forwarded use, I
don't think that's possible, is it?). I did that a while ago but it got
so annoying since I ssh to hosts hundreds of times a day.
> Anything that involves sending your password across the wire, or storing RSA
> keys on the Debian host, is pretty obviously not good.
Anything that involves sending a password over the wire that can be
used to access shells on other machines should be avoided, agreed.
> But if you don't find these arguments persuasive, then of the options
> proposed, I think AFS is the best. (Or you could use Samba with Kerberos
> sign+seal... :)
The nice property of AFS is that it allows for a more decentralized
setup, if I understand things correctly. I.e. you would not rely on a
single server in a single location.
> > 1. And more likely the user will fetch a full TGT on the source host
> > when they want to copy stuff to another host since the default mode of
> > login will probably stay ssh keys.
>
> Well, a way around that is to not give users kinit on the Debian hosts,
> and/or implement ACLs on the KDC that prohibit issuing TGTs to Debian hosts.
Not sure how feasable that would be, and what it would help if you can
just forward a TGT to a debian host.
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/
Reply to: