openssh

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

openssh

Gregory Edigarov-5
Hello,

Just out for curiosity.
what is the fastest and lightest in cpu terms algorithm in ssh?

--
With best regards,
          Gregory Edigarov

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Nick Holland
On 07/01/14 07:00, Gregory Edigarov wrote:
> Hello,
>
> Just out for curiosity.
> what is the fastest and lightest in cpu terms algorithm in ssh?

As someone who has worked with lots of really old and weak processors
(and still used the defaults)...I must ask, why?  If this matters to
you, I'd suggest getting a better computer, not dumbing-down SSH.  Yes,
using ssh on a 25mhz sparc is annoying, but then, so is almost
everything else you do on those machines.  A 20% change one way or
another won't change the annoying factor enough to worry about.

And maybe more important: why aren't you just testing what YOU care
about on YOUR system and answering your own question?  I suspect you may
see different answers on different processors and different tasks.
I.e., what matters? connection time?  throughput?  On the client or server?

And if you have difficulty answering, maybe the answer is "doesn't
really matter, just use the defaults".

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Gregory Edigarov-5
On 07/01/2014 02:20 PM, Nick Holland wrote:

> On 07/01/14 07:00, Gregory Edigarov wrote:
>> Hello,
>>
>> Just out for curiosity.
>> what is the fastest and lightest in cpu terms algorithm in ssh?
> As someone who has worked with lots of really old and weak processors
> (and still used the defaults)...I must ask, why?  If this matters to
> you, I'd suggest getting a better computer, not dumbing-down SSH.  Yes,
> using ssh on a 25mhz sparc is annoying, but then, so is almost
> everything else you do on those machines.  A 20% change one way or
> another won't change the annoying factor enough to worry about.
>
> And maybe more important: why aren't you just testing what YOU care
> about on YOUR system and answering your own question?  I suspect you may
> see different answers on different processors and different tasks.
> I.e., what matters? connection time?  throughput?  On the client or server?
>
> And if you have difficulty answering, maybe the answer is "doesn't
> really matter, just use the defaults".
>
> Nick.
>
because I need to scp some 90-100G  of data from a VERY busy server over
internet on a regular basis and I don't
want scp eat any cpu at all, which in case of encryption is unavoidable).

then, in the middle I have a firewall, that is out of my control, only
allowing connections to 22 port to that server.

Hope my explanation is enough

--
With best regards,
          Gregory Edigarov

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Nick Holland
On 07/02/14 09:08, Gregory Edigarov wrote:

> On 07/01/2014 02:20 PM, Nick Holland wrote:
>> On 07/01/14 07:00, Gregory Edigarov wrote:
>>> Hello,
>>>
>>> Just out for curiosity.
>>> what is the fastest and lightest in cpu terms algorithm in ssh?
>> As someone who has worked with lots of really old and weak processors
>> (and still used the defaults)...I must ask, why?  If this matters to
>> you, I'd suggest getting a better computer, not dumbing-down SSH.  Yes,
>> using ssh on a 25mhz sparc is annoying, but then, so is almost
>> everything else you do on those machines.  A 20% change one way or
>> another won't change the annoying factor enough to worry about.
>>
>> And maybe more important: why aren't you just testing what YOU care
>> about on YOUR system and answering your own question?  I suspect you may
>> see different answers on different processors and different tasks.
>> I.e., what matters? connection time?  throughput?  On the client or server?
>>
>> And if you have difficulty answering, maybe the answer is "doesn't
>> really matter, just use the defaults".
>>
>> Nick.
>>
> because I need to scp some 90-100G  of data from a VERY busy server over
> internet on a regular basis and I don't
> want scp eat any cpu at all, which in case of encryption is unavoidable).
>
> then, in the middle I have a firewall, that is out of my control, only
> allowing connections to 22 port to that server.
>
> Hope my explanation is enough

not really, but regardless, YOU still need to do experiments on YOUR
systems.  And I still think fiddling with the encryption knob is the
wrong knob.  Will it change something?  Sure.  Not much, however.

What is busy?  if "busy" is CPU, nice(1) is your friend.  if busy is
disk, chewing some CPU or even rate limiting may be your friend.  If you
are generating that much new data regularly, you may well have more of a
disk issue than a CPU issue.  If it isn't all new data, look at rsync --
more cpu for less disk and network I/O.

