Sending Files w/o Sending Clear Passwords?

Ambush_Bug asks: "I've done some googling around, but to no avail. I'm wondering if the Slashdot knows of a remote login protocol which exists in security space somewhere between ssh & rsh/ftp/telnet. Basically, the point is that I don't care if my data are encrypted, but I'd rather not send my password around as plaintext. I'm sending extremely large astronomical images which don't compress very well (noisy backgrounds...) and sftp is just too slow, but our sysadmin isn't fond of rcp, ftp and the like. Is there something in between?"

Comments

Push 'em.

[TheSHAD0W]

Put the data up in an obscure or passworded http or ftp server directory, then log in to your remote host via ssh and grab them remotely.

SCP

[CyberVenom]

Try scp. It is included with ssh.

Re:SCP

[Anonymous Coward]

And if you're working with a win box, WinSCP3 is a pretty good app.

Re:SCP (with -c none)

[Anonymous Coward]

specifically "scp -c none", which will send the data in the clear, but still do the secure authentication (ie. no cleartext passwords)

It isn't always enabled; your admin may have to set it up. Google around for the details.

One-time passwords

[jhealy1024]

If you use one-time passwords, you can use a totally insecure connection because the password is invalid immediately after you use it. Thus, even if it gets sniffed, it doesn't give an attacker anything they can use to get into your system. Thus, the connection is totally insecure, but your password remains safe. Sounds to me like just what you would want.

Look into libpam-opie on linux or s/key on the *BSDs for more info. Some good background is available from the FreeBSD manual:

http://www.freebsd.org/doc/en_US.ISO8859-1/books /h andbook/skey.html

It integrates well with most of the "basic" services on those OSes, so you shouldn't have much trouble getting it off the ground.

The one pain is that you have to look up a new password off of a card or piece of paper every time you log in. Alternately, some programs allow you to compute the OTP challenge/response on the fly (you could even write a script to help you out if you do this often enough).

Definitely worth a look...

Re:SCP (with -c none)

[CyberVenom]

Here's a link to the manpage. http://www.die.net/doc/linux/man/man1/scp.1.html

very simple - tunnel ftp over SSH

[stonebeat.org]

FTP uses 2 ports: port 21 for control connection(passwd/authentication) and port 20 for data transfer.
You just need to tunnel 21 through SSH, and leave 20 unecrypted.
Very simple technique, but very powerful. I use SSH tunneling everyday.
openssh supports tunneling and the windows downloadable form http://www.ssh.com also supports it. takes 3 mins to setup the tunnel.

Try a faster cipher

[semanticgap]

Sftp uses ssh as the transport. Chances are your ssh configuration defaults to 3des which is painfully slow, you might do better by specifying blowfish as your cipher, or if you are really lucky, your sysadmin has compiled ssh with "none" cipher enabled (but my guess is you are not so lucky, even though ssh with none as cipher addresses your problem precisely - passwords are encrypted, and the rest isn't).

To tell sftp to tell ssh to use blowfish I believe you need "sftp -oCipher=blowfish"

Re:Try a faster cipher

[kwerle]

This is exactly the right kind of thing to do.

I use scp, and so the command I issue is

scp -c blowfish SomeFile me@TargetHost:/somepath

On my 11Mb/s 802.11 network I am capped by bandwidth, not by CPU.

SFTP slowness

[lpontiac]

The reason yer SFTP is slow is because yer internet connection is throttled for non HTTP packets. This is common in large networks and schools.

There are a couple of other things that can slow SFTP and SCP down:

• You're encrypting. Not a problem on a fast machine with a slow link, but on a slow machine with a fast link, it's noticable. Another poster has already pointed out you can configure ssh to not compress.
• The SSH2 protocol implements its own flow control, over and above what TCP is already doing. A really simple implementation of the protocol that won't allow multiple packets to go out without (yet) being acknowledged will slow down heaps - when PuTTY improved it's packet handling I saw scp over 802.11 go from 20KiB/s to 450KiB/s.
  
  Apparantly, when using OpenSSH, you'll want to use the -B option to bump up the internal buffer size way beyond the 32768 byte default.

How about kerberos?

[DeathBunny]

Sounds like a good application for Kerberos. From the RedHat Kerberos docs:

"Kerberos is a network authentication protocol created by MIT which uses symmetric key cryptography to authenticate users to network services -- eliminating the need to send passwords over the network. When users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted."

Just find yourself an FTP client and server that both support Kerberos. Here's a few links to get you started:

Kerberos section of the RedHat 9 manual:
http://www.redhat.com/docs/manuals/linux/ RHL-9-Man ual/ref-guide/ch-kerberos.html

Kerberos FAQ:
http://www.cmf.nrl.navy.mil/CCS/people/kenh/ kerber os-faq.html

MIT Kerberos page:
http://web.mit.edu/kerberos/www/

Use rsync direct over tcp

[DDumitru]

Most *nix distributions have a copy of rsync loaded.

In this case you are using rsync directly over tcp/ip connections, sometimes called "daemon mode".

This mode features:

o high-strenght crytpo on passwords, but no encryption of data.
o passwords that are 100% independent of the system passwords.
o 100% streaming, even with large numbers of small files.
o restart of failed transfers where they left off.
o delta transfers for files where only parts change.
o optional gzip style compression.
o plus a lot more neat stuff.

Info on rsync is at:

http://rsync.samba.org

If you have a Linux system with xinetd or equivilent, there is a good change that you already have an /etc/xinetd.d/rsync control record for the daemon. You then need an /etc/rsyncd.conf file plus a "secrets" file to hold the passwords.

rsync directly on top of tcp/ip is how most "mirror sites" sync to their masters. It is about the only "practical" way to send gigabytes over the internet.

A couple of caveats. If stuff is twitchy, try to use the latest version of rsync (2.5.6) on both ends. Also, if you use the --compress option with already compressed (or encrypted data), there is a gziplib boundary bug. There are patches for this, but if you are sending uncompressable data, just leave off the --compress option.

correcting mis-information, and a solution

[menscher]

First off, do NOT follow the advice of all the idiots saying to use scp -c none. That will not encrypt your password, despite all the uninformed claims to the contrary. The encryption type is determined during the initiation of the connection. The password is simply part of the data, sent later. (If anyone chooses to dispute this, please provide evidence to back up your claims.)

Second, if you can afford some slowdown, use -c blowfish. The default is usually 3DES, which is incredibly slow. Blowfish is 11 times faster.

Finally, if you have some control over what applications are installed at each end, look into SafeTP. It encrypts the password, but not the data. Exactly what you asked for.

Re:correcting mis-information, and a solution

[Above]

I believe the poster is correct, -c none will pass passwords in the clear. You can get around this by using RSA authentication, which is public key based, and thus doesn't need to be encrypted.

So, -c none only with RSA authentication, please.

Re:OTP Calculators

[Anonymous Coward]

STRIP will store your passwords and calculate OTPs too.