Multi-Threaded SSH/SCP

neo writes "Chris Rapier has presented a paper describing how to dramatically increase the speed of SCP networks. It appears that because SCP relies on a single thread in SSH, the crypto can sometimes be the bottleneck instead of the wire speed. Their new implementation (HPN-SSH) takes advantage of multi-threaded capable systems dramatically increasing the speed of securely copying files. They are currently looking for potential users with very high bandwidth to test the upper limits of the system."

Comments

A likely story

[sqldr]

Hi, I've invented a new way of downloading pron^H^H^H^H^H^Hcopying files across a network. If you have uber bandwidth, please contact me urgently!

Re:A likely story

[slyn]

Makes you wonder how many innovations can either be directly attributed to or partially attributed to the distribution of porn (not (necessarily) that this is).

VHS v Betamax comes to mind.

Re:A likely story

[harry666t]

Get a /real/ girl.

Re:A likely story

[shenanigans]

I think this story is interesting because it shows a general trend: increased focus on multi-threading. We will see much more of this in the future as multi-core and multi-processor systems become more common. This trend is driven not by porn though, but by that other big driving force behind the computer industry, gaming.

Re:A likely story

[neumayr]

They're overrated..

Re:A likely story

[empaler]

AND they get pregnant.

Re:A likely story

[mikael]

People are always willing to pay more to be entertained that to be educated.

Which explains why football players and movie stars will get paid more than the innovators that carried out the research to develop the broadcast technology that helped to make those stars famous.

Re:A likely story

[Anonymous Coward]

...what's wrong with looking at porn with a real girl?

Re:A likely story

[Anonymous Coward]

People are always willing to pay more to be entertained that to be educated.

Which explains why football players and movie stars will get paid more than the innovators that carried out the research to develop the broadcast technology that helped to make those stars famous. Another big issue is that there are fewer stars than researchers. As such, it is more difficult to replace any given star than to replace any given researcher. The star does a greater portion of the work than the researcher (even if all the stars do a smaller portion than all the researchers).

Replace a star NFL quarterback with his backup, big drop in performance of the team. Replace a top researcher with a new hire, a big drop in performance of her immediate team but the overall group of teams is impacted only slightly.

Re:A likely story

[Sczi]

And then you're just going to want to post their nudy pics on the net anyway, so we're back to square one.

Re:A likely story

[somersault]

Not if they're like 80. Extra benefits there are a lack of teeth.

Re:A likely story

[rapier1]

Actually, this is one of the main reasons why we did this. If you look at where processor architectures are going they aren't necessarily increasing the pure computational power of each core as much as they are using more and more cores. If you are in a situation where you have a single threaded process that is CPU bound - like SSH can be - you'll find that throughput rates (assuming that you aren't network bound) will remain flat. In order to make full use of the available network capacity we'll have to start doing things like this. There is still a lot of work to be done but we're pleased by our progress so far.

Re:A likely story

[dodobh]

There's also message passing and event driven programming, which can be a much simpler model if done right. Multi threading tends to shared state, and that's bad for programmers.

Re:A likely story

[Mikkeles]

They're overrated..

But never overinflated!

Re:A likely story

[Anonymous Coward]

"...what's wrong with looking at porn with a real girl?"

They cost too much.

Re:A likely story

[Mister Whirly]

Because slasdotters generally can either only afford to pay for the porn site, or pay for the girl, but not both.

Re:A likely story

[Bob of Dole]

Hey, I graduated college with a final project I originally built to search porn.

Porn powers computer science.

Re:A likely story

[Anonymous Coward]

... PAY for porn? I don't understand...

Re:A likely story

[Anonymous Coward]

Yes, pay. You don't think those 2 girls are going to fill the cup for free, do you?

Re:A likely story

[geminidomino]

There's also message passing and event driven programming, which can be a much simpler model if done right. Multi threading tends to shared state, and that's bad for programmers. Would you mind going into more detail on why you say this?

Not a challenge, a genuine request for more information.

Re:A likely story

[starfishsystems]

I completely agree. In fact there was a great paper on this which came out about ten years ago. Can't find it for the life of me, but it walked through several common examples of multithreading and showed how each could be more simply reimplemented with events. Anyone recognize this paper?

Threading provides an excellent opportunity for programmers to shoot themselves in the foot. If requirements can be satisfied using events, use them!

Re:A likely story

[adamfranco]

People are always willing to pay more to be entertained that to be educated.

I don't know how much your entertainment costs are, are they anywhere close to $45,000 per year?

If tuition rises any more, today's students (at some institutions) will be paying $200,000 for a 4-year undergraduate degree if they don't get financial aid.

Re:A likely story

[jhol13]

There are a lot of studies/experiments which have concluded that "threads are bad".

OTOH some system build e.g. with Erlang have been much more a success. For example http://yarivsblog.com/articles/2006/06/14/more-erlang/, although I'd say the test has been rigged to show Erlang in a very positive light.

Not that you asked from me :-)

Re:A likely story

[abigor]

This IEEE article sums it up nicely: http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover.xml&xsl=article.xsl

Also look up Erlang and tuple spaces. The latter are implemented in various ways: LinuxSpaces, JavaSpaces, etc.

Erlang's huge uptime and reliability is notable. It is of course the one language designed specifically for running parallel applications.