Try compression on vs. off (the results of this are usually easier to
explain after the fact than to predict before.  Shouldn't be the case, I
know, but I've bet wrong too many times).

Fiddle with the rate limiting of scp.  Note that the number you specify
is not terribly absolute -- don't take your available bandwidth and
claim 80% and think magic will happen, you will have to experiement with
values, and leave it sit for a while to let the buffers do their thing.

Then of course, there's the "if you don't like the answers, change the
question" strategy -- drop another machine behind the firewall with a
lower impact way of transfering data -- NFS? FTP?  You are again going
to have to experiement -- then SCP off that machine instead of your
overloaded box.  If the data is logs, you probably want to be syslogging
to another box anyway.

Some time back, TedU@ wrote a nifty little programlette he called
"disknice" -- google for that, you'll find it.  It yanks the program you
have it running away from the CPU (and thus, disk, etc.) periodically,
letting other tasks have at it.  I use it to back up some data from my
laptop's disk to a SD card on boot with rsync, before, it killed the
system performance until it was done.  Now it takes longer, but I don't
feel it happening.  Maybe this helps you in some way.


Nick.

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Gregory Edigarov-5
On 07/02/2014 04:40 PM, Nick Holland wrote:

> On 07/02/14 09:08, Gregory Edigarov wrote:
>> On 07/01/2014 02:20 PM, Nick Holland wrote:
>>> On 07/01/14 07:00, Gregory Edigarov wrote:
>>>> Hello,
>>>>
>>>> Just out for curiosity.
>>>> what is the fastest and lightest in cpu terms algorithm in ssh?
>>> As someone who has worked with lots of really old and weak processors
>>> (and still used the defaults)...I must ask, why?  If this matters to
>>> you, I'd suggest getting a better computer, not dumbing-down SSH.  Yes,
>>> using ssh on a 25mhz sparc is annoying, but then, so is almost
>>> everything else you do on those machines.  A 20% change one way or
>>> another won't change the annoying factor enough to worry about.
>>>
>>> And maybe more important: why aren't you just testing what YOU care
>>> about on YOUR system and answering your own question?  I suspect you may
>>> see different answers on different processors and different tasks.
>>> I.e., what matters? connection time?  throughput?  On the client or server?
>>>
>>> And if you have difficulty answering, maybe the answer is "doesn't
>>> really matter, just use the defaults".
>>>
>>> Nick.
>>>
>> because I need to scp some 90-100G  of data from a VERY busy server over
>> internet on a regular basis and I don't
>> want scp eat any cpu at all, which in case of encryption is unavoidable).
>>
>> then, in the middle I have a firewall, that is out of my control, only
>> allowing connections to 22 port to that server.
>>
>> Hope my explanation is enough
> not really, but regardless, YOU still need to do experiments on YOUR
> systems.  And I still think fiddling with the encryption knob is the
> wrong knob.  Will it change something?  Sure.  Not much, however.
>
> What is busy?  if "busy" is CPU, nice(1) is your friend.  if busy is
> disk, chewing some CPU or even rate limiting may be your friend.  If you
> are generating that much new data regularly, you may well have more of a
> disk issue than a CPU issue.  If it isn't all new data, look at rsync --
> more cpu for less disk and network I/O.
>
> Try compression on vs. off (the results of this are usually easier to
> explain after the fact than to predict before.  Shouldn't be the case, I
> know, but I've bet wrong too many times).
>
> Fiddle with the rate limiting of scp.  Note that the number you specify
> is not terribly absolute -- don't take your available bandwidth and
> claim 80% and think magic will happen, you will have to experiement with
> values, and leave it sit for a while to let the buffers do their thing.
>
> Then of course, there's the "if you don't like the answers, change the
> question" strategy -- drop another machine behind the firewall with a
> lower impact way of transfering data -- NFS? FTP?  You are again going
> to have to experiement -- then SCP off that machine instead of your
> overloaded box.  If the data is logs, you probably want to be syslogging
> to another box anyway.
>
> Some time back, TedU@ wrote a nifty little programlette he called
> "disknice" -- google for that, you'll find it.  It yanks the program you
> have it running away from the CPU (and thus, disk, etc.) periodically,
> letting other tasks have at it.  I use it to back up some data from my
> laptop's disk to a SD card on boot with rsync, before, it killed the
> system performance until it was done.  Now it takes longer, but I don't
> feel it happening.  Maybe this helps you in some way.
Thanks for the insight NIck. I will seriously think about second machine
approach.
The data I need to copy are in a way something like logs, although they
are coming
from some technological equipment.

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Mihai Popescu-3
In reply to this post by Gregory Edigarov-5
> because I need to scp some 90-100G  of data from a VERY busy server over
> internet on a regular basis and I don't
> want scp eat any cpu at all, which in case of encryption is unavoidable).

Better buy a hardisk, copy your data and mail it abroad. Seriously.

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: openssh

Kevin Chadwick-2
previously on this list Mihai Popescu contributed:

