Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security The Internet

Sending Files w/o Sending Clear Passwords? 151

Posted by Cliff from the between-ftp-and-scp dept.
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?"
This discussion has been archived. No new comments can be posted.

Sending Files w/o Sending Clear Passwords? More

Sending Files w/o Sending Clear Passwords?

Comments Filter:

  • Push 'em. (Score:3, Informative)

    by TheSHAD0W ( 258774 ) on Tuesday October 14, 2003 @10:16PM (#7215661) Homepage
    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.
    • To be more explicit:
      (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.
      • If you don't secure your data transmission you might as well not login. You might as well just go all plaintext, because a man-in-the-middle attack could be used to inject whatever your trying to secure with your "secure password only" approach anyways.
    • Just a quick note, if you use a passworded http directory, your password is NOT sent in clear text on most modern web server configurations. They are usually hashed with MD5 somehow - there's a standard, but I can't seem to Google it right now. (This doesn't encrypt the data, it just secures your password)
      • Actually the password is base64 encoded, to be safe over 7bit media. It's still very much "plain text".
        • OK, you had me worried for a bit (no pun intended)!

          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.
          • MD5 is still susceptible to dictionary attacks. So you better choose random characters as your pass if you plan on using HTTP Auth. Somebody needs to petition to get SRP as the new Secure Remote Password mechanism.
            • It shouldn't take too long to write a javascript function for encrypting salt+password with the password. Send this as your authentication; the server decrypts with known password to confirm.

              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.
              • This is also susceptible to dictionary attack. Scenario:
                Man in the middle intercepts your authentication message. Stores it in memory then runs the same salt on a dictionary. No problem.
                • The salt is encrypted w/ the password:

                  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
                  • That would require the remote authentication service to have the same synchronized times (to the precision of the time declaration), and it would also require the knowledge of the salt by the end user as a third credential. Furthermore, the enumeration through possible human memorable salts along with the dictionary makes it still susceptible to dictionary attacks. Because even though it is salted with the time and a number the time can be recorded and the number can be brute forced along with the passwor
                    • I must be losing my explantory powers. The salt, by what I thougth was standard convention, is a random number generated by the password creation routine -- in this case javascript (as per my granp-parent post). My apologies for either misusing terminology or poorly explaing myself.

                      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
          • I don't really know how popular this digest authentication is

            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.
      • 1) Digest Auth HTTP. (http://www.ietf.org/rfc/rfc2617.txt) For IIS it's a check-button, Apache it's a mod: mod_auth_digest (Requires capable browser: IE or Moz).

        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)

    by Dancin_Santa ( 265275 )
    Snail mail doesn't require a password.

  • SCP (Score:2, Informative)

    by CyberVenom ( 697959 )
    Try scp. It is included with ssh.

    • Re:SCP (with -c none) (Score:3, Informative)

      by 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.

    • Re:SCP (Score:1, Informative)

      by Anonymous Coward
      And if you're working with a win box, WinSCP3 is a pretty good app.
  • 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

    • SFTP slowness (Score:4, Informative)

      by lpontiac ( 173839 ) on Tuesday October 14, 2003 @10:48PM (#7215942)
      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.
  • 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 [openbsd.org]

  • sftp? (Score:1, Offtopic)

    by __aafkqj3628 ( 596165 )
    I always thought sftp was secure and allowed file transfer.

    • Re:sftp? (Score:1, Insightful)

      by Anonymous Coward
      Congratulations on not even reading the submission text, you unbelievably stupid piece of shit.
  • 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...)
    • Here You go!
      (Darn, /. doesn't seem to like code. Well here's a link to the code then!)

      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.
    • What the? How would you manage to run PPP over IP? It's a WAN protocol. SFTP, on the other hand, uses the SSH Transport Layer protocol, and as such, can run on top of TCP/IP. Have fun writing your "script."
      • > How would you manage to run PPP over IP?

        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]
        • There's a project on sf.net for ppp over
          telnet over tcp over ip.

          Useful for getting a back-door into your
          company's network.
      • I think the whole point is that encrypting the entire datastream is too processor intensive in this case, so SFTP (or even SCP) would be out of the question. PPP could potentially be run over a TCP/IP socket (like VPN/PPTP). Not that PPP itself is really the point, I just thought that there might be a way to use existing authentication methods. The script I wrote does not use PPP, but implements a challenge handshake based on some of the same concepts as CHAP.
        • Well, the reason I raised an eyebrow is because you seemed (IMHO) to point to PPP being the core of this whole thing. PPTP is something different entirely (a something I hate with a passion but that's another discussion all together ;)). Really, PPP, or PPTP, not CHAP are critical to this. All you really need is a challenge response. Avoiding this all together, we can just use a one time password. There are numerous (good) ways for implementing those.

  • One-time passwords (Score:4, Informative)

    by jhealy1024 ( 234388 ) on Tuesday October 14, 2003 @10:26PM (#7215758)
    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...
  • 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.

  • 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.
    • ...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.

      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.
      • 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.
        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)

    by stonebeat.org ( 562495 ) on Tuesday October 14, 2003 @10:41PM (#7215882) Homepage
    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.
  • I think you should use anonymous ftp (your operator should be fairly happy with that, it's the one remaining, legitimate use of ftp there is), then log in securely using ssh and move it somewhere safe and run an md5 checksum on it to check that it made the trip without any modifications or corruption.

    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)

    by semanticgap ( 468158 ) on Tuesday October 14, 2003 @10:46PM (#7215926)
    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 (Score:4, Informative)

      by kwerle ( 39371 ) <kurt@CircleW.org> on Wednesday October 15, 2003 @12:05AM (#7216349) Homepage Journal
      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.
      • Odd. scp is *much* slower than rsync -e ssh on my system.
        • That seems REALLY unlikely, unless rsync is telling scp to use a faster cipher. Is it slow because the CPU is maxed?

          Or maybe scp is trying to compress files that are already compressed?
          • rsync doesn't use scp. It uses ssh to open a channel to a remote "rsync --server" command.

            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

  • 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

    • You don't need a script. There's a standard PUT command in the HTTP spec. If you use windows you can drag and drop files into a netscape window to transfer them up. On a *nix you can use curl (with the --upload-file option). Just make sure it's password protected and you're ready to go.
  • 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.

  • -c None (Score:2, Redundant)

    by KagatoLNX ( 141673 )
    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.
    • Newer versions of OpenSSH don't support -c none. (The usual security zealot nonsense from the OpenBSD people from what I can tell. There *is* a place for -c none.)

  • How about kerberos? (Score:4, Informative)

    by DeathBunny ( 24311 ) on Tuesday October 14, 2003 @10:49PM (#7215949)
    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/
    • Yes. Mod parent up. Kerberos is exactly what this person is looking for.
    • I agree, Kerberos is definitely the solution here. Aside from solving the original poster's problem, it also does a whole bunch of other cool stuff - consider it a bonus :-)

      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.
  • 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 j
    • Soekris will soon have a new PCI crypto accelerator, the VPNL401 [soekris.com] Encryption at 400Mbs. That ought to be enough encrypted bandwidth to map every prospective Starbuck's franchise in the Virgo Galactic Cluster.

      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.

    • I haven't done the investigation as to why, but SSG (and by extension, scp/sftp) doesn't approach the throughput of FTP.

      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

    • 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 pip

    • 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 efficien
  • 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
  • Mail it and have a procmail-driven script that puts it in the right directory. Use perl's MIME and other mail modules to make it easy (both for sending and procmail). No, this isn't 100% secure, but the potential damage is not much worse than mail-bombing - the worst someone could do is intentionally fill up your storage...which they can probably already do. And there's no password at all this way.

    Or just use scp, which is easier still.

    • Thats got to be one of the worst suggestions I've ever heard.

      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
  • 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
  • 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
  • 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,
  • 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.
    • I've always used rsync, and just sucked the files down. I've found that SSH is considerable slower then FTP or RSYNC on 100Mbit/sec. Granted that was on a dual processor PIII-700 Xeon (both to and from). I used that stock redhat cipher, and then switched to blowfish, while that helped, it still sucked. There are a few interesting tidbits mentioned in the threading about it could possibly be OpenSSH buffering, and flow control that is causing issues.

      I pegged the box about about 60-80% CPU utilization a

  • 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.
  • Kerberos will do this, although you will have to put a bit of effort into setting up a domain. Essentially, it allows you to do fully authenticated rsh, rcp, ftp, etc. while never transmitting your password. Instead, you get a cryptographic key.

    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

  • I use rsync over ssh to make up for many of scp/sftp weaknesses. eg:

    rsync -e ssh /local/file user@host:/remote/file

    (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.

    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
  • This method can also be used as a push or pull.

    rsync -azve 'ssh' /localpath remote.site:/remotepath

    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...
  • 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 [berkeley.edu]. It encrypts the password, but not the data. Exactly what you asked for.

  • ssh, trough scp can do what you want. It never sends passwords in the clear, and it'll happily use whatever cipher you specify for encrypting the data itself. If you want no cipher, you need only specify the command-line switch "-c none"

  • 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/ [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.
  • 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.
  • Use samba with the "encrypt passwords" option.
  • 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'?

  • UDT (Score:2)

    by 4of12 ( 97621 )
    6.8 Gbs [sciencedaily.com]

    Probably only an option with dedicated lines, though. I don't think they bothered with authentication. But the transfer rates are nice.

  • You want kerberos V5 telnet/rcp, secure authentication, but without the overhead of encrypting the data stream:

    [paul@fogarty paul]$ echo "kerberos is nifty" > /tmp/kfile
    [paul@fogarty paul]$ rcp /tmp/kfile hibernia:/tmp
    Trying krb4 rcp...
    trying normal rcp (/usr/bin/rcp)
    [paul@fogarty paul]$ telnet -a hibernia
    Trying 192.168.0.3...
    Connected to hibernia.somewhere (192.168.0.3).
    Escape character is '^]'.
    [ Kerberos V5 accepts you as ``paul@SOMEWHERE'' ]
    Last login: Wed Oct 15 03:38:04 from fogarty
    You have mail.

  • 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.

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close