hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
Farkas Levente wrote:
is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
more questions: why isn't this feature included in upstream openssh? are they working to get this feature/code upstream?
-- Rex
Rex Dieter wrote:
Farkas Levente wrote:
is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
more questions: why isn't this feature included in upstream openssh? are they working to get this feature/code upstream?
I just dropped a query to the hpn-ssh maintainers, as I'd love to have this feature myself, having noticed less-than-spectacular scp performance on gigabit links...
Jarod Wilson wrote:
Rex Dieter wrote:
Farkas Levente wrote:
is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
more questions: why isn't this feature included in upstream openssh? are they working to get this feature/code upstream?
I just dropped a query to the hpn-ssh maintainers, as I'd love to have this feature myself, having noticed less-than-spectacular scp performance on gigabit links...
A related issue: Long ago, ssh included an encryption option "none". I wish it still did! I'd love to have ssh authentication without encryption overhead, when backing up my own data over my own lan.
On Thu, 2007-07-12 at 10:41 -0400, Neal Becker wrote:
Jarod Wilson wrote:
Rex Dieter wrote:
Farkas Levente wrote:
is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
more questions: why isn't this feature included in upstream openssh? are they working to get this feature/code upstream?
I just dropped a query to the hpn-ssh maintainers, as I'd love to have this feature myself, having noticed less-than-spectacular scp performance on gigabit links...
A related issue: Long ago, ssh included an encryption option "none". I wish it still did! I'd love to have ssh authentication without encryption overhead, when backing up my own data over my own lan.
Funny, I just asked for the same thing in #fedora-devel this morning and was provided with this link:
http://arctic.org/~dean/patches/openssh-3.8.1p1-cipher-none.patch
josh
Jarod Wilson wrote:
Rex Dieter wrote:
Farkas Levente wrote:
is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
more questions: why isn't this feature included in upstream openssh? are they working to get this feature/code upstream?
I just dropped a query to the hpn-ssh maintainers, as I'd love to have this feature myself, having noticed less-than-spectacular scp performance on gigabit links...
Fun. So apparently, the hpn-ssh folks have been trying to get this into upstream openssh for about 3 years now, and always get put off by openssh folks being "too busy to validate such a big patch". However, I've been assured the code has been vetted by multiple 3rd-parties, and gets heavily utilized in the high-performance networking community, and has been without any incompatibilities w/stock openssh or serious bug reports in over a year.
Personally, I'd say lets add it to rawhide and see how it goes... Anyone else have an opinion? Adding Tomas to the cc list, since he maintains our openssh packages, to solicit his opinion as well...
Personally, I'd say lets add it to rawhide and see how it goes... Anyone else have an opinion? Adding Tomas to the cc list, since he maintains our openssh packages, to solicit his opinion as well...
Also....
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224489
It's only been open for about six months with no one looking at it ;)
Ray
Jarod Wilson wrote:
Personally, I'd say lets add it to rawhide and see how it goes... Anyone else have an opinion? Adding Tomas to the cc list, since he maintains our openssh packages, to solicit his opinion as well...
Diverging from upstream is a wee-bit against fedora's objectives/goals, but ultimately, it is the pkg maintainer's call to make.
-- Rex
On 7/12/07, Rex Dieter rdieter@math.unl.edu wrote:
Diverging from upstream is a wee-bit against fedora's objectives/goals, but ultimately, it is the pkg maintainer's call to make.
When upstream is working actively with downstream contributors, this policy works well. If upstream blows off downstream contributors who are trying to play ball (and there isn't some sort of weird personality conflict nastiness) the policy can feel burdensome because its re-enforcing a broken process instead of re-enforcing a healthy innovation process.
I can't judge the problem here, but if this work has been going on in parallel for 3+ years, something in the upstream communication is broken. The question is, is this a fixable or a forkable situation? Does Fedora has as a community have any leverage with upstream openssh (via an active fedora contributor who conributes to upstream perhaps?) to put this functionality/patch firmly onto the roadmap for upstream adoption?
-jef
On 7/12/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 7/12/07, Rex Dieter rdieter@math.unl.edu wrote:
Diverging from upstream is a wee-bit against fedora's objectives/goals, but ultimately, it is the pkg maintainer's call to make.
When upstream is working actively with downstream contributors, this policy works well. If upstream blows off downstream contributors who are trying to play ball (and there isn't some sort of weird personality conflict nastiness) the policy can feel burdensome because its re-enforcing a broken process instead of re-enforcing a healthy innovation process.
I can't judge the problem here, but if this work has been going on in parallel for 3+ years, something in the upstream communication is broken. The question is, is this a fixable or a forkable situation? Does Fedora has as a community have any leverage with upstream openssh (via an active fedora contributor who conributes to upstream perhaps?) to put this functionality/patch firmly onto the roadmap for upstream adoption?
You might want to post to comp.security.ssh, Darren Tucker (one of the Upstream devs from OpenSSH) often responds quickly and politely.
stahnma
-jef
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, 2007-07-12 at 12:02 -0400, Jarod Wilson wrote:
Jarod Wilson wrote:
Rex Dieter wrote:
Farkas Levente wrote:
is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
more questions: why isn't this feature included in upstream openssh? are they working to get this feature/code upstream?
I just dropped a query to the hpn-ssh maintainers, as I'd love to have this feature myself, having noticed less-than-spectacular scp performance on gigabit links...
Fun. So apparently, the hpn-ssh folks have been trying to get this into upstream openssh for about 3 years now, and always get put off by openssh folks being "too busy to validate such a big patch". However, I've been assured the code has been vetted by multiple 3rd-parties, and gets heavily utilized in the high-performance networking community, and has been without any incompatibilities w/stock openssh or serious bug reports in over a year.
Personally, I'd say lets add it to rawhide and see how it goes... Anyone else have an opinion? Adding Tomas to the cc list, since he maintains our openssh packages, to solicit his opinion as well...
I'm still a little bit uneasy to allow this patch in. We were trying to keep as close to upstream as possible. On the other hand we have other changes we have other patches in like the SELinux changes for MLS and the recent support for keys in NSS by which we significantly diverge from upstream already. So maybe we could reconsider applying the HPN patch or at least some less controversial parts of it.
But also note that ssh was designed to be primarily a protocol for interactive shell sessions and thus it has its limitations which mean that it never can be 100% efficient as protocol for large file transfers or even establishing VPNs. It seems to me that people which want extremely fast and secure file transfers should use different solutions like stunnel.
Am Donnerstag, den 12.07.2007, 22:40 +0200 schrieb Tomas Mraz:
I'm still a little bit uneasy to allow this patch in. We were trying to keep as close to upstream as possible. On the other hand we have other changes we have other patches in like the SELinux changes for MLS and the recent support for keys in NSS by which we significantly diverge from upstream already. So maybe we could reconsider applying the HPN patch or at least some less controversial parts of it.
This paragraph disagrees with your signature.
But also note that ssh was designed to be primarily a protocol for interactive shell sessions and thus it has its limitations which mean that it never can be 100% efficient as protocol for large file transfers or even establishing VPNs. It seems to me that people which want extremely fast and secure file transfers should use different solutions like stunnel. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb
On Sat, 2007-07-14 at 19:16 +0200, nodata wrote:
Am Donnerstag, den 12.07.2007, 22:40 +0200 schrieb Tomas Mraz:
I'm still a little bit uneasy to allow this patch in. We were trying to keep as close to upstream as possible. On the other hand we have other changes we have other patches in like the SELinux changes for MLS and the recent support for keys in NSS by which we significantly diverge from upstream already. So maybe we could reconsider applying the HPN patch or at least some less controversial parts of it.
This paragraph disagrees with your signature.
That depends on what the right and what the wrong road in this case is which I am afraid I don't know.
tor 2007-07-12 klockan 12:02 -0400 skrev Jarod Wilson:
Personally, I'd say lets add it to rawhide and see how it goes... Anyone else have an opinion? Adding Tomas to the cc list, since he maintains our openssh packages, to solicit his opinion as well...
The problem with this is that if one patch goes in, other will come knocking on the door. :)
Here's one example:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187211
It adds proper GSSAPI support for OpenSSH so that within a Kerberised infrastructure you never again need to answer that question about if the public key fingerprint is correct.
It's a well known patch, it's been around for several years (more than three, I think) but never got fully applied (se bug for more info about that), so the situation is similar.
/abo
On Thu, 2007-07-12 at 23:21 +0200, Alexander Boström wrote:
tor 2007-07-12 klockan 12:02 -0400 skrev Jarod Wilson:
Personally, I'd say lets add it to rawhide and see how it goes... Anyone else have an opinion? Adding Tomas to the cc list, since he maintains our openssh packages, to solicit his opinion as well...
The problem with this is that if one patch goes in, other will come knocking on the door. :)
Yes, that's exactly what I'm afraid of.
And then there is LDAP public key patch, and PKCS#11 patch and X509 patch and who knows what else patch etc. etc. And in the end we will have openssh package which is so diverged from upstream that it will take weeks of work to simply rebase to new upstream version.
Also as ssh(d) are realy security sensitive applications if there is some unnoticed security problem in one of these patches it has much bigger risk of staying unnoticed in public for a long time than in the base upstream package.
Tomas Mraz <tmraz <at> redhat.com> writes:
Yes, that's exactly what I'm afraid of.
And then there is LDAP public key patch, and PKCS#11 patch and X509 patch and who knows what else patch etc. etc. And in the end we will have openssh package which is so diverged from upstream that it will take weeks of work to simply rebase to new upstream version.
What about forking OpenSSH at hosted.fedoraproject.org and trying to get other distributions to join efforts?
Kevin Kofler
Farkas Levente wrote:
hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
I noticed that for scp if you disable compression (yes disable), then transfer rate increases a lot. I looked at it very quickly and it seemed worse the more the data compressed. Also Protocol=1 seems much better:
dd bs=1M count=50 if=/dev/zero of=50MB_zeros dd bs=1M count=50 if=/dev/urandom of=50MB_random
$ scp localhost:50MB_random /tmp 50MB_random 100% 50MB 10.0MB/s 00:05
$ scp -C localhost:50MB_random /tmp 50MB_random 100% 50MB 4.6MB/s 00:11
$ scp -C localhost:50MB_zeros /tmp 50MB_zeros 100% 50MB 2.3MB/s 00:22
#setting Protocol=1 in sshd_config I get the following speed: $ scp -C localhost:50MB_zeros /tmp #Includes time to type password! 50MB_zeros 100% 50MB 12.5MB/s 00:04
When talking about improvements to ssh, chrootssh seems useful: http://chrootssh.sourceforge.net/
Also upstream openssh breaks X forwarding in interesting ways unless -Y is specified (at least fedora fixes this).
Also scp does full remote login etc. even if local specified files don't exist
Also scp has weird error messages: $ scp /etc/fstab localhost:/non_existent/ scp: /non_existent/: Is a directory
Don't get me started...
Pádraig.
Le jeudi 12 juillet 2007 à 16:10 +0100, Pádraig Brady a écrit :
Farkas Levente wrote:
hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
I noticed that for scp if you disable compression (yes disable), then transfer rate increases a lot.
Compression is a big win for remote tranfers. For local ones of course it's a net loss.
Nicolas Mailhot wrote:
Compression is a big win for remote tranfers. For local ones of course it's a net loss.
It's not as simple as that. I also tested across the LAN, and compression slowed things down there also.
Also notice, I demonstrated that compressing and transfering random data is faster than zeros.
It's something to do with the twisty maze of (zlib) buffers and sleeps within ssh I think.
Pádraig.
Le jeudi 12 juillet 2007 à 17:18 +0100, Pádraig Brady a écrit :
Nicolas Mailhot wrote:
Compression is a big win for remote tranfers. For local ones of course it's a net loss.
It's not as simple as that. I also tested across the LAN,
LAN counts as local too. You can find many discussions on compression pros & cons at the protocol level on the internet.
Nicolas Mailhot wrote:
Le jeudi 12 juillet 2007 à 17:18 +0100, Pádraig Brady a écrit :
Nicolas Mailhot wrote:
Compression is a big win for remote tranfers. For local ones of course it's a net loss.
It's not as simple as that. I also tested across the LAN,
LAN counts as local too. You can find many discussions on compression pros & cons at the protocol level on the internet.
It really comes down to who is the bottleneck - the wire or the CPU...
/Thomas
On 7/12/07, Pádraig Brady P@draigbrady.com wrote:
Farkas Levente wrote:
hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
I noticed that for scp if you disable compression (yes disable), then transfer rate increases a lot. I looked at it very quickly and it seemed worse the more the data compressed. Also Protocol=1 seems much better:
dd bs=1M count=50 if=/dev/zero of=50MB_zeros dd bs=1M count=50 if=/dev/urandom of=50MB_random
$ scp localhost:50MB_random /tmp 50MB_random 100% 50MB 10.0MB/s 00:05
$ scp -C localhost:50MB_random /tmp 50MB_random 100% 50MB 4.6MB/s 00:11
$ scp -C localhost:50MB_zeros /tmp 50MB_zeros 100% 50MB 2.3MB/s 00:22
#setting Protocol=1 in sshd_config I get the following speed: $ scp -C localhost:50MB_zeros /tmp #Includes time to type password! 50MB_zeros 100% 50MB 12.5MB/s 00:04
If all you care about is speed why use SSH? Use FTP. Protocol is has some flaws that really can't be overcome, hence, the existance of protocol 2.
When talking about improvements to ssh, chrootssh seems useful: http://chrootssh.sourceforge.net/
Also upstream openssh breaks X forwarding in interesting ways unless -Y is specified (at least fedora fixes this).
Remember that upstream's job is for SSH to be SECURE, not to have all these bells and whistles. I asked them about X.509 support, tab-completion in sftp, Public keys in LDAP, and several other features and the answer is always, "will it introduce more bugs specifially in the security space?" Since they are not sure, they decide to be cautious. I actually am kind of surprised the project hasn't forked into the feature-rich SSH and a stable/secure one (classic) OpenSSH.
stahnma
Also scp does full remote login etc. even if local specified files don't exist
Also scp has weird error messages: $ scp /etc/fstab localhost:/non_existent/ scp: /non_existent/: Is a directory
Don't get me started...
Pádraig.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, Jul 12, 2007 at 01:54:57PM +0200, Farkas Levente wrote:
hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
This OpenSSH bug may be of interest:
https://bugzilla.mindrot.org/show_bug.cgi?id=1311
This is not the HPN patch, but a different patch offering some performance gains. Sounds like it'll be in OpenSSH 4.7.
Here's another bug with some commentary (and there is plenty more discussion on the OpenSSH mailing list):
https://bugzilla.mindrot.org/show_bug.cgi?id=1337
Ray
is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh?
Not unless upstream takes it. The Fedora merge did not happen so that we don't have to work with upstream anymore. We should never think about putting a patch in Fedora first and then seeing if upstream takes it.
-Steve
____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=...
Steve G <linux_4ever <at> yahoo.com> writes:
Not unless upstream takes it. The Fedora merge did not happen so that we don't have to work with upstream anymore. We should never think about putting a patch in Fedora first and then seeing if upstream takes it.
Fedora ships and has always shipped plenty of patches. It not being upstream is definitely an argument against shipping it, but there might be reasons why shipping it is a net win after all.
Also, if upstream isn't willing to merge patches, it might even make sense to fork the project.
Kevin Kofler
On Fri, 2007-07-13 at 00:59 +0000, Kevin Kofler wrote:
Steve G <linux_4ever <at> yahoo.com> writes:
Not unless upstream takes it. The Fedora merge did not happen so that we don't have to work with upstream anymore. We should never think about putting a patch in Fedora first and then seeing if upstream takes it.
Fedora ships and has always shipped plenty of patches. It not being upstream is definitely an argument against shipping it, but there might be reasons why shipping it is a net win after all.
Also, if upstream isn't willing to merge patches, it might even make sense to fork the project.
Please don't use the 'f' word lightly. Forking is the exact opposite goal of Fedora.
josh
On Thu, Jul 12, 2007 at 01:54:57PM +0200, Farkas Levente wrote:
hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
Not really sure if a conclusion was ever reached on this discussion, but...
https://bugzilla.mindrot.org/show_bug.cgi?id=1311
Looks like this is now in 4.7 (not the same as HPN, but some improvements). Is 4.7 slated for inclusion in F8?
Ray
On Tue, 2007-08-21 at 11:58 -0700, Ray Van Dolson wrote:
On Thu, Jul 12, 2007 at 01:54:57PM +0200, Farkas Levente wrote:
hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/
Not really sure if a conclusion was ever reached on this discussion, but...
https://bugzilla.mindrot.org/show_bug.cgi?id=1311
Looks like this is now in 4.7 (not the same as HPN, but some improvements). Is 4.7 slated for inclusion in F8?
Yes, if the actual release happens before the F8 feature freeze.