> > because I need to scp some 90-100G  of data from a VERY busy server over
> > internet on a regular basis and I don't
> > want scp eat any cpu at all, which in case of encryption is unavoidable).

If you have a fairly new OpenSSH at each end then I would investigate
ed25519

--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Henning Brauer-4
In reply to this post by Mihai Popescu-3
* Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
> Better buy a hardisk, copy your data and mail it abroad. Seriously.

A truck full of harddisks is a transport link with fantastic bandwidth.
Latency kinda sucks, tho.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Gilles Chehade-7
On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
> * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
> > Better buy a hardisk, copy your data and mail it abroad. Seriously.
>
> A truck full of harddisks is a transport link with fantastic bandwidth.
> Latency kinda sucks, tho.
>

Sadly, French researchers have found _at least_ one way to DDoS
this transport and make it unusable with very few resources:

     http://french.about.com/od/vocabulary/a/operationescargot.htm

--
Gilles Chehade

https://www.poolp.org                                          @poolpOrg

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Peter Nicolai Mathias Hansteen
In reply to this post by Henning Brauer-4
On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
> * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
> > Better buy a hardisk, copy your data and mail it abroad. Seriously.
>
> A truck full of harddisks is a transport link with fantastic bandwidth.
> Latency kinda sucks, tho.

And if the hard disks are small enough, you can attach them to pigeons, or swallows, even! (African or European)

- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Damien Miller
In reply to this post by Gregory Edigarov-5
On Tue, 1 Jul 2014, Gregory Edigarov wrote:

> Hello,
>
> Just out for curiosity.
> what is the fastest and lightest in cpu terms algorithm in ssh?

In recent OpenSSH, [hidden email] is what you want.

-d

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Dennis Davis-3
In reply to this post by Peter Nicolai Mathias Hansteen
On Thu, 3 Jul 2014, Peter N. M. Hansteen wrote:

> From: Peter N. M. Hansteen <[hidden email]>
> To: [hidden email]
> Date: Thu, 3 Jul 2014 09:41:12
> Subject: Re: openssh
>
> On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
> > * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
> > > Better buy a hardisk, copy your data and mail it
> > > abroad. Seriously.
> >
> > A truck full of harddisks is a transport link with fantastic
> > bandwidth.  Latency kinda sucks, tho.
>
> And if the hard disks are small enough, you can attach them to
> pigeons, or swallows, even! (African or European)

Sounds to me like this means that RFC1149[1] should be updated.
Technology has improved somewhat since this RFC was written.

[1] http://tools.ietf.org/html/rfc1149
--
Dennis Davis <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Gilles Cafedjian
Le 03/07/2014 15:17, Dennis Davis a écrit :

> On Thu, 3 Jul 2014, Peter N. M. Hansteen wrote:
>
>> From: Peter N. M. Hansteen <[hidden email]>
>> To: [hidden email]
>> Date: Thu, 3 Jul 2014 09:41:12
>> Subject: Re: openssh
>>
>> On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
>>> * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
>>>> Better buy a hardisk, copy your data and mail it
>>>> abroad. Seriously.
>>> A truck full of harddisks is a transport link with fantastic
>>> bandwidth.  Latency kinda sucks, tho.
>> And if the hard disks are small enough, you can attach them to
>> pigeons, or swallows, even! (African or European)
> Sounds to me like this means that RFC1149[1] should be updated.
> Technology has improved somewhat since this RFC was written.
>
> [1] http://tools.ietf.org/html/rfc1149
It was:
https://tools.ietf.org/html/rfc2549

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Dennis Davis-3
On Thu, 3 Jul 2014, Blaise Hizded wrote:

> From: Blaise Hizded <[hidden email]>
> To: [hidden email]
> Date: Thu, 3 Jul 2014 14:41:10
> Subject: Re: openssh
>
> Le 03/07/2014 15:17, Dennis Davis a écrit :
> > On Thu, 3 Jul 2014, Peter N. M. Hansteen wrote:
> >
> >> From: Peter N. M. Hansteen <[hidden email]>
> >> To: [hidden email]
> >> Date: Thu, 3 Jul 2014 09:41:12
> >> Subject: Re: openssh
> >>
> >> On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
> >>> * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
> >>>> Better buy a hardisk, copy your data and mail it
> >>>> abroad. Seriously.
> >>> A truck full of harddisks is a transport link with fantastic
> >>> bandwidth.  Latency kinda sucks, tho.
> >> And if the hard disks are small enough, you can attach them to
> >> pigeons, or swallows, even! (African or European)
> > Sounds to me like this means that RFC1149[1] should be updated.
> > Technology has improved somewhat since this RFC was written.
> >
> > [1] http://tools.ietf.org/html/rfc1149
> It was:
> https://tools.ietf.org/html/rfc2549

