openssh unix dev - Apr 2005 - Feature Suggestion - scp don't decrypt file at destination unecrypt on copy back switch

Hi all,

Please pardon me if this has been discussed already on this list.
I searched on "destination" and did not find a hit.

The problem I am trying solve is having backups on a remote server
that even root cannot not read. I have seen lot's of specialized file
systems and volume drivers for various operating systems. But being
that all files are already scp'd to the destination(s) I am thinking 
that the
most efficient way to do this on a user by user basis may be a switch in
the scp command. This solutions would be highly portable and easily
automated.

The idea is this: when this switch is present, the file is encrypted on the
fly just as always.  However when the file reaches the destination, it
is emitted onto the disk in the transported encrypted state.  The decryption
stage is by-passed.  The file name is then  marked with a unique file
extension to indicate that it is encrypted.

When scp is called from the source machine to copy the file back, the
file remote agent recognizes the extension and does not re-encrypt the file
but sends the encrypted file. The file receiving agent then decrypts the 
file
and the copy is restored.

Alternatives may be to allow scp to take a source file from stdin, but then
encryption would be happening twice.

Of course there is always the script that encrypts files, scp's them and
it's scp'ing, decrypting partner, but this is what I am trying to avoid.

Any comments?

Gerard J. Cerchio
gjpc at circlesoft.com
www.circlesoft.com

> Of course there is always the script that encrypts files, scp's them
and
> it's scp'ing, decrypting partner, but this is what I am trying to
avoid.
> 
> Any comments?
aren't the encryption keys different for every invokation of scp?  or can
one
tell scp they keys to use and have the keys be the same for each session? 
otherwise you have a key per file and that would present something of a key 
storage problem wouldn't it?

rick jones

On Wed, Apr 06, 2005 at 12:40:37PM -0700, Gerard J. Cerchio
wrote:
> Any comments?
There are several reasons why this is a bad idea, some political,
some security-related.

scp has a single purpose in OpenSSH; a drop-in replacement for rcp.

All new file-transfer development should go into sftp instead.

The encryption "environment" in which scp and sftp runs (provided by
ssh) works well as designed but is probably not the best choice for
encrypted disk storage.

You are of course welcome to create a custom subsystem for
maintaining and accessing encrypted storage volumes, but I doubt it
will ever be part of OpenSSH. (Like any other custom subsystem not in
the SSH specification I guess.)


//Peter

Gerard J. Cerchio wrote:
> The idea is this: when this switch is present, the file is encrypted on the
> fly just as always.  However when the file reaches the destination, it
> is emitted onto the disk in the transported encrypted state.  The 
> decryption
> stage is by-passed.  The file name is then  marked with a unique file
> extension to indicate that it is encrypted.
This won't work without drastic changes to scp and ssh. scp doesn't know
that session keys that ssh uses (and shouldn't) - it just treats ssh as
a secure transport.

If you want encryption for backups, this is a good recipe:

tar zcf - /path/to/whatever | gpg --encrypt -r publickey at domain.com | \
     ssh user at backuphost "dd of=backup.tar.gz.pgp"

-d

Damien wrote:

 > tar zcf - /path/to/whatever | gpg --encrypt -r publickey at 
domain.com <http://www.mindrot.org/mailman/listinfo/openssh-unix-dev> | \
 >  ssh user at backuphost 
<http://www.mindrot.org/mailman/listinfo/openssh-unix-dev> "dd 
of=backup.tar.gz.pgp"

Thanks Damien, but this solution leads to single file recovery problems, 
especially given that most users can't tell a tar from a feather. ;)

It will also bulk up the data transfer making the data less compressible 
and larger due to entropy added during encryption.

Gerard

Peter wrote:

 > On the other hand, OpenSSH isn't really a backup software.

Maintaining the design concept of small "filter" programs performing 
tasks that are linked together to perform ever more complex tasks is the 
design goal of UNIX, circa 1974, Murray Labs.