Sending Files w/o Sending Clear Passwords? 151
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?"
Push 'em. (Score:3, Informative)
Re:Push 'em. (Score:1)
(1) mkdir --mode=og+x-r ~/public_html/private/
Apache can't read this directory but can access specific files in it.
(2) mkdir ~/public_html/private/xyzzy/
where xyzzy is any random password. Put the files you want to transfer in that directory and retrieve them with wget.
Re:Push 'em. (Score:2)
Re:Push 'em. (Score:2)
Re:Push 'em. (Score:2)
Re:Push 'em. (Score:2)
I had to Google for "HTTP Authentication" to come up with this: Apache reference [apache.org] page. It DOES use MD5, but I don't really know how popular this digest authentication is... I know my web host supports it, but I don't remember how I ended up figuring that out.
Re:Push 'em. (Score:2)
Re:Push 'em. (Score:2)
Of course, I'm no security expert, so this may be horribly insecure. It just occurred to me that by setting the salt to include the current time of day, you should be able to thwart replay attacks that occur more than a given epsilon after the login, which is kinda neat.
Re:Push 'em. (Score:2)
Man in the middle intercepts your authentication message. Stores it in memory then runs the same salt on a dictionary. No problem.
Re:Push 'em. (Score:2)
Auth(enteredpw) = Enc(enteredpw, RandomSalt+time+enteredpw)
Verify(auth) = let salt,time,enteredpw = Dec(knownpw,auth)
check: enteredpw == knownpw && (timenow - time < replaywindow)
Is that what you understood me to say above? Ifso, could you explain how the dictionary attack comes in?
There is a window during which the entered password can be replayed; this can be countered by either having the server store the salt and allow a given salt to be use
Re:Push 'em. (Score:2)
Re:Push 'em. (Score:2)
Assuming that is how you understood salts to work, then I am confused where human-memorable salts enter the picture. Why would the human even see the salt, as it is a random number supplied by the remote client program?
You're
Re:Push 'em. (Score:2)
Not very. It only works if your server has a plaintext equivalent of your password. It's useless if you're authenticating against LDAP, for instance. Usually you'll end up using Basic authentication (plain text password) over SSL.
Re:Push 'em. (Score:2)
2) One-time Passwords - think S/Key. I think Apache needs mod_auth_pam, and the PAM module for S/Key needs to be configured. I havn't done this, but the buzz is opiepasswd is the most flexible PAM module.
KERBEROS. A whole bunch of work to kerberize one service, but if you start here, you can move to K5 for most of your infrastructure. I like t
DVD (Score:2, Interesting)
Re:DVD (Score:1)
Re:DVD (Score:1)
Re:DVD (Score:2)
Re:DVD (Score:2)
Re:DVD (Score:2)
SCP (Score:2, Informative)
Re:SCP (with -c none) (Score:3, Informative)
It isn't always enabled; your admin may have to set it up. Google around for the details.
Re:SCP (with -c none) (Score:2, Informative)
Re:SCP (Score:1, Informative)
ummm... (Score:1)
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
SFTP slowness (Score:4, Informative)
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.
one time passwords (Score:2)
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 [openbsd.org]
Re:one time passwords (Score:1)
sftp? (Score:1, Offtopic)
Re:sftp? (Score:1, Insightful)
PPP? (Score:1)
Custom Perl Server! (Score:1)
(Darn,
server.pl [sablesoftware.com]
client.pl [sablesoftware.com]
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.
Re:PPP? (Score:1)
Re:PPP? (Score:2)
Microsoft managed to do it. The protocol is called pptp and does just that. I know this is off topic, just wanted to point out that ppp over ip is totally doable.
http://www.poptop.org [poptop.org]
Re:PPP? (Score:2)
telnet over tcp over ip.
Useful for getting a back-door into your
company's network.
Re:PPP? (Score:1)
Re:PPP? (Score:1)
One-time passwords (Score:4, Informative)
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...
OTP Calculators (Score:2)
For those on the go an OTP calculator for the Palm OS: http://palmkey.sourceforge.net/ [sourceforge.net].
Don't authenticate (Score:2)
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.
FTP and SSH (Score:2)
Re:FTP and SSH (Score:2)
This approach will crash and burn if attempting to traverse a stateful firewall, of course, since such a beast needs the info in the control conection in order to allow the data connection back through.
Re:FTP and SSH (Score:2)
Not if you use FTP in PASV mode though, right? Using PASV lets the client do the connection to the server for both the control and data connections.
very simple - tunnel ftp over SSH (Score:4, Informative)
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.
Re:very simple - tunnel ftp over SSH (Score:2)
for example, if you limit the clients that can use it to the active mode ones, you can actually portforward the control connection from any computer you like on internet(so the computer that actually serves the files, and brings up the data transfer connections can sit behind a firewall that allows no incoming connections)
Anonymous FTP (Score:2)
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
Try a faster cipher (Score:5, Informative)
To tell sftp to tell ssh to use blowfish I believe you need "sftp -oCipher=blowfish"
Re:Try a faster cipher (Score:4, Informative)
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.
Re:Try a faster cipher (Score:2)
Re:Try a faster cipher (Score:2)
Or maybe scp is trying to compress files that are already compressed?
Re:Try a faster cipher (Score:2)
The scp (which uses the scp1 protocol over ssh), which is what you that comes with OpenSSH seems to use some insanely slow protocol over SSH. My guess is that it uses some sort of "send, wait-for-ack" mechanism.
The CPU is *not* maxxed. I'm sending from a PIII-650 to/from a Thunderbird 1200 over a wireless LAN card.
My point is that it's not the cipher that's the problem, it's probably the archaic SCP1 protocol
Re:Try a faster cipher (Score:2)
Good point! Shows how assumption is the mother of all problems, I stand corrected, cipher none is not such a good idea.
WebDAV or HTTP? (Score:2)
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
Re:WebDAV or HTTP? (Score:1)
tunnel FTP through SSH (Score:2)
-c None (Score:2, Redundant)
That should use scp with no cipher. You can, however, still use a key pair for authetication. Thus, auth is secure, transmission is plain.
Re:-c None (Score:2)
Re:-c None (Score:2)
How about kerberos? (Score:4, Informative)
"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/
Re:How about kerberos? (Score:2)
Re:How about kerberos? (Score:2)
I've collected a bunch of Kerberos information at the ROSPA website [rospa.ca], and I have several realms in production use. It provides the sort of magic that seems simple until you try to work at a site that doesn't use it.
sftp too slow - WHY? (Score:2)
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 j
Re:sftp too slow - WHY? (Score:2)
Even without hardware crypto, any modern 1GHz CPU can saturate a fat pipe using AES or Blowfish as the cypher algorithm. Quit blaming sftp and find a way to make sftp work properly.
Blowfish tops out at 10Mb/s? (Score:3)
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
Re:sftp too slow - WHY? (Score:2)
Re:sftp too slow - WHY? because: (Score:2)
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 efficien
netcat? (Score:2)
Machine a:
# nc -l -p 1234 > file
Machine b (via ssh session):
# nc machinea 1234 file_to_send
Re:netcat? (Score:2)
Re:netcat? (Score:2)
And as somebody pointed out, the second line should read:
Machine b:
# nc machinea 1234 file_to_send
(stupid HTML)..
To do it with SSH (grab that actual disk image) (Score:2)
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.
Re:To do it with SSH (grab that actual disk image) (Score:2)
Re:To do it with SSH (grab that actual disk image) (Score:2)
Re:To do it with SSH (grab that actual disk image) (Score:2)
Would that still encrypt the password though?
E-Mail (Score:2)
Or just use scp, which is easier still.
Re:E-Mail (Score:2)
Email is a 7 bit medium. If you take a file and encode it for email, you are basically getting 8 bit content to work in a 7 bit medium. This means that the overall file size is increased. Since the author was complaining about speed, adding that overhead isn't likely to help.
That + the fact that email really isn't designed for transferring large files around. You'd probably break the hell out of whatever mail system you were using anyways.
There
Few quick options (Score:2)
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
you can still use scp (Score:2)
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
Use SCP with the 'none' block cypher (Score:2)
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,
Kerberos FTP (Score:1)
Kerberized FTP (Score:2)
(b) Why is it "too slow"? A modern system running AES can saturate a 100Mbits/sec network.
Re:Kerberized FTP (Score:2)
I pegged the box about about 60-80% CPU utilization a
FTPS (Score:2)
Kerberos (Score:2)
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 s
Rsync over ssh (Score:2)
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.
Use rsync direct over tcp (Score:2, Informative)
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
Try rsync over ssh (Score:2)
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...
correcting mis-information, and a solution (Score:4, Informative)
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 [berkeley.edu]. It encrypts the password, but not the data. Exactly what you asked for.
Re:correcting mis-information, and a solution (Score:2)
Re:correcting mis-information, and a solution (Score:3, Informative)
So, -c none only with RSA authentication, please.
man scp. (Score:2)
kerberos or srp (Score:2)
HTTP Digest Auth or S/Key (Score:2)
end, if you enabled digest auth on your httpd.
alternatively, there is s/key auth for ftp.
Anon ftp with IP range restrictions (Score:2)
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.
SAMBA (Score:2)
You can do this: (Score:2)
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'?
UDT (Score:2)
Probably only an option with dedicated lines, though. I don't think they bothered with authentication. But the transfer rates are nice.
kerberos telnet/rcp/ftp (Score:2)
Challenge-response (Score:2)
Re:Make sure you understand the security requireme (Score:2)
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.
Re:ftps (Score:2)