Oops, my apologies to all.  My research was obviously conducted
without due diligence.  I must try harder.

Further afternoon, armchair research shows a later RFC[2] with an
extension for IPv6.  Nice to see the IETF on the ball :-)

[2] http://tools.ietf.org/html/rfc6214
--
Dennis Davis <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Giancarlo Razzolini-3
In reply to this post by Gilles Chehade-7
Em 03-07-2014 05:36, Gilles Chehade escreveu:

> On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
>> * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
>>> Better buy a hardisk, copy your data and mail it abroad. Seriously.
>> A truck full of harddisks is a transport link with fantastic bandwidth.
>> Latency kinda sucks, tho.
>>
> Sadly, French researchers have found _at least_ one way to DDoS
> this transport and make it unusable with very few resources:
>
>      http://french.about.com/od/vocabulary/a/operationescargot.htm
>
https://what-if.xkcd.com/31/

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Jim Willis-2
In reply to this post by Gregory Edigarov-5
44


Sent from my Samsung Epic™ 4G Touch

-------- Original message --------
From: Giancarlo Razzolini <[hidden email]>
Date: 07/03/2014  9:56 AM  (GMT-06:00)
To: Gilles Chehade <[hidden email]>,[hidden email]
Subject: Re: openssh
 
Em 03-07-2014 05:36, Gilles Chehade escreveu:

> On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
>> * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
>>> Better buy a hardisk, copy your data and mail it abroad. Seriously.
>> A truck full of harddisks is a transport link with fantastic bandwidth.
>> Latency kinda sucks, tho.
>>
> Sadly, French researchers have found _at least_ one way to DDoS
> this transport and make it unusable with very few resources:
>
>      http://french.about.com/od/vocabulary/a/operationescargot.htm
>
https://what-if.xkcd.com/31/

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Chris Cappuccio
In reply to this post by Peter Nicolai Mathias Hansteen
Peter N. M. Hansteen [[hidden email]] wrote:
> On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
> > * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
> > > Better buy a hardisk, copy your data and mail it abroad. Seriously.
> >
> > A truck full of harddisks is a transport link with fantastic bandwidth.
> > Latency kinda sucks, tho.
>
> And if the hard disks are small enough, you can attach them to pigeons, or swallows, even! (African or European)
>

Drones.

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Gilles Cafedjian
Le 03/07/2014 22:49, Chris Cappuccio a écrit :

> Peter N. M. Hansteen [[hidden email]] wrote:
>> On Thu, Jul 03, 2014 at 10:32:42AM +0200, Henning Brauer wrote:
>>> * Mihai Popescu <[hidden email]> [2014-07-02 17:05]:
>>>> Better buy a hardisk, copy your data and mail it abroad. Seriously.
>>> A truck full of harddisks is a transport link with fantastic bandwidth.
>>> Latency kinda sucks, tho.
>> And if the hard disks are small enough, you can attach them to pigeons, or swallows, even! (African or European)
>>
> Drones.
>
Burrito.

http://tools.ietf.org/html/draft-lohsen-ip-burrito-00

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Christian Weisgerber
In reply to this post by Damien Miller
On 2014-07-03, Damien Miller <[hidden email]> wrote:

>> Just out for curiosity.
>> what is the fastest and lightest in cpu terms algorithm in ssh?
>
> In recent OpenSSH, [hidden email] is what you want.

Most likely yes, but I wouldn't entirely dismiss Nick's suggestion
to test actual performance.  E.g., I stopped preferring
chacha20-poly1305 for my Blade 100, because aes128-ctr/umac-64 was
actually faster when I checked.

And, speaking in general, the choice of MAC has as much influence
on bulk throughput as the cipher, if not more so.  It's remarkable
that new MACs are still such a performance problem.  GHASH for
AES-GCM is widely acknowledged to be a nightmare in software, but
I feel Poly1305's claim to speed is also overstated.  DJB's propaganda
refers to his hyperoptimized x86 implementation that bizarrely
abuses the floating point registers to perform integer arithmetic.
The portable version we use has an inner loop that requires 25
multiplications 32x32->64 bits for each 16-byte block.  For simple
CPUs, that will stall out the pipeline.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: openssh

Zeljko Jovanovic
In reply to this post by Peter Nicolai Mathias Hansteen
On 03.07.2014. 10:41, Peter N. M. Hansteen wrote:

> And if the hard disks are small enough, you can attach them to pigeons, or swallows, even! (African or European)
>
> - P

What is the air-speed velocity of an unladen swallow (African or European)?

:D

12