Re: sftp batch transfer

[Chuck Yerkes <chuck+obsd_(_at_)_2004_(_dot_)_snew_(_dot_)_com>]

Quoting Chris Alatakis (Alatakis_(_at_)_t-online_(_dot_)_de):
> From: "Chuck Yerkes" <chuck+obsd_(_at_)_2004_(_dot_)_snew_(_dot_)_com>
> > Quoting Karl R. Balsmeier (karl_(_at_)_sfdata_(_dot_)_net):
> > > FTP is faster, but less secure.  We experience this trade-off alot when
> > > shipping machine images back & forth...
> >
> > I wonder about strong auth to get the discussion going
> > (authenticate) but the transfer in cleartext, with encrypted
> > checksums of the blocks xfered to ensure that they came over
> > accurately...
> >
> > Bad to keep the clear data off the wire, but a step up from
> > 1971's ftp and faster than scp/krsh/sftp/ssh.
> >
> > Just kinda thinking out loud...
> >
> > Holes in this?
> 
> The point is I think "the clear data off the wire".
> In a production enviroment you can keep your backing up data
> without root sensitive information but not with no users (customers)
> sensitive information as this is the case for us sometimes.
> So there is no alternative than encrypting the whole data...
> I think is very stupid to provide ssl encryption in your website
> but tranfer the whole backup unencrypted.
> In other cases could work but not for one such as this..
> Hoping that we can use encrypted transfers with the today rates of
> unectrypted ones in near future.

On the other hand, if it's done with knowledge ("CLEARGET") and my
xfer rate doubles, then I win.  And there is quite a bit of data
I can run in the clear.  My issue is strong auth.

Eh, kerberos (krlogin) can handle this I think, now that I recall it.