[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 [EMAIL PROTECTED] 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]