[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sftp batch transfer
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: sftp batch transfer
- From: Chuck Yerkes <chuck+obsd_(_at_)_2004_(_dot_)_snew_(_dot_)_com>
- Date: Sat, 24 Apr 2004 01:58:57 -0400
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.
Visit your host, monkey.org