I look at the threading issue kind of like how we used to look at memory management: it's unnecessary bookkeeping for most apps and subtracts time spent on the actual problem domain. Ten years ago, we worried about memory management, but then garbage collection came along and for most purposes, memory management wasn't a huge issue any more (I'm not talking about the areas where C/C++ are crucial, obviously). In the same sense, programmers currently spent an inordinate amount of time debugging threaded apps when they should be focused on other things, like solving the business problem they've been presented with.

Clearly there's room for improvement, and I wonder if tuple spaces will do for parallel programming what garbage collection did for memory management.

Re:A likely story

[Anonymous Coward]

"Always" is a dangerous word.

I paid low-6-digits for a 4-year-degree from a top school -- and that's not even counting travel to other continents for scientific research and foreign language study. I sure as heck haven't paid that much for entertainment in my whole life.

Besides, part of it is simply availability. Much of education in this country is done by the government, who is not (to say the least) known for their ability to monetize things to the greatest extent possible. How many of you would buy a complete set of "3-2-1 Contact" DVDs, if such a thing existed?

Re:A likely story

[jovetoo]

It is rare that you can completely separate every context of every step of your processing. There is always some data that needs to be shared between the threads and they become bottlenecks. The faster you serve your requests, the worse the contention (waiting for a resource) and thus the inefficiency.

It depends on the task at hand and on your architecture. A file or web server is less likely to encounter contention than for example an IRC server. The first requires some authentication and resource resolving through configuration data but the actual data can be send without interference from other requests. An IRC server requires constant lookups in the user database for routing information and this is likely to take longer than actually sending the messages (even without multi-threading). In these cases, you really have to think your locking scheme through or you will lose more time waiting for a lock than doing actual work - defeating much of the purpose of going MT.

When it comes to architecture, multi threading is an option in your architecture, not an architecture in itself. There is no problem doing a multi-threaded event-driven architecture or a MT message passing architecture -- these are actually very effective. For some interesting reading about this, I would suggest you check out the SEDA white paper for a pretty in depth list of options and their goals.

Why is it bad for programmers? Because locking is hard to do in itself and if your locking scheme is subobtimal it often requires a lot of work to change it afterwards.

Re:A likely story

[jhol13]

There is always some data that needs to be shared between the threads and they become bottlenecks. This has not been (the biggest) problem in my experience. Much bigger is the problem that one thread does so little before giving CPU to next thread. If a thread uses a lot less time than the time slice is the system will get a huge performance penalty. No OS I know even schedules same thread twice in one time slice - not that it would help as the context switch (cache flush) is at least order of magnitude heavier than lightest tasks *I have*.

Re:A likely story

[dodobh]

This one perhaps? : Threads.pdf

Re:A likely story

[dodobh]

Additionally, locking resources tends to expose you to race conditions. Message passing and/or event driven, shared nothing architectures explicitly make the decision to copy data as opposed to sharing it, and avoid those race conditions. Non atomic access to shared structures is bad, and atomic access becomes the performance bottleneck.

Re:A likely story

[starfishsystems]

Yes! Thank you!

Written by John Ousterhout, the guy who developed Tcl/Tk. So I guess he has a bit of an axe to grind in promotion of events versus threads, but he makes some good points.

Someone please mod this "informative."

Re:A likely story

[Shadowlore]

We will see much more of this in the future as multi-core and multi-processor systems become more common. This trend is driven not by porn though, but by that other big driving force behind the computer industry, bloated operating systems and office programs.

There you go, all fixed.

Re:A likely story

[Anonymous Coward]

That's lovely, except you lose the important attribute that threads can actually run in parallel when you have more than one CPU.

The fact that even after all these years to get used to the idea, the majority of developers still are not comfortable with threads is just mind boggling. Either I'm superman and my brain works differently to 99% of all developers or it actually really isn't that hard after all!

Re:A likely story

[ignavus]

And people wonder why we geniuses turn to evil!

"With my new wonder death ray, I - Doctor Blitztod, Professor of Nuclear Physics at an underfunded college - *will* be paid like a celebrity, I tell you! All bow to me or die!"

Re:A likely story

[CajunArson]

If you read the PDF you posted you will note that it mentions in BIG RED LETTERS: "No CPU Concurrency" This paper touts events as being a simpler programming model (and it makes a good point) but it expressly disclaims their use for things like high-performance concurrent software running on multi-CPU systems (meaning any system sold in today's market, with even more cores coming in the future).

Re:A likely story

[dodobh]

Nothing constrains events to be handled by a single process. You can just spawn off n processes, one of which is a queue manager for dispatching events to the rest. Each of those processes is then a shared nothing architecture, and independent of the rest of the processes involved. This isn't difficult, see Postfix for example.

Lots of simple applications, each doing one thing well and able to pipeline.

Re:A likely story

[shenanigans]

Yes, you are right. A queued event system works great in parallel in many cases, and probably in more cases than it is being used. A great example is the standard Windows or X desktop, where each window is a thread (program) and everything is done through a central event handler.

For many systems however, where you have writeable shared data, you would still have to invent some kind of locking and you end up with the same problems as when using threads directly. This works on the desktop because programs seldom have to use the same resources or files simultaneously, and if they do its acceptable to just let them fail.

Re:A likely story

[harry666t]

It's like sitting in a real car with engines off and watching Fast&Furious 8.

Re:A likely story

[geminidomino]

Replying to myself to thank everyone who replied to me. Interesting stuff.

And they say slashdot is just for memes and flamewars.

Re:A likely story

[mikael]

I really meant "Joe average" who has just come home from work in the evening or is at home on the weekends. Viewing figures are always considerably higher for sports games and movies, than for anything scientific or technical.

Re:A likely story

[Anonymous Coward]

This is a case where threading is the right choice - they are just multithreading the encryption part of the task, which was a bottleneck. They aren't creating socket listeners waiting for 1000s of connections or doing a bunch of tasks, it's for some research group to pump 100s of GBs of data from Stanford to CERN or similar via scp. They used the right tool for the job.

The stuff you mention is good for other situations but doesn't map well to the constraints they were trying to work within.

this is just what i've been looking for

[Anonymous Coward]

not that scp as-is isn'--stalled--

Must be why rsync over ssh is much faster

[MichaelSmith]

I get a lot of use out of ssh for moving files around and rsync is definitely the best way to do heavy lifting in this area. Improving scp would be good to. I can't wait to hear what Theo thinks about this. I don't see him as a fan of adding complexity to improve performance.

Big scp copies through my wifi router used to cause kernel panics under netbsd current of about a year ago. I never had that problem running rsync inside ssh.

Re:Must be why rsync over ssh is much faster

[Anonymous Coward]

Eh? I've not even read the article but the summary clearly states that crypto is a bottleneck for some networks. Multithread that and everything tunneled over SSH should see improvements on modern multiproc boxes -- at least where it's the crypto overhead and not bandwidth that's the current bottleneck.

Re:Must be why rsync over ssh is much faster

[MichaelSmith]

There is definitely something funny(strange) about the way scp does bulk copies. It stops and starts. Other applications happily stream through encrypted ssh connections.

And in my experience rsync is faster.

Re:Must be why rsync over ssh is much faster

[cheater512]

Rsync doesnt encrypt. SSH/SCP does.

Rsync is only really useful as a synchronizing method between a source and a out of date copy.
Then its real benefits get shown.

Re:Must be why rsync over ssh is much faster

[AnyoneEB]

Unless your servers are running rsh, rsync is probably going to get routed through ssh, in which case it gets encrypted just like scp. ref:

Secure Shell - The security concious of you out there would like this, and you should all be using it. The stream from rsync is passed through the ssh protocol to encrypt your session instead of rsh, which is also an option (and required if you don't use ssh - enable it in your /etc/inet.d and restart your inet daemon if you disabled it for security).

Re:Must be why rsync over ssh is much faster

[Tony Hoyle]

That's just flat out wrong. rsyncd has its own, unenctypted, protocol.

You can run it from inetd or as a daemon, but it's unrelated to rsh.

That connection may or may not be encrypted depending on the route it takes.. VPNs tend to be encrypted for example, but LAN connections not.

Re:Must be why rsync over ssh is much faster

[blueg3]

From "man rsync":

There are eight different ways of using rsync. They are: ...
* for copying from the local machine to a remote machine using a remote shell program as the transport (such as ssh or rsh). This is invoked when the destination path contains a single : separa-tor.
* (same as the above, but copy from remote to local machine)

Note that the remote machine could alternately have an rsync server. However, this is not required -- if the remote machine does not have an rsync server, transport is done via a shell. In my experience, this often how people use rsync, and they often use ssh as the transport shell.

Re:Must be why rsync over ssh is much faster

[rasputin465]

And if you have both available, it becomes a little ambiguous. However, this excerpt from the rsync man page indicates it uses ssh as default (unless the system is old):

Once installed, you can use rsync to any machine that you can access
via a remote shell (as well as some that you can access using the rsync
daemon-mode protocol). For remote transfers, a modern rsync uses ssh
for its communications, but it may have been configured to use a dif-
ferent remote shell by default, such as rsh or remsh.

You can also specify any remote shell you like, either by using the -e
command line option, or by setting the RSYNC_RSH environment variable.

Re:Must be why rsync over ssh is much faster

[drinkypoo]

If you just want to copy some files from system to system in an encrypted fashion, then the BEST option by far is to use tar, and pipe it through ssh like so:

tar cvfpz - * | ssh user@host '( cd /destination ; tar xvfpz - )

This example will compress and encrypt your data before sending it; on the other end, the file is streamed to tar. This example requires GNU rar or a close facsimile.

Now, if you want to UPDATE a directory, use rsync:

rsync -av -e ssh * user@host:/destination/

Because rsync will do partial checksums and send parts even of BINARY files if the whole file has not changed, and doesn't re-send unchanged files, rsync makes sense when updating a directory. But it provides no speedup benefit over using tar, and in fact the directory scans it does before the sync mean that it may actually be slower.

Use scp only for copying single files, because you're right, scp chokes between each file.

Re:Must be why rsync over ssh is much faster

[rapier1]

As a note, the changes are actually to SSH itself and not just SCP. So any application that uses SSH as a transport mechanism can see a performance boost. This isn't to say *every* user will. This is mainly geared towards high bandwidth delay product networks (greater than 1MB) or GigE LANs.

Re:Must be why rsync over ssh is much faster

[gazbo]

SSH can, of course, be configured to compress automatically.

Re:Must be why rsync over ssh is much faster

[ComputerSlicer23]

tar cfpz - . | ssh user@host '( cd /destination ; tar xfpvz - )'

I'd use a "." instead of *, it avoids shell line length problems, and will also copy hidden files... as someone who as learned this the hard way. Also in my experience, on anything faster then 10MB, don't bother with compression (it's really a CPU to network speed ratio, on transfers I did regularly that was the rule of thumb with P4 2.2Ghz Xeons). Also, I removed the "v" from the source tar, as it duplicates every file name twice and can be hard to read. I can't remember if ssh or tar had better compression, I know I tested both. It really just changed the tipping point of the CPU speed. I also used to use blowfish for the cipher as it was easier on the CPU if you were running out of CPU instead of network. On a Gigabit network, I always ran out of CPU first.

I normally use -C instead of a subshell, but that's merely a matter of taste. I also use the technique in reverse quite often so I can untar on the destination machine as root.

Kirby

Re:Must be why rsync over ssh is much faster

[John Fulmer]

Unless you are moving large amounts of data over an unreliable network. rsync can recover a failed transfer; tar cannot.

Re:Must be why rsync over ssh is much faster

[t35t0r]

rsync can compress with -z flag and as you know it can use ssh as the transport

Re:Must be why rsync over ssh is much faster

[RevDigger]

Have you ever benchmarked this? It's a beautiful trick, but I couldn't even fill up a 10M local network link the last time I tried it. Same with SSH and rsync. Same with NFS.

The best performance I got was piping a tar/gzip through netcat. That requires a trusted network though.

Re:Must be why rsync over ssh is much faster

[Khopesh]

Lose the "v" flag; its verbosity consumes bandwidth and takes up screen-painting time (people don't realize that the time spent to display things in your terminal is time not spent plowing through files). This is a significant speed boost when transferring lots of smaller files, and is not limited to tar-over-ssh (the saved screen-painting is more significant when purely local).

You also have an un-matched quote in the tar line, and you don't need the parenthesis. The "f" flag must be immediately followed by the file name ("-"), too. Use this instead:

tar cpzf - * | ssh user@host " cd /destination ; tar xpzf - "

(I changed the quote type just in case a user wants to use a variable in there.)

Also of note, tar does a great job of retaining ownership by UID/GID, but only when run as root. To use that, assuming there's enough room on the target system, dump a tarball there and unpacking it as root later:

sudo tar cpzf - * |ssh user@host "cat >/tmp/archive.tgz"

And then on the target host:

cd /destination; tar xpzf /tmp/archive.tgz

Re:Must be why rsync over ssh is much faster

[Anonymous Coward]

scp and typical rsync over SSH suffer a major security issue: they allow normal user access to the entire filesystem of the SSH server. You may not think that matters at first, but the access to /etc/passwd can reveal the account names and likely targets for spam or SSH brute force password attacks. Similarly, a lot of shared SSH servers are not really secured against client access to system files. The "sftp" tool in SSH servers is no better, and it mishandles both hard links and symlinks.

There are other technologies for massive downloads: bittorrent is effective, and WebDAV over HTTPS allows authenticated upload in a way that does restrict access far more safely than any SSH tools, until and unless SSH tools include a real chroot cage. And by the way? That whole "chroot" craziness in OpenSSH some years ago has nothing to do with a normal chroot cage, and is useless in these terms.

Re:Must be why rsync over ssh is much faster

[Anonymous Coward]

You want to add at least '-e none' as argument when piping into ssh or reading from an ssh pipe.

Re:Must be why rsync over ssh is much faster

[timeOday]

scp isn't slow because of compression, it's slow because it has significant latency to initiate the transfer of each single file (even if you do it with a single command like scp -r), during which time the bandwidth goes unused. Using tar as stated above fixes this problem because it's one continuous stream of data. For a large number of small files, it's a big speedup.

Re:Must be why rsync over ssh is much faster

[timeOday]

tar cpzf - * | ssh user@host " cd /destination ; tar xpzf - "

You don't need a quoted pair of commands, just use tar's -C option

ssh user@host.com tar -C /remote/path -cpzf - remotefile1 remotefile2 | tar -C /local/path -xvzp -

Re:Must be why rsync over ssh is much faster

[Khopesh]

Your code goes the other direction, and ignores my point about lost performance from verbosity. You're right that -C works in place of the "cd" command, which takes out the semi-colon and thus the need for quotes. I've found I can't rely on GNU extensions at work (lots of really old commercial UNIX boxes here), so its safer to do it the old-fashioned way.

Archive to a remote host:

tar cpzf - localfile1 localfile2 |ssh user@host tar -C /destination -xpzf -

Archive from a remote host:

ssh user@host tar -C /remote/path -cpzf - remotefile1 remotefile2 |tar -C /destination -xpzf -

Re:Must be why rsync over ssh is much faster

[WindShadow]

I used earlier versions of this patch, with large buffers and "none" encoding over an internal GigE network. I did find that with even moderately modern CPUs, like 2.4GHz P4 w/o HT, that just switching to "blowfish" encryption made a world of difference in transfer speed, and needs no patches.

scp -c blowfish myfile other.invalid:incoming/

Re:Must be why rsync over ssh is much faster

[drinkypoo]

Also of note, tar does a great job of retaining ownership by UID/GID, but only when run as root. To use that, assuming there's enough room on the target system, dump a tarball there and unpacking it as root later:

If I wanted to copy a single file, I could just use scp. As a sibling comment says, I can just initiate the transfer from the other end:

ssh user@host 'tar cf - directory' | tar xf -

That solves your problem of being root. I've done it many times. You could also just enable remote root logins of course. Probably a bad idea via the internet but not as serious inside.

Re:Must be why rsync over ssh is much faster

[Khopesh]

Nobody here was addressing single files; scp is great for small transfers. When it comes to backing up large filetrees, scp just isn't an option. When it comes to preserving permissions, you're right ... I'm usually in a situation that prevents going the easier way, so I forgot that tar preserves permissions while archiving.

I sometimes solve that by opening up root ssh access via a key, doing the transfer, and closing root ssh access (change the sshd_config file, restart sshd, start the ssh transfer, revert the sshd_config file, then restart sshd; the transfer is only on one session, and only new sessions are affected by the restarted sshd).

One thing I forgot to mention was compression-versus-bandwidth comparison. Linux Journal had a really comprehensive article on this called Compression Tools Compared back in July 2005. Basically, it boils down to suggesting even gzip may be too computationally expensive to be worthwhile if you've got a fast network hookup. On your LAN, you're best off without compression, be it through tar or ssh (set "Compression no" in your ~/.ssh/config for your LAN). Of course, it's often faster to send backup tapes via next-day mail...

Alternative solution for a trusted LAN

[Diomidis Spinellis]

If you want to speed up transfers and you're working on a LAN you trust (i.e. you don't worry about the integrity and confidentiality of the data passing through it), you can dramatically increase throughput using socketpipe. Although the initial socketpipe communication setup is performed through client-server intermediaries such as ssh(1), the communication channel that socketpipe establishes is a direct socket connection between the local and the remote commands. This eliminates not only the encryption/description overhead, but also the copying between your processes and ssh or rsh.

How will this affect application deployment

[Zombie Ryushu]

How will this affect the operation of applications wich use SSH to standardie applications accross Linux like urpmi's --parallel parameter?

This is one of the most useful aspects of Mandriva, but as the number of nodes I have to manage increases, I find RPMS being SCPed to other nodes taking longer and longer. I think this is because even though with Kerberos Authentication is much faster, urpmi is waiting until one node finishes copying the files to start copying to the next node in the Domain.

Thoughts?

Re:How will this affect application deployment

[Anonymous Coward]

Set up a local urpmi repository with your local packages and have each machine connect to it to do the update. Now you no longer have to rely on serial execution - tasks can take place in parallel.

Sweet!

[miffo.swe]

I really hope this will make it into OpenSSH after some security auditing. The performance gains was pretty impressive. It will make ssh much more fun for rsync, backups and other times when i transfer large files. I also wonder if one cant get similar performance gains with normal ssh and for example forwarded X-windows. That would be very interesting indeed.

Re:Sweet!

[Jah-Wren Ryel]

I also wonder if one cant get similar performance gains with normal ssh and for example forwarded X-windows. Probably not. The X11 protocol is very latency sensitive, so the bottleneck tends to be round-trip times rather than raw throughput.

I haven't read the article, so I don't know what it says about per-packet set-up times, but I wouldn't be surprised if latency was actually increased due to the overhead of having to at least decide to distribute encryption work across multiple CPUs.

Re:Sweet!

[Per Wigren]

Use NX instead of plain old remote DISPLAY or ssh's X11 forwarding or even VNC! It's silly fast! You get a perfectly usable desktop even on slow, high latency connections. The free edition is free as in GPL.

Re:Sweet!

[Anonymous Coward]

Gentoo's ebuild for openssh includes a hpn USE flag for it. Go forth and build the system & tools as you need/want them. Portage is best package manager out there.

Re:Sweet!

[Neil Hodges]

It even speeds up X where one doesn't use the NX server, making it a good replacement for Xnest and possibly Xephyr.

Re:Sweet!

[msuarezalvarez]

Portage is best package manager out there.

...assuming you do like seeing gcc lines go by for extended periods of time, no?

Re:Sweet!

[Anonymous Coward]

...assuming you do like seeing gcc lines go by for extended periods of time, no?

You do realise you don't have to watch it while it compiles, right?

Re:Sweet!

[msuarezalvarez]

you have to wait, though...

Re:Sweet!

[Mad Merlin]

you have to wait, though...

Not really, you continue using your computer normally while it updates in the background or while you sleep, then it doesn't matter how long it takes.

Re:Sweet!

[msuarezalvarez]

You have to wait for the update to be done. You can of course do something else in the meantime, like brewing a nice cup of tea, but that does not mean that the update is done any sooner.

Otherwise, in the general sense in which you took my post, one could even say that unless you are the last human alive, others can probably do whatever it is you needed the update for in case you die while waiting for the update, so there is really no hurry.

Re:Sweet!

[Mad Merlin]

You have to wait for the update to be done.

No, you don't. Say a new version of Vim is released and I'm currently editing a file (with Vim, of course). I update my Vim install without closing my existing editor and the next time I edit a file, I get the new version instead of the old.

The only time you'd care about the time to compile something is if there's some specific feature that you want in the new version of something, and this isn't particularly common. Mind you, in this case, the rolling update method of Portage (ie, new releases of basically everything are available within a day or two) is still vastly superiour to the "update everything at once every 6 months" method of pretty much every other distro. because waiting a day or two + a few minutes (typical) or hours (big packages) is much preferable to waiting several months + a couple seconds.

Re:Sweet!

[msuarezalvarez]

If you picked portage because you think other distros make you wait six months for updates, well, you made a very misguided decision.

Re:Alternative solution for a trusted LAN

[upside]

You can also use a cheaper cipher. From the ssh manpage:

-c blowfish|3des|des
                          Selects the cipher to use for encrypting the session. 3des is
                          used by default. It is believed to be secure. 3des (triple-des)
                          is an encrypt-decrypt-encrypt triple with three different keys.
                          blowfish is a fast block cipher, it appears very secure and is
                          much faster than 3des. des is only supported in the ssh client
                          for interoperability with legacy protocol 1 implementations that
                          do not support the 3des cipher. Its use is strongly discouraged
                          due to cryptographic weaknesses.

To *have* such problems...

[pla]

the crypto can sometimes be the bottleneck instead of the wire speed.

Between two devices on my gigabit home LAN, the CPU barely even registers while SCP'ing a large file (and that with every CPU-expensive protocol option turned on, including compression). What sort of connection do these guys have, that the CPU overhead of en/decryption throttles the transfer???


Coming next week: SSH compromised via a thread injection attack, thanks to a "feature" that only benefits those of us running our own undersea fiber.

Re:To *have* such problems...

[dm(Hannu)]

They claim that the first bottleneck is actually flow control of buffers, which prevents utilizing full network bandwidth in normal gigabit connections. The threads will help only after this first bottleneck has been cleared. They have patches to fix both problems. The slashdot summary was therefore a bit inaccurate, and reading TFA certainly helps.

Re:To *have* such problems...

[Anonymous Coward]

those of us running our own undersea fiber.

What, don't you? Pfft, luddite.

Re:To *have* such problems...

[totally bogus dude]

Have you measured your actual throughput on the file transfer? It tends to take a crapload of tuning to get anywhere near saturating gigabit, even if you're not using encrypted transfers.

I wrote the bit below which I'll keep because it might be interesting to someone, but dm(Hannu) already mentioned the claw flaw in the logic behind the PP and article summary: if the CPU is the bottleneck, how could adding more threads possibly help?

Just for a laugh I used scp to copy a 512 MB file from my file server to itself, an Athlon 3700+ running at 2.2ghz. I got about 18 megabytes / second out of it. I took a snapshot of top's output right at the end (97% complete) and the CPU usage was as follows:

ssh: 48.6%
sshd: 44.9%
scp: 3.7%
scp: 1.3%
pdflush: 0.7%

So this system was pretty much pegged by this copy operation, and it achieved less than a fifth the capacity of a gigabit network link. Obviously the system is capable of transferring data much faster than this; the source was a RAID-5 set of 5 new 500 GB drives, and the destination was a stripe across two old 40 GB drives. I'd also repeated the experiment a few times (and this was the fastest transfer I got) so it's likely the source file was cached, too.

I do agree that there's probably more interesting and useful things to optimise (and make easy to optimise) than scp's speed, but I know for sure that scp'ing iso images to our ESX servers in a crapload slower than using Veeam's copy utility or the upload facility in the new version of Infrastructure Client (at least I think it's new, never noticed it before).

Re:To *have* such problems...

[sammydee]

This could be very useful for older computers or embedded devices such as routers.

Re:To *have* such problems...

[mikael_j]

A possible problem source here is that you're also doing disk I/O, when transferring data on my home network I've noticed that rsyncing things for redundancy purposes I end up with a lot more CPU usage (even when reading from a RAID5 via a hardware controller) than if I just pump random data from one machine to another. I reommend you try just transferring random data and piping it directly to /dev/null on the receiving machine to see if there's any difference in CPU usage.

/Mikael

Re:To *have* such problems...

[Kyojin]

That's mostly a good idea except for the randomly generated bit. Random number generation can be cpu intensive. A better option might be to randomly generate 500Mb of data in memory and send that to dev/null over whatever link, using the same data each time.

Re:To *have* such problems...

[totally bogus dude]

True enough, but my main point was that getting to actual gigabit speeds in the first place is actually pretty difficult. Plus, I couldn't find an easy way to copy only X amount of "random" data via scp which was the point of the article. Regardless, copying data is rarely if ever a useful thing to do with scp, anyway.

Re:To *have* such problems...

[egede]

The limitations of transfer rates for scp is often the round trip time that consumes time for confirmation of received packages. This is a serious issue for transfers from the Europe to the US West Coast (around 200 ms) or to Australia (around 400 ms). Having several parallel TCP streams can solve this problem and has been in use for many years for transfer of data in High Energy Physics. An example of such a solution is GridFTP http://www.globus.org/toolkit/docs/4.0/data/gridftp/.

Re:To *have* such problems...

[alexhs]

Hello !

My home server/internet gateway is a Pentium MMX at 200MHz, with a 100 Mb/s NIC.
With SCP (default options, server sending), I can transfer at 8Mb/s.
With RCP, at 25 Mb/s

Re:To *have* such problems...

[BitZtream]

This was my first thought as well. I've never had SSH use more than a tiny amount of CPU. As you said, it will be great to have some race conditions in there to make it all that much more secure. $10 says OpenSSH won't be in a big rush to put these patchs in place.

Re:To *have* such problems...

[sydbarrett74]

those of us running our own undersea fiber. What, don't you? Pfft, luddite. Well I had mine but some NSA spy^H^H^H^Hidiot seaman with a wayward anchor took them out.

Re:To *have* such problems...

[Danathar]

PSC = Pittsburgh Supercomputing Center (At Carnegie Mellon).

They are a node on the Teragrid which has throughput over some segments of around 100Gb/s

Re:To *have* such problems...

[Vellmont]

The limitations of transfer rates for scp is often the round trip time that consumes time for confirmation of received packages. This is a serious issue for transfers from the Europe to the US West Coast (around 200 ms) or to Australia (around 400 ms).

Huh. I'm surprised TCP sliding window protocol doesn't take care of that. Shouldn't it account for filling up the pipeline between sender and receiver?

Re:To *have* such problems...

[Andy Dodd]

Older implementations of TCP only allow for a 64 KB window size. (Older meaning "really old" - nearly any implementation in the last decade implements extensions that allow for much larger transmit/receive windows.)

Many apps set fixed window sizes (incl. apparently standard SSH - the webpage implies 64K.)

Linux can "autotune" window sizes, but most OSes don't, hence the need for an app to be able to specify a larger window.

Even with larger window sizes, TCP congestion control starts breaking on networks with high speed and large BDP. For example, even with a BER of something like 1*10^-12, a gigabit connection will drop something like one packet per hour - on a gigabit connection with 400 ms latency, 1 hour is apparently about how long it will take for the congestion control algorithm to even ramp up to full wire speed. One packet drop and all of a sudden TCP throttles way back - hence the large amount of work on advanced congestion control algorithms that handle high BDP networks better. (Such as the current default algo in Linux, CUBIC.)

Using multiple TCP streams works around this problem in a more cross-platform manner as it does not depend on the OS's TCP implementation getting tweaked.

Re:To *have* such problems...

[Andy Dodd]

"if the CPU is the bottleneck, how could adding more threads possibly help?"

Pretty sure the article summary covered this - it is intended for multicore/multiprocessor systems.

i.e. a single CPU is a bottleneck, but multithreading allows the load to be distributed over multiple CPUs, removing the bottleneck a single CPU might provide.

Re:To *have* such problems...

[drinkypoo]

The only time disk access ever causes measurable perturbations in CPU usage, at least for me, is when I'm either doing software RAID (which is handled by your CPU) or USB (which is also handled by your CPU, even in USB2 - don't believe the hype.) The SAME DISK in the SAME ENCLOSURE which is USB2/IEEE1394 will raise my CPU to as much as 12% total (I have a core duo, so that's 24% of a 2.16GHz Core core) just, say, reading 25MB/sec and writing it to the internal disk. Reading 10MB and writing 10MB at the same time to the internal disk (seek!) consumes, well, no CPU whatsoever. If just pulling data from a PATA, SATA, or SCSI disk raises your CPU use, then there is something wrong.

Re:To *have* such problems...

[rapier1]

You may be looking at the wrong process. SCP is basically a wrapper around SSH - all it really does is the file handling and then passes the data to SSH via a pipe. So there will actually be an instance of SSH running every time you run SCP. As such CPU usage of SCP tends to remain quite small but if look for the associated SSH process you'll see that its actually sucking up a lot of compute resources. So you may want to rerun your tests and just look at total load or just run top. You may also want to take a look at the SSHD on the other machine as well.

Re:To *have* such problems...

[rapier1]

> if the CPU is the bottleneck, how could adding more threads possibly help? This is actually a great question. On single core systems its very unlikely that the multi-threading aspect of our patch will be of much use to you. The stock version of SSH is, because of its design, unable to use more than one core regardless of how many cores you actually happen to have. Which means that you could have one core thats pegged by SSH and have other cores that are essentially running idle (if you look at the presentation we go into that after we address with window issues). What we've done is allow SSH to offload the heavy work (the encryption) onto other cores in order to make full use of the CPU resources available.

Re:To *have* such problems...

[Anonymous Coward]

if the CPU is the bottleneck, how could adding more threads possibly help? Modern systems typically contain two-core CPUs. Adding a thread for decoding enables both cores to be utilized.

Re:To *have* such problems...

[archen]

There's no reason you can't use /dev/zero if you're not compressing anything. It should give the same results with less cpu overhead.

Re:To *have* such problems...

[msuarezalvarez]

Do those machines have several cores?

Re:To *have* such problems...

[TemporalBeing]

the crypto can sometimes be the bottleneck instead of the wire speed.

Between two devices on my gigabit home LAN, the CPU barely even registers while SCP'ing a large file (and that with every CPU-expensive protocol option turned on, including compression). What sort of connection do these guys have, that the CPU overhead of en/decryption throttles the transfer???


Coming next week: SSH compromised via a thread injection attack, thanks to a "feature" that only benefits those of us running our own undersea fiber.
A worked on a program that is similar to what the summary describes. For various legacy reasons (legacy code-base) we only supported Triple-DES encryption. But the bottlenecks break down as follows:

1. Network Bandwidth
2. CPU/encryption
3. Disk Access

Network bandwidth is easily over-come to a degree - in the manner the summary describes, it will easily fill the pipe if you can get past the other two issues.

CPU/encryption - this is really more the encryption and how much it affects you will depend on what algorithm you use. For example, our tests with Triple-DES enabled would limit a 100 Mbps pipe to around 30 to 40 Mbps; with encryption disabled we would get around 94 to 96 Mbps. I didn't have a change to try an AES algorithm, but it should give better performance than Triple-DES. Now you don't always have the encryptor on the actual computer - you might have it in-line with your network connection, which will yield higher performance via dedicated encryption hardware, but it will still eat your bandwidth. (I'm aware of in-line encryptors taking 1.5 Mbps links down to around 700 Kbps.)

Disk Access - this is the hardest to overcome as you can really only improve by changing your disk drives to a disk array of some sort (e.g. some sort of striped RAID), or putting in a super-fast connectivity to the disks (e.g. Fibre-Channel), or both. It's still a pretty hard physical limit to break.

Of course, you may still have some issues with Operating System implementations too. Linux tends to do better than Windows, for example - probably due to using better algorithms across the system.

I did manager to test the program I was working on on a gigabit network. We peaked at 500 Mbps for up to 2 seconds, then dropped to under 200 Mbps. The limitation? The hard drives couldn't keep up. I did not have any further opportunity to do more testing for that program.

Re:To *have* such problems...

[Kazoo the Clown]

I wrote the bit below which I'll keep because it might be interesting to someone, but dm(Hannu) already mentioned the claw flaw in the logic behind the PP and article summary: if the CPU is the bottleneck, how could adding more threads possibly help?

It doesn't unless you have multiple cores-- in which case adding more threads is specifically throwing more CPUs at the problem, at least with an OS like Windows which won't automatically distribute a single process across multiple CPUs...

Re:To *have* such problems...

[richterd]

A more lightweight solution that also uses multiple parallel FTP streams and doesn't require the whole GridFTP setup is bbftp http://doc.in2p3.fr/bbftp/. Incidentally, it also uses either SSL for encryption or ssh as a transport; might be interesting to see how multithreaded-ssh + bbftp performs.

Tangentially, at my lab we recently evaluated an anti-P2P "solution" that initially experienced some interesting crashing problems exposed by bbftp. If we get permission, there may be an interesting paper coming out of that evaluation.

Re:To *have* such problems...

[Anonymous Coward]

psc.edu is a joint effort between Pitt and CMU. Its just as much Pitt.edu as it is cmu.edu, damn it!

I want this yesterday (literally)!

[Immerial]

Aw man, if only I had this yesterday! Just had someone download ~6GB worth of video files from one of my machines and just as it shows in the article, throughput was pegged at ~2MB/sec. It took most of a day to send it. This would also kick some serious bootae for uploads to YouTube if they were to ever implement it... for those of us uploading GBs of GBs of stuff.

Re:I want this yesterday (literally)!

[Anonymous Coward]

According to file size and type, it must be Island.Fever.4.PROPER.avi

Re:I want this yesterday (literally)!

[Immerial]

Wow... I know Walter Lewin's lectures are exciting but I think that pushing it ;-)

Oblig applicable Dilbert

[bigmouth_strikes]

Wally: "My proposed work plan for the year is to stress-test our product under severe network conditions. I will accomplish this by downloading large image files from the busiest servers on the net."

(PHB rejects suggestion)
(later)

Wally: "I was this close to making it my job to download naughty pictures."
Dilbert : "It's just as well; I would have had to kill you."

( http://books.google.com/books?id=dCeVfKrZ-3MC&pg=PA77&source=gbs_selected_pages&cad=0_1&sig=xD5tmMhG1RcspLch8gCIJu8ro2U#PPA79,M1 )

Re:Oblig applicable Dilbert

[empaler]

(Scroll up a bit from the link)

Re:Alternative solution for a trusted LAN

[Anonymous Coward]

Or just compile from source and enable the 'none' "cipher".

I surely missed having that option when copying files between hosts on my LAN. I don't need to hide data from myself. If someone else connects and encrypting data is a concern, I'll simply not use the 'none' "cipher".

Re:Alternative solution for a trusted LAN

[MoogMan]

Or use netcat/nc (installed by default on most Linux distros). Server cats it's output directly to a file (or to tar -x). Client grabs it's input from a file.

Server: nc -l 1234 | tar -x
Client: tar -c file_list_here | nc localhost 1234

Re:Alternative solution for a trusted LAN

[Chris Pimlott]

And if you really trust your network, you can recompile SSH with the 'none' cipher enabled, which (as the name implied) uses no encryption on the datastream whatsoever.

Linux kernel version 2.6.17 to 2.6.24.1

[arkarumba]

Preferably, we would like to test it any very high bandwidth systems running Linux kernels version 2.6.17 to 2.6.24.1.

Re:Linux kernel version 2.6.17 to 2.6.24.1

[un1xl0ser]

:-) Mod parent up.

Re:Linux kernel version 2.6.17 to 2.6.24.1

[Anonymous Coward]

You are forgetting that the latest revisions of 2.6.22 and 2.6.23 have the vmsplice fix applied. So you'll need to limit yourself to 2.6.17 to 2.6.21. And not vendor kernels either; Debian has patched 2.6.18 and Ubuntu has patched one (I think it's 2.6.18) and no doubt many other vendors too.

Re:Linux kernel version 2.6.17 to 2.6.24.1

[cnettel]

You are right, vmsplice should reduce the number of separate copy operations and buffers.

Re:Linux kernel version 2.6.17 to 2.6.24.1

[yanyan]

For the benefit of those who did not get the parent's post:

http://it.slashdot.org/article.pl?sid=08/02/10/2011257

bbftp

[Anonymous Coward]

There exists already a multi-threaded & multi-stream file transfer tool, bbftp. It is not a drop-in replacement for scp, as it uses a protocol optimized for bulk files, but doubtless some of its ideas could be backported.

Pretty much totaly incorrect summary

[Eunuchswear]

Almost all the improvements they talk about come from optimising TCP buffer usage. The summary of the fixes:

HPN-13 A la Carte

• Dynamic Windows and None Cipher
  This is a basis of the HPN-SSH patch set. It provides dynamic window in SSH and the ability to switch to a NONE cipher post authentication. Based on the HPN12 v20 patch.
• Threaded CTR cipher mode
  This patch adds threading to the CTR block mode for AES and other supported ciphers. This may allow SSH to make use of multiple cores/cpus during transfers and significantly increase throughput. This patch should be considered experimental at this time.
  
• Peak Throughput
  This patch modifes the progress bar to display the 1 second throughput average. On completion of the transfer it will display the peak throughput through the life of the connection.
• Server Logging
  This patch adds additional logging to the SSHD server including encryption used...

So the main part of the patch set is "It provides dynamic window in SSH and the ability to switch to a NONE cipher post authentication" and the only part that has to do with threading is marked "This patch should be considered experimental at this time".

By the way, does anybody else think "the ability to switch to a NONE cipher post authentication" is pretty dodgy?

Re:Pretty much totaly incorrect summary

[Arimus]

By the way, does anybody else think "the ability to switch to a NONE cipher post authentication" is pretty dodgy?

Not really, for some of the stuff I do via SSH: eg logging into my webhost to untar a patch and apply it the only part of the transaction I want to be secure is my initial password/key-exchange post authentication I really don't give a stuff who sees me type

cd ~/www
tar xvfz ~/patch.tar.gz

or any of the other commands I type in. However it should be down to the admin of the system in the first place to decided whether to allow NONE down-grade (Either on system wide or per user/session basis) and then down to me as a user to decide whether to take advantage.

Re:Pretty much totaly incorrect summary

[Anonymous Coward]

By the way, does anybody else think "the ability to switch to a NONE cipher post authentication" is pretty dodgy?

Not really, for some of the stuff I do via SSH: eg logging into my webhost to untar a patch and apply it the only part of the transaction I want to be secure is my initial password/key-exchange post authentication I really don't give a stuff who sees me type

cd ~/www
tar xvfz ~/patch.tar.gz

or any of the other commands I type in. However it should be down to the admin of the system in the first place to decided whether to allow NONE down-grade (Either on system wide or per user/session basis) and then down to me as a user to decide whether to take advantage.

Everyone who sees you type, can inject package that says that you said rm -rf.

Re:Pretty much totaly incorrect summary

[dissy]

By the way, does anybody else think "the ability to switch to a NONE cipher post authentication" is pretty dodgy? Yes, you almost might as well just use telnet or rlogin.

The only advantage ssh with no cipher is that an attacker will not see your authentication details (password or key) to login to the remote machine.

Unfortunatly just like telnet, using ssh with the none cipher opens the connection up to tcp hijacking and injection of packets, so the attacker doesnt really need your password anymore, they can just execute commands as you on the server once you are authenticated.

My guess is with the dynamic tcp window size patch they use, this might be harder than normal to pull off, but I would still feel more comfortable having that tested by someone more knowledgable before I start using it.

Fortunatly CPU has never been my bottleneck with ssh/scp, as alot of my machines on the lan still use 100mbit, so this isnt exactly targeted at me.

Re:Pretty much totaly incorrect summary

[Atzanteol]

Yes, you almost might as well just use telnet or rlogin.

Sorta. If you're on a private network sending a 4Gig ISO (or other large file/files) why do you need the data to be encrypted? Encrypting credentials is sufficient.

Re:Pretty much totaly incorrect summary

[tbuskey]

By the way, does anybody else think "the ability to switch to a NONE cipher post authentication" is pretty dodgy?

I'd like it when I tunnel a new SSH or scp through another SSH tunnel. We call it a sleeve. I've had to sleeve within a sleeve's sleeve before to get through multiple SSH gateways and firewalls to an inner system. You can tell ssh to use XOR but I'm not sure you can in scp.

Of course, if speed is paramount, you can use netcat inside the sleeve(s) to copy files. No encryption of the netcat, but it's inside an encrypted sleeve so the stream is encrypted.

Re:Pretty much totaly incorrect summary

[dissy]

Sorta. If you're on a private network sending a 4Gig ISO (or other large file/files) why do you need the data to be encrypted? Encrypting credentials is sufficient. Exactly. As long as you can trust (or at worse, assume) your LAN is secure.
Much easier to do on a home network where it is either just you, or you and family.
A rather safe assumption to make if your client machines and 'servers' are secured from eachother, limiting the potential damage from an infected wi^H^H^H client machine.

THe main use I see is that the scp command is damn handy compared to most any other command line method of transfering files. Especially so with RSA/DSA keys.
As far as people that use GUIs go, generally samba (or your native file sharing protocol of choice) is plenty good enough, and it doesnt get easier than drag&drop in a GUI.

Now that would be an interesting benchmark. SCP using the NONE cipher, compared to things like NFS, samba, appletalk (or whatever they use these days as native in OSX) etc, and then speeds for a direct netcat thrown in.
I'd venture a guess that samba would still have more overhead, but I wonder about NFS, and would like to see this compared to netcat speeds.

Re:Pretty much totaly incorrect summary

[rapier1]

Where the performance boost comes from is going to depend on a lot on the characteristics of the network path. If its a high bandwidth delay product path then the majority of the performance increase may very well come from the dynamic window sizing (this is application layer windowing by the way). However, if path has a low BDP and you are CPU bound then either the NONE cipher switch or the multi-threading may provide more of a performance increase than the window sizing. Alternatively, in some high BDP paths the windowing patch may speed up the transfer enough so that it becomes CPU bound at which point the threading and/or NONE cipher switch will allow the user to make full use of the network capacity. One of our test paths is a transatlantic GigE pipe. With the window patch and full encryption we were able to get around 300Mb/s and then we were CPU bound. When we used either the NONE cipher switch or the multi-threaded AES-CTR mode cipher our throughput increased to 700Mb/s.
As for the dodgy aspect of the NONE cipher switching. I'll be the first to admit that its not a perfect solution. The authentication remains fully encrypted and you can't use the NONE switch in an interactive session which obviates some of the problems. However, it still, in some ways, is counter to the idea of SSH which is why we came up with the threaded cipher. If you are willing to accept the NONE cipher then you can use that but if you want full encryption then you can use the threaded AES-CTR mode cipher.

Re:Pretty much totaly incorrect summary

[rapier1]

As a note - while the NONE cipher switch turns off data encryption we do *not* disable the message authentication cipher (MAC). So each data packet is still signed and authenticated. If it detects any in transit modification of the packet the connection is immediately dropped.

Re:Pretty much totaly incorrect summary

[Nahor]

Everyone who sees you type, can inject package that says that you said rm -rf.

From their FAQ:
Additionally, while the data is no longer encrypted each packet is still digitially signed and protected against in transit manipulation of the information.

Re:Pretty much totaly incorrect summary

[Anonymous Coward]

There is really nothing wrong with a NONE chipher like in HPN-SSH. It is never used by default, and if you use it you should be expected too understand the implications.

There are plenty of cases where you transmit completely non-secret data, but still need the control channel authenticated and encrypted.

Re:Pretty much totaly incorrect summary

[ComputerSlicer23]

That way lies madness...

I'm curious if you ever have problems like this:

http://sites.inka.de/~W1011/devel/tcp-tcp.html

Essentially transporting TCP over TCP has serious timeout problems... a small glitch in the outer TCP can cause major hiccups on the inner TCP.

Kirby

Re:Pretty much totaly incorrect summary

[Cerilus]

> By the way, does anybody else think "the ability to switch to a NONE cipher post authentication" is pretty dodgy?

Well, there's a perfectly reasonable explanation why you'd want to do this. Some transmission mediums restrict the use of cryptography. I good example of this is amateur radio. I'd love to use ssh to authenticate to my home server over a radio link (at 2kW!), but without this patch, it's illegal.

Sometimes there's no reason to conceal the content of your communication, but you will want to preserve strong authentication and integrity.

Steve (KI6MBY)

Re:Pretty much totaly incorrect summary

[rb12345]

I'm curious if you ever have problems like this:

http://sites.inka.de/~W1011/devel/tcp-tcp.html

Essentially transporting TCP over TCP has serious timeout problems... a small glitch in the outer TCP can cause major hiccups on the inner TCP.

Your link refers to TCP packets encapsulated within TCP streams, e.g. PPP over TCP. That kind of encapsulation does suffer timeout problems. SSH opens separate TCP connections at both ends of the tunnel, owned by the ssh and sshd processes. It then simply copies the data between the two, over the ssh->sshd link. This way means that you now have three unrelated TCP timeouts - one for the SSH link, and one for each of the two end links.

Re:Pretty much totaly incorrect summary

[Mr Z]

If you're on a private, trusted network and you're using SSH mainly as an RSH replacement, it makes total sense. For example, I don't see a need to actually AES encrypt communication between my computer and my wife's computer on my home's LAN. But, I do scp files between them from time to time.

I could install RSH and friends, but SSH tends to have better error checking (e.g. when wielding globs and such, or when it comes to getting tripped up on noisy login scripts) and is all around nicer.

Re:Pretty much totaly incorrect summary

[ComputerSlicer23]

Sure, except for the tunnel inside a tunnel bit he talked about.

Re:Pretty much totaly incorrect summary

[dlapine]

No, the none cipher is targeted at HPC clusters with private networks- When I want to use ssh as an rsh replacement, and don't need encrypt the same thing 100 times to 100 different machines.

Re:Pretty much totaly incorrect summary

[RichiH]

So you are saying you have a built-in DoS switch? Not saying that a RST can't do the same, but still..

Hardware acceleration

[AceJohnny]

I've been wondering, does there exist hardware accelerators usable by OpenSSL or GnuTLS? I work in embedded systems, and our chip includes a crypto and hash processor. I'm surprised nothing equivalent exists on modern PCs, or have I just not been looking in the right places?

Re:Hardware acceleration

[Anonymous Coward]

hoho

Re:Hardware acceleration

[neumayr]

There were crypto acceleration cards, but I think the market was fairly small. They made sense for sites with lots of https traffic, but nowadays general purpose cpus are blazingly fast compared to back then.
So I guess they disappeared..

Re:Hardware acceleration

[bzzzt]

Those embedded systems usually have slow CPU's which are outperformed by hardware-accelerated encryption boards. Your average desktop CPU running openssl will be a lot faster than most cheap accelerator cards. Most of the time it's cheaper to invest in a faster generic CPU than a piece of custom hardware.

Re:Hardware acceleration

[TeknoHog]

I've been wondering, does there exist hardware accelerators usable by OpenSSL or GnuTLS? I work in embedded systems, and our chip includes a crypto and hash processor. I'm surprised nothing equivalent exists on modern PCs, or have I just not been looking in the right places?

The VIA C7 processor has hardware crypto acceleration (AES and some helper functions) that's supported by OpenSSL out of the box. Applications still require some patching, for example OpenSSH. The reason seems to be that the application has to choose the encryption engine used by OpenSSL.

http://bugs.gentoo.org/show_bug.cgi?id=162967

Re:Hardware acceleration

[Bill Wong]

There is a whole lot of available crypto hardware listed here.
I've used a Hifn Crypto Accelerator a year or three ago. Worked with OpenSSL for the most part.

Re:Hardware acceleration

[htd2]

There are a number of vendors who supply PCI/e/x/etc crypto accelerators. However these are mostly targeted at servers where the overhead of serving up numerous encrypted streams of data is much higher than on a client PC.

The Sun T1 and T2 processors in the T2000 and T5000 also have onchip crypto units 1 on the T2000 and 8 on the T5000 which accelerate OpenSSL traffic by offloading DES, AES, MD5 etc.

Re:Hardware acceleration

[pixr99]

I've been wondering, does there exist hardware accelerators usable by OpenSSL or GnuTLS? I work in embedded systems, and our chip includes a crypto and hash processor. I'm surprised nothing equivalent exists on modern PCs, or have I just not been looking in the right places? Similar features exist, though not on all "modern PCs." VIA's C3 chips have a random number generator. C3 chips with the step 8 or later Nehemiah core actually have a hardware AES implementation. I think the C7 family has these features as well. And then, of course, there's a bunch of Hifn-based hardware that can be attached to a PC. Soekris Engineering has PCI and mini-PCI versions of their Hifn-based crypto boards.

Re:Hardware acceleration

[Jah-Wren Ryel]

Typically the overhead of the memory copy across the PCI bus to the crypto card and back into main memory is higher than just letting the host cpu do the crypto work itself (AES was designed to be very efficient even on slow cpus, far better than DES/3DES).

As others have mentioned, the Via cpus have built-in accelerators which avoid those memory copies

Re:Hardware acceleration

[xehonk]

There are still accelerators in the server market.

But for a typical desktop they're pretty pointless. My amd x2 3800 can scp with about 45MB/s to an equally fast machine. Though netcat is still faster with approx. 57MB/s, those 45MB/s are enough to make me happy.

Re:Hardware acceleration

[Anonymous Coward]

In most desktop scenarios [today] ciphers/hashes are certainly going to be faster than your IDE or PCI bus can cope with [realistically]. So the only thing a cipher could help with is latency. Unless you put it in your flow, e.g. between you and your MAC. Farming data off from PCI [e.g. your harddisk], to a crypto chip, then back over PCI to your NIC isn't going to be any faster than just using the main cpu. At best it lowers the load, but it's really not worth the cost.

For starters, adding crypto makes it harder to export devices. Which adds cost.

Re:Hardware acceleration

[Anonymous Coward]

via c7

Re:Hardware acceleration

[dj245]

Mod parent up. I saw some benchmarks a year or so ago showing a puny little Via processor completing an SSL benchmark 20 times faster (or something equally amazing) than the top end Pentium chip. Hardware acceleration makes all the difference!

Re:Hardware acceleration

[jimicus]

The main reason why it's hard to justify specialised hardware in PCs is that 9 times out of 10, CPU progress means that even if it isn't now, the CPU will be easily fast enough to handle 99% of end-user requirements long before they've made the return on investment on putting the extra hardware on the motherboard.

Re:Hardware acceleration

[Wesley Felter]

I've been wondering, does there exist hardware accelerators usable by OpenSSL or GnuTLS? There's VIA PadLock; too bad you have to buy the slowest processor to get the fastest crypto.

Re:Alternative solution for a trusted LAN

[KiloByte]

Actually, it appears that (at least on Debian) AES is already the default. Selecting 3des gives tremendous slowdown; blowfish is somewhat slower than AES.

Copying 100MB of data over 100mbit ethernet to a P2 350Mhz box (the slowest I got) gives:
* 3des 1.9MB/s
* AES 4.8MB/s
* blowfish 4.4MB/s

sftp and ASCII mode transfers

[Anonymous Coward]

sftp still not have an ASCII transfer mode, unlike the ftp it replaces. What is the deal with this? How much extra code would it take to do this? Of course you can workaround it, but it wastes times and causes confusion and complaints (google sftp and ascii).

Re:sftp and ASCII mode transfers

[raynet]

The lack of ASCII transfer mode is a good thing. A LATIN15 transfer mode might be handy. Less time wasted and less confusion and complaints amongst my clients.

Re:sftp and ASCII mode transfers

[colfer]

WinSCP implements SFTP with ASCII/text transfer. WinSCP uses SFTP by default, and falls back to SCP if SFTP is not available. But even in SFTP-only mode, it does the line ending change for ASCII transfers. Some SFTP clients, such as the version of Filezilla I tried a few years ago, do not support ASCII transfer, do not change the line endings.

Re:sftp and ASCII mode transfers

[Anonymous Coward]

Well lah-dee-dah, Euro person.

Re:sftp and ASCII mode transfers

[raynet]

But I like my umlauts and prefer them to be intact after file upload.

Re:Alternative solution for a trusted LAN

[Diomidis Spinellis]

Nc is useful, but it still involves the overhead of copying the data through it (once at the client and once at the server). Nowadays, in most settings this overhead can be ignored. But, given the fact that a well-behaved application will work with a socket exactly as well as with a pipe or a file descriptor, I thought it would be very elegant to be able to connect two instances of (say) tar through a socket. Hence the implementation of socketpipe. Socketpipe sets up the plumbing and then just waits for the programs to finish.

This is the setup using nc:

tar --pipe--> nc --socket--> nc --pipe--> tar

and this is the setup that socketpipe arranges:

tar --socket--> tar

News just in!

[j.a.mcguire]

Crowds were shocked to discover that multi-threaded software runs faster on a multi-core system, it was hard to contain the excitement over the discovery which could revolutionise software development!

Why not loopback?

[neumayr]

I don't get it, if they need lots of bandwidth to test their scp acceleration code, why can't they do it over the loopback interface?
Is there some limit to that I'm not aware of?

Re:Why not loopback?

[Shakrai]

That wouldn't tell them very much about their TCP changes though. Much better to do the test on a real live network.

Re:Why not loopback?

[Mr Z]

BDP is the bandwidth-delay product. BDP is one of the main things these patches address. Loopback has very, very little delay. You could, I suppose, add artificial delay over loopback, but now you're diverging further from the actual deployment scenario.

The other thing is that when sender and receiver are the same host, you don't engage the full network stack (no ethernet queuing, for example, no dropped packets, etc. etc.), so you don't find out all the curve balls that TCP/IP will throw you.

And yet another thing is that sender and receiver will compete for the same CPUs, and so whatever upper CPU bound you have with separate sender and receiver, you'll be at roughly half that (assuming send and receive are balanced) when both are on the same machine.

--Joe

Re:Why not loopback?

[TheLink]

AFAIK freebsd 4 (and earlier) allows you to add delays and set levels of packet loss.

So all you need are three machines: client, "pipe", server.

Do a netcat or something to see how fast things are without scp.

The trouble is if your Gbps NICs don't actually do Gbps speeds, there are a fair number of those out there that can't sustain 1Gbps. Fortunately nowadays most onboard NICs aren't too crappy.

why look for high bandwidth only ?

[richlv]

it's weird that they look for high bandwidth users only. they could also use low-powered systems to test the approach :)
of course, if they want to test how well it scales, that's a different matter.

Re:why look for high bandwidth only ?

[Mr Z]

Part of the scaling problem is due the amount of buffering relative to the bandwidth-delay product. So really, they could just look for pairs of systems with really, really, high ping times. Deep Space Network anyone?

Comcast

[OglinTatas]

"They are currently looking for potential users with very high bandwidth to test the upper limits of the system."

You comcast users can forget about it, then.

Re:Comcast

[rapier1]

To be honest the ideal test system we are looking for now are 10Gb/s connected multi-core hosts - preferably over a transoceanic or continental path. We're still trying to see how fast we can go.

Re:Alternative solution for a trusted LAN

[houghi]

The situation where this can be usefull will be almost non-existing. The places that could benefit from the increase will most likely have several people working.

That means the better way is to encrypt BY DEFAULT. Security is not so much a technical issue. It is also a social one. Encrypting by default will benefit you in the long run.

This means also sending gpg signed messages by default. Much shorter, beter and more usefull then the legal sh|t they attach now.

Old news?

[Damocles the Elder]

Digging around for the best way to apply the patch without screwing up my portage updates, I came across a request for this to be merged into the portage back in 2005, and is apparently usable with the HPN useflag.

Not that I'm that surprised to see this is old news, since they're apparently on major revision 13...

Re:Alternative solution for a trusted LAN

[dissy]

Or just compile from source and enable the 'none' "cipher".

I surely missed having that option when copying files between hosts on my LAN. I don't need to hide data from myself. If someone else connects and encrypting data is a concern, I'll simply not use the 'none' "cipher". -1 redundant, -1 fail at slashdot

from the linked article:

Dynamic Windows and None Cipher
This is a basis of the HPN-SSH patch set. It provides dynamic window in SSH and the ability to switch to a NONE cipher post authentication. Based on the HPN12 v20 patch.

Re:Alternative solution for a trusted LAN

[Anonymous Coward]

It can also be done in another way, using standard ssh (so it can be used on a lan you don't trust):

tar zcf - * | ssh remotehost tar zxvf - -C /path/to/remotedir

You also get compression on the fly, which helps a bit; replace ssh with rsh if you wish.
It also works out of the box across different *nix variants: no problem if you don't have socketpipe on the receiving end (i'm assuming it's less widely available tha ssh).

Regards,
Alberto.

Re:Alternative solution for a trusted LAN

[Neil Watson]

Actually, it depends upon the SSH protocol. Both Debian and Cygwin have this to say:

        -c cipher_spec
                          Selects the cipher specification for encrypting the session.

                          Protocol version 1 allows specification of a single cipher. The
                          supported values are "3des", "blowfish", and
                          "des". 3des (triple-des) is an encrypt-decrypt-encrypt
                          triple with three different keys. It is believed to be secure.
                          blowfish is a fast block cipher; it appears very secure and is
                          much faster than 3des. des is only supported in the ssh client
                          for interoperability with legacy protocol 1 implementations that
                          do not support the 3des cipher. Its use is strongly
                          discouraged due to cryptographic weaknesses. The default
                          is "3des".

                          For protocol version 2, cipher_spec is a comma-separated list of
                          ciphers listed in order of preference. The supported ciphers are:
                          3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr,
                          aes192-ctr, aes256-ctr, arc
                          four128, arcfour256, arcfour, blowfish-cbc, and cast128-cbc. The default is:

                                      aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
                                      arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
                                      aes192-ctr,aes256-ctr

Multithreading waaay to go...

[Crass Spektakel]

Today you can buy a machine with eight cores, 8gb memory and 1tb harddrive for less than 2000. And most software will only use one core and a maximum of 2gb memory.

WE NEED MULTITHREADING NOW BIG AND EVERYWHERE.

Multithreading is maybe the biggest change in software development. In contrast to advanced command sets like MMX, SSE and so on it is not about some peep hole optimization, about replacing a bunch of x86_32 commands with some SSE commands, it is about changing the whole approach, finding new algorithms and redevelop much if not all software we are used to work with.

And we are lightyears away from using appropiate software on on todays systems.

See compressors: Most can't multithread at all. Those who can have more issues than the SCO buisness plan, eg reduced efficency, scale very bad, can't accept input from stdio or can't output on stdout. Basically compression should be a good starting point but even here todays solutions are incredible far behind the hardware.

Also consider network communication, graphical interfaces, games, printing, non-enterprise realtime presentation and so on and so forth.

The revolution is NOT here. People aren't even talking about it.

Re:Multithreading waaay to go...

[Neil Hodges]

Noting the 2 GB per-application limit: we need more x86_64-native applications. On Windows, it's an issue because nothing can be recompiled to fix that, especially third-party drivers. They're often restricted to PAE (or not even), which allows the more than 4 GB of RAM, but still gives only that amount to each application.

On 64-bit Linux, it's usually a matter of recompiling the software packages and improving coding semantics. Most of the drivers are in the kernel, and nVidia's kind enough to provide us with a DRI/XV/composite driver for 64-bit kernels (unlike fglrx from ATi/AMD), and the common Intel cards are supported by an open source driver anyway. Heck, I even have 32-bit Flash working in 64-bit Firefox, though not Opera and Konqueror. Hopefully Gnash will continue improving to where I can switch to it soon, or Adobe will finally get their 64-bit implementation out.

FUNNY?! That's not funny, try for TRUE

[empaler]

Srsly. I'm gonna be a father this year. DO NOT WANT!

Re:FUNNY?! That's not funny, try for TRUE

[Tolkien]

After someone says something like that, I can only feel bad for the baby. :|

Re:FUNNY?! That's not funny, try for TRUE

[Anonymous Coward]

I won't lie to you -- being a parent is no laughing matter. It is a ton of work. It can be amazingly stressful and expensive. I've been through periods that I look back on now and wonder how the hell I managed to pull through without going completely insane. But if you ask me, the rewards outweigh the difficulties ten to one.

When your child first looks up at your face and you see actual recognition in her eyes... when you see all the blocks fall into place as she figures out how to do something for the first time... look, I know it sounds really sappy and smarmy, but seriously (srsly) it is absolutely indescribable. This thing started out as a bit of genetic code from two people, and now it is actually self-aware and sentient. How cool is that? What geek can't be astonished at these emergent properties, derived from a program more complicated than you can possibly imagine -- a program that has spontaneously evolved over time?

And you get to see her mental map evolve. You watch branches get added to her decision tree. You observe as she learns how to acquire information, process it, and decide how to act upon it. And all the while, you mold her view of the world based on your interactions with her. I don't know about you, but I find that not only fascinating, but incredibly rewarding.

Before my daughter was born, I was terrified too, and somebody had said these things to me, I would've said, "Yeah, okay, I'm sure it's great and all, but I'm sure you're exaggerating somewhat." That's because there is something that happens to you when it's your kid. There's some very ancient, very basic code that gets turned on in your brain that says "this life is your responsibility, and you must do everything you can to ensure its safety, survival, and growth". I can't explain it because I honestly believe it's something buried deep beneath the conscious mind.

Whatever the case, if you honestly don't want the baby, for it's sake, put it up for adoption. Don't make it live a life with a father who doesn't care for it. I'm being absolutely serious here. Find a loving couple who are unable to have kids of their own.

(Posting AC because this is way offtopic, and because there are a lot of single, selfish, bitter child-haters out there with mod points to burn... but I had to say something.)

Re:FUNNY?! That's not funny, try for TRUE

[TheLink]

I wonder how many people are doing the following approach:

Get the girl pregnant, get married, get to know the girl.

The "conventional" approach is the other way around of course :).

Of course for us slashdotters there's step 0) - find a girl...

Re:FUNNY?! That's not funny, try for TRUE

[Anonymous Coward]

Sure, it's amazing during the formative years... but later on down the line, when that nurturing environment that made your child into a healthy, independent, and intelligent adult lets him come to his own conclusions that he should vehemently support that which you equally vehemently oppose. When the loving adoration for daddy turns into a sort of pitiful contempt because of some religious, philosophical, or political variable.

Can't see how anyone could feel like anything but a failure in that spot.

Re:FUNNY?! That's not funny, try for TRUE

[corifornia2]

I go with this method:

• Get the girl pregnant
• Kick her down some stairs
• repeat

Re:FUNNY?! That's not funny, try for TRUE

[Anonymous Coward]

Touché. And yeah, I don't know how I'll feel when and if that day comes. But I'd like to think that I would rather be happy that my child has learned to make her own decisions than crushed that she doesn't share the exact same opinions as myself. (Or, for that matter, her mother.)

Example: my dad was rather bigoted towards homosexuals, had a dim view of Japan (since his dad fought in WW2), adored model railroading, and had rather conservative views regarding the control and censorship of the Internet. I have openly gay friends, like some anime, never got really into model railroading, and am extremely liberal when it comes to the Internet. I don't think he ever felt like a failure because I didn't agree with him on every issue, nor did I ever view him with contempt because his opinions differed from my own. Quite the opposite -- we had some really good debates on many issues, and often one of us managed to get the other to understand his viewpoint, if not agree with it.

Re:FUNNY?! That's not funny, try for TRUE

[sgbett]

There's also other geek parents out there that know exactly where you are coming from. well said.

Re:FUNNY?! That's not funny, try for TRUE

[Anonymous Coward]

I tried that a few times, then i figured out that cleaning stairs from bloodstains is quite expensive.

Re:FUNNY?! That's not funny, try for TRUE

[DimmO]

Ever heard of contraception?

Re:FUNNY?! That's not funny, try for TRUE

[empaler]

Yeah. Turns out 0.8% risk of pregnancy isn't as small as I thought it was.

Re:FUNNY?! That's not funny, try for TRUE

[empaler]

No worries, she'll be right.

Re:FUNNY?! That's not funny, try for TRUE

[empaler]

Thank you for your very well-written reply, but I wasn't actually being all that serious. (No, the pregnancy was unplanned, and I am actually opposed to the idea of becoming a parent at my current place in life; however, after talking this over with the only other person to have any say in this (the mother), I've decided to go with it).

Don't mistake my badly crafted joke for being completely ignorant of what's ahead of me; before the final decision came, I had consulted with friends who are also parents (carefully not discussing this with any of my single, singlemindedly free-roaming friends), and I am in no way in doubt that I will make this child a net benefit for the human race. There are simply too many rotten parents, spoilt children, miserable families and bad genes in the world for me to actually fail in that respect.
Plus, living in Denmark*, the baby will have pretty good odds for a good life, my involvement notwithstanding.

I am going to have a lot of fun making tech projects for my little one when that time comes, including audio books with his/her favourite bed time stories, video diaries of how the child evolves, and of course, teaching how to solder before the age of 5. How I survived until 15 without that knowledge eludes me to this day.

*: Studies have shown that there is a tie for Country With Best Quality of Life; Denmark and Iceland. I've been to Iceland, and it smelled like rotten eggs. Denmark takes the lead.

Re:FUNNY?! That's not funny, try for TRUE

[empaler]

Been with this one for 3½ years - I usually wear a condom until I at least find out whether they have a name*. Not that their names really matter, though. I usually get around to asking what it is within a week or so.

*: Wouldn't want to accidentally have sex with a clone or a robot, unprotected

Re:FUNNY?! That's not funny, try for TRUE

[Anonymous Coward]

That sounds great! Just remember the cardinal rule for making toys (tech or otherwise) for a baby: how will it handle being chewed on?

Re:FUNNY?! That's not funny, try for TRUE

[scotch]

Your child will hate homosexuals and love model railroading. These things skip a generation.

Re:FUNNY?! That's not funny, try for TRUE

[Anonymous Coward]

....says the man named "e(/i)mpaler"

Re:Alternative solution for a trusted LAN

[HAKdragon]

I may be speaking out of ignorance, but doesn't that defeat the point of SSH?

Re:Alternative solution for a trusted LAN

[angus_rg]

There is also no security in socketpipes, so it isn't much different from using FTP from a security standpoint.

I think the point of this article is to improve a "secure" method of data transfer by making the way it deals with encryption better. Even using weaker encryption methods, you still have this problem.

I think the idea makes perfect sense and probably could improve file transfer dramatically. Realistically, it is just a software encryption accelerator. If they could implement it in the NIC card, that would be a better solution, but probably a headache from a OS programming/encryption update standpoint.

Can't we all just get along?

[piojo]

Okay, it's very simple.

Encrypted and tunneled over SSH, rsync is spawned by a login shell at the other side:
rsync /some/path myhost.com:my/directory

Not encrypted, rsyncs daemon must be running at other end:
rsync /some/path rsync://myhost.com/my/directory OR
rsync /some/path myhost.com::my/directory

Re:Alternative solution for a trusted LAN

[drinkypoo]

The "point" is whatever you want it to be. When copying files on my LAN, I still want secure password exchange, but I could give a shit about the data. I don't know if it's actually possible to achieve this (encrypt only for exchange) with ssh or not, though.

You can watch the presentation here

[Anonymous Coward]

High Performance Bulk Data Transfers Using the SSH Protocol

Re:Alternative solution for a trusted LAN

[rapier1]

If you just recompile the stock SSH with the NONE cipher enabled the entire process happens in clear. This includes the authentication. You can test this by capturing the network activity with TCP dump (use a full snaplen) and looking at the results. You'll find that your key/password/whatever is in plaintext. The NONE cipher switch available in HPN-SSH is different in that the authentication *is* encrypted and the NONE cipher is only used *after* the user is authenticated.

Are threading and security mutually exclusive?

[emil]

AFAIK, the OpenBSD kernel has adopted the SMP approach of the Linux 2.2 kernel (i.e. one great big kernel lock), and threads are implemented in a userland library. I assume that there will be less of a performance benefit on OpenBSD.

Given this stance, is it very likely that either the core maintainers, or the maintainers for the portable releases, will integrate this code?

Given the danger of protecting critical sections of code from race conditions and other exploits, should we keep things simple?

p.s. Is there any performance loss when using the privilege separation multi-process model? Could this threading approach from the article be reworked to use standard SysV IPC to make better use of these processes?

this is news?

[cats2ndlife]

I don't know about you but I've been using the HPN variant of OpenSSH from MacPorts for a couple of years now. Don't know why this is news.

Re:this is news?

[rapier1]

The earlier versions did *not* include the multi-threaded cipher. If you are using one of the older version of HPN-SSH (HPN12 and below) you're limited to one core.

No free lunch.

[UseTheSource]

Multithreading is maybe the biggest change in software development. In contrast to advanced command sets like MMX, SSE and so on it is not about some peep hole optimization, about replacing a bunch of x86_32 commands with some SSE commands, it is about changing the whole approach, finding new algorithms and redevelop much if not all software we are used to work with.

This is a good point, although multithreading is not a new thing. It does often take a complete rework of existing algorithms in order to leverage the benefits of parallelism, though. Just keep in mind that there's no free lunch. Just because you throw, for example, twice the processor resources at a problem, does not mean you'll get twice the speedup. You can approach that (but almost never reach it), as contention for shared resources, dependence on results produced by other code, etc. reduces these improvements somewhat. It all depends on how much of the code needs to run serially, and how much is independent of other things and can run in parallel. In the case of SSH, we're talking about using multithreading for buffering completely independent data sets, so the improvement is good. In general though, you still do reap the benefits of being able to share code pages which may offer speed and memory footprint advantages over simple copy-on-write, multi-process programming.

rsync.net offers bandwidth, testbed, and support

[kozubik]

rsync.net would be happy to offer bandwidth and support to the authors - please contact info@rsync.net if these resources are still needed for your project. Much of what we do is based on SCP, so we were happy to see this announcement.

Re:Alternative solution for a trusted LAN

[forkazoo]

I may be speaking out of ignorance, but doesn't that defeat the point of SSH?

SSH is one of those uberutilities that has a surprising amount of usefulness once you dig a bit. Sure, secure telnet functionality is great, and I use it a lot. But, I still use ssh on my own LAN where I don't really care about security. I use sshfs because it is easier and more convenient for me than bothering with Samba. SCP/SFTP to avoid bothering with ftp. I use it for forwarding ports between various machines, and I use it for forwarding X sessions. There are surely ways to accomplish all the same stuff that I use ssh (and the closely related stuff like scp) for without using ssh, but I'd just rather not bother about it.

Defeating the point of ssh is like defeating the point of a morning star. No matter how dull you make the point, the other 99 of them will still clobber you in the face.

Re:Alternative solution for a trusted LAN

[MadMidnightBomber]

That's protocol v. 1. Protocol version 2, which we should all be using, will try aes128-cbc first off, and that should be one of the fastest ciphers available.
$ cat /etc/ssh/sshd_config | grep Pro
Protocol 2

SCP really

[MSDos-486]

SCP is OK for one or two files, but isn't there something better for moving large files in a secure way.

This is coming from a person who gets made at people for using FTP (or worse email) on there student accounts for file transfer when its possible to use SMB ( and I think even NFS) and mount them directly.

Re:SCP really

[Culture20]

Yes, there is:
http://linux.slashdot.org/comments.pl?sid=451874&cid=22406684
or rsync over ssh, etc etc.

Some comments from one of the authors

[rapier1]

First off, thank you for taking the time to read down this far. There have been some very interesting and useful comments so far. Second, I need to point out that both Ben Bennett of PSC and Michael Stevens of CMU were instrumental in getting this patch written. Without them there would be no HPN-SSH patch. I also highly suggest that interested people go to the http://www.psc.edu/networking/projects/hpn-ssh and read about what we've done. There is a lot of good material in the papers and presentations section as well as the FAQ.

A couple notes about the multi-threading: The main goal was to allow SSH to make use of multiple processing cores. The stock OpenSSH is, by design, limited to using one core. As such a user can encounter situations where they have more network capacity and more compute capacity but will be unable to exploit them. The goal of this patch was to allow users to make full use of the resources available too them. The upshot of this is that its best suited for high performance network and compute environments (The HPN in HPN-SSH stands for High Performance Networking). This doesn't mean it won't be useful to home users - only that they might not see the dramatic performance gains someone in a higher capacity environment might see. Its really going to depend on the specifics of their environment.
Based on our research we decided the most effective way to do this would be to make the AES-CTR mode cipher multi-threaded. The CTR mode is well suited to threading because there is no inter block dependency and, even better, the resulting cypher stream is indistinguishable from a single threaded CTR mode cypher stream. As a result, we retain full compatibility with other implementations of SSH - you don't need to have HPN-SSH on both sides of the connection. Of course, you won't see the same improvements unless you do.
We still see this as somewhat experimental because we've not yet implemented a way to allow users to choose between a single threaded AES-CTR and multi-threaded AES-CTR mode. As such users on single core machines - if using AES-CTR may see a decrease in performance. We suggest those users just make use of the AES-CBC mode instead (which is the default anyway). Also, you need to be able to support posix threads.
Future work will involve pipelining the MAC routine and that should provide us with another 30% or so improvement in throughput.

Also, its important to keep in mind that these improvements are *not* just for SCP but for SSH as a whole. People using HPN-SSH as a transport mechanism for rsync, tunnels, pipes, and so forth may also see considerable performance improvements. Additionally, the windowing patches don't necessarily require HPN-SSH to be installed on both ends of the connection. As long as the patch is installed on the receiving side (the data sink) you may (assuming you were previously window limited) see a performance gain.

We welcome any comments, suggests, ideas, or problem reports you might have regarding the HPN-SSH patch. Go the website mentioned above and use the email address there to get in touch with us. This is a work in progress and we are doing what we can to enable line rate easy to use fully encrypted communications. We've a lot more to do but I hope what we've done so far is of use and value to the community.

Comment removed

[account_deleted]

Comment removed based on user account deletion

This is old news

[Anonymous Coward]

I found out about this and the PSC patch about 8 months ago when I setup a 20GB Infiniband network in our data center.

Good for virtual machines

[spitzcor]

This technique would be great for virtual machine instances hosted in simulation environments (eg. bochs).

Re:Alternative solution for a trusted LAN

[fm6]

In other words, by default you'll get aes, unless you happen to connect to a server that doesn't support it (unlikely). So the question is, which of these is fastest?

Comrade

[popejeremy]

In Soviet Russia, SSH Multi-Threads You.

Mod parent up

[mccrew]

Sorry, I don't have mod points today to do it myself. Recommend +1 Interesting or +1 Insightful.

Re:Alternative solution for a trusted LAN

[algae]

I use sshfs because it is easier and more convenient for me than bothering with Samba.

I've heard more and more people saying this lately. Why not use NFS? It saves the crypto overhead, is massively easy to set up on both the client and server side, etc etc. Agree about Samba though - using it for *nix-to-*nix shares is idiotic.

Re:Alternative solution for a trusted LAN

[mikael_j]

The downside to NFS is of course that you pretty much need network-wide logins (via Kerberos or some other method) to keep your UID the same on all machines, you can always do it the ugly way and simply set the UIDs on the NFS partition to whatever UID you have on the machine you normally access it from but once you have a few different machines and users it just becomes easier to set up Kerberos...

/Mikael (uses NFS because it doesn't act up nearly as often as Samba)

Hardware is cheap

[Anonymous Coward]

I believe heavy use of SSE3/SSE4 instructions can provide much better performance than going multi-threaded. Multi-threaded is only easier.

Re:Hardware is cheap

[Kalak]

Multi-threading cross platform (assuming well written). Not everything is x86.

Re: Innovation

[dave87656]

I have a simple fileserver and transfer system I wrote in java to facilitate transferring files and information between hosts in our application. It also allowed me to take specific acts on certain types of files (like expanding zip files or installing jar files for our application).

Writing it multithreaded seemed obvious. But when I look at all the insane patents that are being granted, as crazy as it sounds, someone could actually patent a "file server/transfer system using multiple threads to enable simultaneous transfers and non-file information as well as intelligent handling of specific file types."

Any normal person would say, "Hey ftp does most of that already" but the way the patent office works today you could still get a patent on it.

Reminds me of...

[Atti K.]

... AST: Multi-threaded SSH/SCP "is only a performance hack". :)

Great. Now support softlinks!

[RichiH]

Please, in the name of all that is holy (relative to $deity of your choice), make that version detect and handle softlinks correctly!

Because adding complexity...

[NateTech]

... to anything designed to secure ALWAYS makes it more secure, historically.

I think I'll wait for version 2, or 3... maybe 10.