Hello.
I'm using a x2go server on CentOS 6.9 (the latest version from EPEL, 4.0.1.20), clients use Windows XP/7 and the latest version of X2Go Client (4.1.0.0-2017.03.11). Each time the client connects, ssh-keygen.exe (C:\Program Files\x2goclient\ssh-keygen.exe) starts with the parameters "-t rsa -b 4096 -N" "-C" X2Go Client RSA user key "-f C: /Users/max/.x2go/ssh/gen/key.fl1416 ". On not very powerful computers, this causes a delay of a few seconds with each connection and irritates users. Tell me please, if it is possible to generate this key once and for all?
--
M. Alhimenko
On 09/28/2017 01:49 PM, Max A. wrote:
I understand that this may be inconvenient, but no, there's currently no way to generate a set of keys that will be re-used.
I explicitly decided against that. For more information and the rationale for this change, refer to the release announcement: http://lists.x2go.org/pipermail/x2go-announcements/2017/000302.html
Mihai
I agree with this. One of the things Snoden revealed was that the NSAhung on to a large number of compromised keys to tain access to encrypted data. In light of that re-using the same key is just making things too easy.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Fri, 6 Oct 2017, Mihai Moldovan wrote:
On Fri, Oct 6, 2017 at 3:12 AM, Mihai Moldovan <ionic@ionic.de> wrote:
The release announcement talks about 2048-bit keys being generated while this indicates that even stronger keys are being used (which in turn increases the time to create them). I think for slow clients this is too much. At least the admin should be able to decide about the required security, not the maintainer.
So what about staying as is by default but providing a possibility to pre-generate keys for those connections.
Uli
By doing so you weaken security for sites providing this capability.-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Fri, 6 Oct 2017, Ulrich Sibiller wrote:
On Fri, Oct 6, 2017 at 9:22 AM, Robert Dinse <nanook@eskimo.com> wrote:
By doing so you weaken security for sites providing this capability.
Yes, maybe, maybe not. Think about sites that have strict rules about keys. Or sites having to use specific key types. Or RSA being compromised. Currently there's nothing an admin can do.
It's the site's administrator that has to decide about that. The tool can provide a default but the admin must be enabled to change it if desired.
Uli
Ok, in any case, it took my 12 year old workstation 5 seconds to connect.Are we not perhaps splitting hairs?
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Fri, 6 Oct 2017, Ulrich Sibiller wrote:
Your laptop is slower than my 12 year old computer? Running Windows 3.11per chance?
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Fri, 6 Oct 2017, Max A. wrote:
My machine is also 2005 vintage. Bu tnot celeron based. This is ratherlike the argument of whether or not to retain weak encryption on https so that Windows 95 users can still use it.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Fri, 6 Oct 2017, Max A. wrote:
Robert,
Please do not mock other users just because they have what you consider inferior hardware. Some people are stuck with old hardware for whatever reason, and there are many reasons that qualify as valid.
Kind Regards, Stefan Baur X2Go Project/Community Manager
Am 06.10.2017 um 11:13 schrieb Robert Dinse:
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
I agree especially in the case of the TCE where we're targeting ThinClients that are generaly quite low on specs (mostly ATOM or celeron based). Anyway,time to open the session is a bit too slow to my taste, I would agree but this is not unbearable. RDP on the other hand is extremely fast at opening the session but if I remember well, it uses a secured channel with encryption (but not through SSH) so, what are they using to connect that fast without compromising security too much ?
On the other hand, I have a problem with the client beeing very slow to quit but this is another subject, I'll fill a bug report for that later.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> À: x2go-user@lists.x2go.org Envoyé: Vendredi 6 Octobre 2017 12:24:45 Objet: Re: [X2Go-User] ssh-keygen.exe loads the processor every time the client starts
Robert,
Please do not mock other users just because they have what you consider inferior hardware. Some people are stuck with old hardware for whatever reason, and there are many reasons that qualify as valid.
Kind Regards, Stefan Baur X2Go Project/Community Manager
Am 06.10.2017 um 11:13 schrieb Robert Dinse:
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
Am 06.10.2017 um 13:29 schrieb Walid MOGHRABI:
I haven't tested it myself yet, but some devs suggested that slow session startup (as opposed to slow booting to login screen) may be caused by homedirs stored on NFS. Might be worth adding a test account that has a homedir "native" to the server, and if that brings a significant speed increase, trying out other networked filesystems like glusterfs.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Might be possible, NFS migh probably add a few latency but I wouldn't recommend using GlusterFS instead, it is far slower due to the voulme beeing mounted through Fuse. I already did many testing on GlusterFS for our internal usage and it is by far slower than NFS. CephFS (file sharing "nfs like" filesystem provided by Ceph on top of it's storage capabilities, as opposed to the "usual" block mode it provides) could be worth trying but I didn't had the opportunity to do some testing by now. Anyway, I think it should be at most comparable to NFS, not really faster.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> À: "Walid MOGHRABI" <w.moghrabi@servicemagic.eu> Cc: x2go-user@lists.x2go.org Envoyé: Vendredi 6 Octobre 2017 13:33:43 Objet: Re: [X2Go-User] ssh-keygen.exe loads the processor every time the client starts
Am 06.10.2017 um 13:29 schrieb Walid MOGHRABI:
I haven't tested it myself yet, but some devs suggested that slow session startup (as opposed to slow booting to login screen) may be caused by homedirs stored on NFS. Might be worth adding a test account that has a homedir "native" to the server, and if that brings a significant speed increase, trying out other networked filesystems like glusterfs.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
Am 06.10.2017 um 15:07 schrieb Walid MOGHRABI:
See, you "think", but you haven't verified it in comparison to a local homedir. As I said, I haven't either, but it was a hint from some of the devs to look out for that. So maybe we just have to live with a slower session startup if networked homedirs are part of the equation; testers to confirm or dismiss this theory are welcome. ;-)
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Stefan I apologize but I thought my 12 year old hardware was really pastobsolete but it keeps chunking on somehow so it hasn't been replaced.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Fri, 6 Oct 2017, Stefan Baur wrote:
Am 06.10.2017 um 10:56 schrieb Max A.:
In my opinion, it would be possible to give an opportunity to choose between security and convenience.
No, because there would be no way to enforce it in cases where it is actually needed.
I was actually considering to suggest that we add an option either server- or client-side that allows using less secure, but faster algorithms - but adding such an option would ease things for an attacker, so: No.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On 10/06/2017 12:57 AM, Ulrich Sibiller wrote:
What about ed25519 keys?
https://stribika.github.io/2015/01/04/secure-secure-shell.html
About 30-60 times faster to create on my fairly fast machine.
Unfortunately EL6 era machines don't support them.
-- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 https://www.nwra.com/
-
Max A. -
Mihai Moldovan -
Orion Poplawski -
Robert Dinse -
Stefan Baur -
Ulrich Sibiller -
Walid MOGHRABI