I would like to use gssapi authentication in rsync. GSSAPI is the standard way to use kerberos. My idea is not too have a full pam implementation, juste a different way to authenticate users than the secret file and md4 challenge. I made a little experiment and it worked well. What I've done is changing the challenge command. Instead of sending @RSYNCD: AUTHREQD <challenge>, it just send "@RSYNCD: GSSAPI. Then gssapi bytes are exchanged and the user principal is returned instead of the rsync login. So the changes are small. Before submiting a full patch, I seek advice, do you think it's a good way to do that ? Some configuration files needes to be changed, the protocol must be changed, is there some best practice about that ? Any help and advice is welcome.
Le 22 ao?t 08 ? 19:24, Simo Sorce a ?crit :> > If you can use ssh then use ssh+GSSAPI auth and you will have to > change > nothing.I'm already using that solution. But the cost in performance is very high, more than just the CPU needed to encrypt and decrypt.
On Fri, 2008-08-22 at 17:57 +0200, Bacchella Fabrice wrote:> I would like to use gssapi authentication in rsync. GSSAPI is the > standard way to use kerberos. > > My idea is not too have a full pam implementation, juste a different > way to authenticate users than the secret file and md4 challenge. > > I made a little experiment and it worked well. > > What I've done is changing the challenge command. Instead of sending > @RSYNCD: AUTHREQD <challenge>, it just send "@RSYNCD: GSSAPI. Then > gssapi bytes are exchanged and the user principal is returned instead > of the rsync login. So the changes are small. > > Before submiting a full patch, I seek advice, do you think it's a good > way to do that ? Some configuration files needes to be changed, the > protocol must be changed, is there some best practice about that ? > > Any help and advice is welcome.If you can use ssh then use ssh+GSSAPI auth and you will have to change nothing. But kerberizing the protocol itself is a *very* good idea, especially if you use also use singing and sealing using GSSAPI. I very much look forward any patch in this area, and I hope other rsync developers can help you to chape them down so that they can rapidly be accepted upstream. I'd be happy also to test patches when they are ready if you post them somewhere. Simo. -- Simo Sorce * Red Hat, Inc * New York
On Fri, 2008-08-29 at 18:50 +0200, Bacchella Fabrice wrote:> Still working on my gss patch.Please remember to attach the updated patch! To generate a single diff, you can "git add" the files you added/changed and then run "git diff HEAD". You could also look into maintaining a git repository containing your change on the Web. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/rsync/attachments/20080829/188fd863/attachment.bin
Indeed. Thanks for the type about git. The diffs against 3.0.3 & git : -------------- next part -------------- A non-text attachment was scrubbed... Name: rsync-3.0.3.diff.bz2 Type: application/bzip2 Size: 11310 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20080830/05955909/rsync-3.0.3.diff.bin -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: rsync-git.diff.bz2 Type: application/bzip2 Size: 5456 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20080830/05955909/rsync-git.diff.bin -------------- next part -------------- Le 30 ao?t 08 ? 01:02, Matt McCutchen a ?crit :> On Fri, 2008-08-29 at 18:50 +0200, Bacchella Fabrice wrote: >> Still working on my gss patch. > > Please remember to attach the updated patch! > > To generate a single diff, you can "git add" the files you added/ > changed > and then run "git diff HEAD". You could also look into maintaining a > git repository containing your change on the Web. > > Matt