transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
[Let's move this to debian-project since there is no
debian-admin-public-bikeshedding. I hope mutt doesn't eat my
Mail-Followup-To header.]
On Thu, 28 Aug 2008, Peter Palfrader wrote:
> > I generally avoid using password authentication to Debian hosts, *except* in
> > the particular case of scp'ing files from one Debian host to another because
> That being said we are evaluating means
> that will allow simple file transfers.
So, there are a few ideas floating around:
- Tell people to only load the debian.org key into an agent, and use -c
when doing that so they have to confirm each use of that key. Then
forward that agent to the debian host when they want to copy files.
pros: + works right now.
+ no problems with existing firewalls.
cons: - Sure, as if people would ever do that.
- install sendfile/saft on all machines so you can do
sendfile foo.tar.gz weasel@merkel
Unfortunately sendfile doesn't use crypto, so who knows what happens
to the stuff you send. And it's yet another network facing server - I
don't know if anybody ever did a real audit on it either. Also, I
have no idea if it's still actively maintained these days. Lack of
crypto seems to suggest that there certainly isn't any new development
going on, and hasn't in ages.
pros: + simple to use,
+ easy to implement
cons: - no confidentiality,
- no integrity checking,
- maintainence status?
- might cause problems with existing firewalls.
The crypto stuff could be alleviated by using ipsec between all our
servers. But that works even less well than you'd expect.
- use uucp.
UUCP stands for Unix to Unix Copy and was built for exactly this
purpose. It allows one to copy files to remote systems. We can make
it use ssh as a transport so its reasonably secure against non-local
adversaries. Unfortunately it stores files in the public spool on the
target host, where it can be read by any local user (maybe even copied
by remote users using uucp) and overwritten by any remote user using
uucp.
pros: + probably not hard to use,
+ not hard to implement
+ no problems with existing firewalls.
cons: - no confidentialy to local users (and local users on peers)
- files can be overwritten by other users so you can't be
sure you get the file on the target host that you wanted.
- progress of copy status is not immediately apparent
- setup afs
Using AFS would allow us to use a shared /afs/debian.org tree on all
our systems. AFS does all the magic crypto stuff so you don't have to
worry about Eve sniffing or Mallory tampering with packets.
Setting up AFS is a big chunk of work. It would require us first to
setup a kerberos realm, to integrate it into ud-ldap so that new krb
principals are created with ud-ldap users, and that ud-ldap users can
set krb passwords, which probably should be different from their ldap
password.
On the user side once logged in you'd have to get a kerberos ticket
using your krb password, then alog to get access to your
/afs/debian.org/transfer/$user or whatever.
We will not put homedirs onto AFS (that would completely torpedo the
initial goal), it would simply provide a transfer area.
pros: + AFS is cool
+ once we have a krb realm we could maybe also use it for other
stuff like all those web services that require logins. How
good is krb support in browsers these days?
cons: - integrating krb and afs into ud-ldap is a lot of work
- setting up afs will be a lot of work too
- little prior experience with afs
- AFS suffers from the not-a-filesystem syndrome: file access
control is not unix-like and will confuse users.
- might cause problems with existing firewalls.
What other options did we forget?
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/
Reply to: