Slashdot Mirror
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?"
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.
Snail mail doesn't require a password.
Try scp. It is included with ssh.
What about running an IM client and using its file transfer feature? Most IM clients offer plaintext file transfers, and most have secure authentication processes (e.g., MSN Messenger uses an MD5 challenge-response system).
You can probably use something like Jabber.
CDRW+UPS.
Innovative protocol that requires a stack of blank CDs and a business account with UPS (unless you want to drive to a drop-off).
CDRW+Fedex is a similar fork of this protocol.
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.
Basically if you are sending something... no matter what, it is broken down into packets and sent. Your computer does not care what it is, just where it is going. It is the job of the receiver to understand it. 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.
What I would do is burn it onto a CD and snail mail it to the person. If the file is to large to put onto one cd, then probabally it is too large to send in one sitting.
If all your traffic is local though, like still on the same LAN or WAN, or (taking a large leap) Metropolitan Area Network, the transfer rates should be no problem.
One other thing. If your institution is using extremley large images or files, generally your sys admins are nice enough to allow you to tansfer them at generally astronomical speeds. If yours are being little trolls holing their bandwidth and crushing the boned of all who cross their path is seek of the precious BW, might i suggest a Knight in Shining Armor, or their boss.
while(1) { fork(); };
it seems that one time passwords could help you out here.
It doesn't encrypt passwords for cleartext protocols but if the password is used only once it's not a great risk.
I used it on OpenBSD (ftp server) and it worked great.
OpenBSD S/Key FAQ section
I always thought sftp was secure and allowed file transfer.
Not sure exactly how you would set it up, but PPP supports unencrypted data streams with hashed passwords when using authentication like CHAP. or... Maybe you could write a Perl (or Python, or shell) script that issies a challenge and spits out whatever files you want if the challenge succeeds. Hell, maybe I'll write one right now - here I go! (check this thread in a few minutes to see the finished product...)
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.
s /h andbook/skey.html
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/book
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...
Here's a link to the manpage. http://www.die.net/doc/linux/man/man1/scp.1.html
If you're on an internal network, setup an anonymous FTP server...
I've seen setups where anyone can upload a file to a certain directory, then some script routine runs every so often and moves the file to the actual place where you want the file to go.
Conformity is the jailer of freedom and enemy of growth. -JFK
I've never tried this, but I once heard that it's possible to create an SSH tunnel for port 21, FTP's control port. The data is actually transmitted in the clear over other ports, but the protocol-related transmissions take place over the encrypted port. I'm not sure how this would work; since the tunneling would mask the client's orgin to the server, I would expect problems negotiating the data ports.
I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. BB
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.
Consensus is good, but informed dictatorship is better
I don't see that you have much advantage from using a secured ftp in this case- 99.999% of the time you won't get hacked or anything and in this case the data you are hauling isn't sensitive anyway. Just don't use the anonymous ftp account for anything that needs the security.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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"
grisha.org
You could use WebDAV (works on IIS and Apache) or, as a slightly more tricky alternative, plain HTTP uploads (you'd need an upload handling script).
As long as you enable authentication, and make sure it's not basic authentication (use digest authentication, or if it's a windows box, NTLM), you're set - your password is encrypted, but your data isn't.
Similarly, you could use either WebDAV or HTTP uploads over an HTTPS connection WITH basic authentication, which gives you overall encryption on the lot, but that's not really what you were after...
oh btw if you dont want to setup tunneling manually, you can also purchase appgate's mindterm, which a a webbased tunneling java program, that is very easy to setup.
Consensus is good, but informed dictatorship is better
It was mentioned above but not modded up, use scp with -c none.
That should use scp with no cipher. You can, however, still use a key pair for authetication. Thus, auth is secure, transmission is plain.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
There are a couple of other things that can slow SFTP and SCP down:
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.
Sounds like a good application for Kerberos. From the RedHat Kerberos docs:
/ RHL-9-Man ual/ref-guide/ch-kerberos.html
/ kerber os-faq.html
"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
Kerberos FAQ:
http://www.cmf.nrl.navy.mil/CCS/people/kenh
MIT Kerberos page:
http://web.mit.edu/kerberos/www/
OK, the question I would have is, exactly WHY is sftp too slow?
The raw throughput of sftp isn't much less than ftp, given that you have enough CPU on both ends of the link for the encryption/decryption.
You speak as though the slowdown of sftp is very large compared to ftp - not the few percent the protocol itself would add. This would lead me to beleive that you are running slow due to the encryption itself.
So, first of all I would check the CPUs of the machines involved - unless you are running an old junque P75 you should not have a big problem filling most pipes.
Secondly, check what encryption algorithm you are using for the link once it is up. Some of the algorithms require less CPU than others.
It really sounds like SSH/SFTP would be the solution you want, but you just need to to a bit of tuning.
www.eFax.com are spammers
Occasionally I want to make a disk-image to a remote machine (typically sending 6 gig). I use netcat to just send the bits as fast as possible.
Machine a:
# nc -l -p 1234 > file
Machine b (via ssh session):
# nc machinea 1234 file_to_send
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Or just use scp, which is easier still.
Advice: on VPS providers
in bashrc (or whateverrc):
alias fastscp="scp -prC -c blowfish"
the -C (compression) won't do much for your images, but is great for most content - think inline zlib compression. blowfish is a reasonably fast cipher as well.
also, if you're hell-bent on not sending encrypted data, you could set up ssh to not use encryption (type "none"), then use a non-password authentication method - either hostbased or publickey.
note, though, that the default for scp/ssh is to NOT use compression. why the insistence on not being a little more secure? in my experience, the encryption overhead is not too big a burden on file transfer over a 100Mbps network. Anything less than that and the bandwidth is the bottleneck, not the cpus on either end.
you may also be able to use an ssl-enabled web page to authenticate, then POST the files over a non-ssl connection... not sure if that's do-able, though.
Actually, scp will work fine, just use 'none' as the cipher.
You can even automate things using public key authentication so there aren't passwords.
a simplified recipe for setting up public key authentication is:
ssh-keygen -t rsa
it will ask for a file name, and then generate two files: file and file.pub
copy file.pub to user@remote in $HOME/.ssh/authorized_keys
(If the file already exists, append the contents of the file to the end)
copy file to your local machine's $HOME/.ssh/identity
If everything is set up ok, you should be able to do:
ssh user@remote
and you should be logged in without a password.
Then try:
scp -c none localfile user@machine:remotefile
no passwords, secure login, fast transfers.
You need to compile openssh with 'none' cypher. This is not copiled by default.
The 'none' block cypher will transfer you data in the clear. This gives a near-ftp speed transfer of your data. However, the good thing is that you get the full SSH authentication with passwords encrypted.
If you can't convince your Sysadmin to compile and install a SSH with 'none' cypher. The next best thing is to use the 'blowfish' cypher. It impacts cpu usage and transfer speed less than any either cypher I have tested.
BTW, the usage is as follows:
scp -c none file remote.ip:/dest/
or
scp -c blowfish file remote.ip:/dest/
Good luck.
-- I am not a fanatic, I am a true believer.
I've never used it, or even looked at it, but perhaps something like a Kerberized FTP. You may want to try different encryption protocols for scp/ssh. SSH defaults to using IDEA for encryption, which is 64% of non-encryption speed. You can switch to Blowfish, which runs at 88% non-encryption speed. Just use the -c option with ssh/scp. And finally you can look at an unsecured file transfer, such as stock FTP, over IPSec. Check out FreeS/WAN if you are using Linux.
(a) Use kerberized FTP. Kerberos is a bitch to set up, but if your sysadmin is paranoid about security, he should be using it. Kerberos just deals with authentication, so it's possible to use non-encrypted systems that still use Kerberos authentication.
(b) Why is it "too slow"? A modern system running AES can saturate a 100Mbits/sec network.
May we never see th
For those on the go an OTP calculator for the Palm OS: http://palmkey.sourceforge.net/.
All editorial writers ever do is come down from the hill after the battle is over and shoot the wounded.
You can use ftps (ftp with ssl). It does encrypted authentication, and encrypted data transfer is optional. However, few ftp servers and clients support it, as there's really no good reason to use it when you've got ssh.
Another option would be to chose a faster encryption algorithm for ssh than the default. In particular, I've seen the arcfour cipher recommended for speed (although I've not used it.) Check out the man page. Older versions of ssh - which you could presumably still find somewhere - support "none" as an encryption option. Using this, you could setup an RSA key and avoid entering a password altogether. One of these options would be easier than setting up kerberos, but not nearly as cool or useful otherwise.
Finally, you could setup an anonymous ftp server, accessible only from your remote IP address with a world writable "drop box" in it (which would be, however, readable only by you.) This might be the easiest thus far, but I misdoubt that your sysadmin will care for it if he's security paranoid. It is, however, very secure since it is only vulnerable to a Denial of Service attack which could be avoided using a quota, and even without the quota vulnerable only from you IP address. You could do something similar with an http form and/or a webdav server.
Or, instead of uploading the files, could you download them? That is, could you put up a webserver on the box where the files are captured, then use wget or something to pull them down without a password at all? That might be the easiest of all.
And, lest we forget, where there's a perl, there's a way. :) You could hack something up using XML::RPC or something in about ten minutes, no doubt. Authenticate by transmitting crypted passwords or something.
Hope this helps.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
Most likely culprit is the general protocol overhead of SSH, even when compression and strong encryption are both disabled.
For example, across a 100Mbps switch between two machines, transferring large (700MB ISO images) files with FTP or even NFS gives an average throughput of 70Mbps, while using 'scp' (blowfish, no compression) tops out at 10Mbps for the exact same file.
Oddly, even using 'scp' on loopback on a 1.4Ghz FreeBSD machine hits the same hard limit of ten megabits?
I do not deploy Linux. Ever.
Here You go! /. doesn't seem to like code. Well here's a link to the code then!)
:)
(Darn,
server.pl
client.pl
Let me know what you guys think!
This code should provide all of the mentioned features: an MD5-based challenge authentication, and unencrypted transfer of files.
I use rsync over ssh to make up for many of scp/sftp weaknesses. eg:
/local/file user@host:/remote/file
rsync -e ssh
(you should read the rsync man page as that is over simplified, I tend to use a more complex command line that meet my needs.)
By using ssh2 keys and the ssh-agent I don't get prompted for passwords and I get the benefit of rsync's ability to do partial transfers and other cleverness. It rocks.
Most *nix distributions have a copy of rsync loaded.
/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.
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
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.
This method can also be used as a push or pull.
/localpath remote.site:/remotepath
rsync -azve 'ssh'
to do a push (reverse the order of the last 2 options for a pull).
rsync should be faster than any other protocol (lower overhead), the -z option will compress data, and you can always set up an authorized key via ssh on the remote system to allow for password-less access...
How about using scp with the blowfish cipher?
...
scp -c blowfish
It has very low overhead, so shouldn't be too much slower than using ftp...
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.
There's a reason scp/sftp encrypt everything: sniffing passwords is the simplest and most obvious attack against ftp but it's not the only one.
.ssh/authorized_keys with something different and then have shell access.
There are numerous other attacks. And they only require control of a machine on the same lan as the server or client.
You don't care if an attacker sees your data fine.
Do you care if they corrupt the in transit? (FTP has no way to authenticate the data.)
More seriously, someone could also hijack your FTP session. There are even script kiddie tools to do this. Once someone has taken over your FTP session they can control you account. For example, they replace
Don't care about what happens on that machine, well once someone controls your account they can probably get your password. Just stick a few trojans in your path. You'd never notice and they'd get your password and happily break into your other accounts.
kerberos might be a bit admin-intensive(and you mentioned you were trying to convince your admin), therefore I recommend you look at http://srp.stanford.edu/ which might do what you require It even has windows-based binary client versions of ftp for those that require them.
you could just wget the files from the far
end, if you enabled digest auth on your httpd.
alternatively, there is s/key auth for ftp.
-I like my women like I like my tea: green-
All of this is true, but it's far beyond the
pale of the threat model that the original
question implies.
It's ALWAYS possible to describe an attack
on the security of ANY system. No news there.
-I like my women like I like my tea: green-
Go into you SSH options, pick a nice MACing algo and then just put none for data encryption. In the key-exchange you get to pick your functions, or none if need be.
QED.
Either that or dummy accounts/throw away passwords.
Considering you're going to be doing this more than once you might as well have your own ftpd set to only accept connections from your IP using anonymous login.
I seem to remember that (very) old ssh versions actually had this feature, but best I can tell, it's gone in newer (e.g. openssh) versions. Anyone have a clue why this is?
If memory serves me right, you can use an FTP-server with TLS support. It encrypts the control-connection and leaves the data-connection unencrypted.
I think this feature is supported by ProFTPD.
- Baffle
ssh sucks for bulk data transfer. it is *not at all optimized* for such a use. its intended primarily for interactive traffic or low bandwidth (read: internet connection speed) traffic.
for bulk data transfer over high speed networks it blows chunks not only due to the crypto speed but also due to data buffering issues, loads upon loads of data copies (scp and sftp send all data through at least one local pipe with tiny buffers if not more), etc. the crypto dominates, but even with "-c none" its efficiency blows chunks.
and don't advocate tunneling over ssh as a solution either. TCP over TCP is a bad idea.
and if the target is a supercomputer or data center machine it probably -does not- have the CPU cycles to deal with the encryption overhead of such a large data transfers...
In this ftps protocol, control connection where the password is transmitted is encrypted, and the data connection is encrypted optionally.
lftp supports AUTH TLS and turns on this secure extension by default if it is supported by server. In Red Hat 8 this extension is supported by default in wu-ftpd.Unfortunately, in Red Hat 9 it is not supported, since wu-ftpd was replaced with vsftpd.
check out pure-ftpd, it can encrypt ftp control channel, you can find a list of compatible clients inside the archive
Use samba with the "encrypt passwords" option.
use connection with netpipes.
.
Like this:
server$ faucet 3000 -out tar cf -
client$ hose server 3000 -in tar xvf -
You can secure the connection with iptables
\m/
The solutions are:
Use HTTP and wget from the other machine. Since you don't care about your data being intercepted, you might as well be up front about it!
Use scp with a faster cipher, like "none". But unless you're on a slow machine and a fairly fast network, I'd be surprised if the encryption is really the bottleneck. Have you looked at 'top'?
Probably only an option with dedicated lines, though. I don't think they bothered with authentication. But the transfer rates are nice.
"Provided by the management for your protection."
above
mail server admins LOVE it when you send several hundred megabyte email attachments!
It is easier to build strong children than to repair broken men. -Frederick Douglass
SRP provides strong authentication capabilities. Here are the client programs that implement it.
http://srp.stanford.edu/
note that you still have the option of encrypting the data stream if you wish by specifying -x to either telnet or rcp. So next time someone tells you telnet, rcp are insecure you can tell them they are wrong!
Note there are is also a kerberos version of FTP server/client available.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
you can move to K5
What does Scoop have to do with anything?
I hadn't previously seen "K5" referring to Kerberos 5.
Pick up a copy of stunnel for both machines, set up an ssl tunnel for the control port (21), and let the data channel be unencrypted. Then you don't have to worry about entering a password twice (SSH tunnels require once for ssh and once for ftp).
I think it just works (in a similar fashion to the way ssh tunnels for ftp just work). But as I've not tried it, I don't know for certain.
Send some random data to the client. The client SHA-1's that and the password, and sends it back. The server checks it against a locally-calculated value. Simple. Using full ssh with no compression would probably be better, though.
I'm amazed no-one else has said this.
Rsync over SSH is amazingly efficient, even with one time copies, I've moved files in the multi gigabyte range with this, and it absolutely flies.
-- You ain't seen me, right?
Call the dude up, start spouting a string of characters.
ssh remotebox "dd if=/dev/hda" > remotebox-hda.dd
Nice, because you don't have to log into a machine in a seperate step to start the server process.
-- I speak only for myself.