Am 26.12.2013 14:59, schrieb Luciano Gabriel Andino:
hello! thanks for your answer. I will try to explain what I try to do and maybe you can recommend the best option. Actually, I'm using thinstation's image for booting diskless station to access a Linux server using XDMCP.
This seems a bit strange to me - why the extra hassle of using thinstation when X2Go has a ThinClientEdition of its own? I'm not saing thinstation is a bad product, in fact, I toyed around with it a few years ago too. It just doesn't seem to make sense when you want to connect via X2Go, when X2Go natively supports XDMCP as a session type, and has a ThinClientEdition. Then again, I've never used XDMCP, so maybe this is where the misunderstanding and confusion starts.
My LAN has about 25 MSI wind nettop clients, no HD but can boot using PXE. I am just trying testing x2go to see if there is an important improvement in terms of graphical response at client side. At the same time, I'm interesting to access my KDE session from outside (Internet) with a normal computer. The problem is I don't know which can be the best option for diskless computers in LAN, thinking that sometimes any user needs to access his account from a different station. Options I understood you told, are:
- using no public keys (no encryption?) how can be done?
"No public keys" does NOT mean "no encryption". X2Go uses SSH, and SSH can work with keyfiles (which may be password-protected or not) or just plain passwords, without any keyfiles involved.
It all depends on your needs - security vs. usability. Of course, planting a passwordless ssh key file into the image will allow everyone to sign in - into every account that has the coresponding keyfile - without ever having to type a single password. Unbeatable ease of use - but a security nightmare.
The other extreme is the two-factor authentication, requiring each user to *know* something - her/his own personal password for the keyfile on her/his USB key fob or smartcard - and to *be in posession of* something
- the actual key fob/smartcard. Especially with smartcards, which aren't easily copied like USB key fobs, this is VERY secure. But the complexity makes it harder to use.
Two "middle ground" scenarios are passwordless keyfiles on USB key fobs passwords without keyfiles - select the session, type in the password,
- plug in, click on the session you want to start, and you're in - and
and off you go. With these two, I'd prefer the "password only" approach, as with server-checked passwords, you have the option to set minimum requirements regarding length and complexity, while you cannot enforce those on passwords for keyfiles.
- In this option, I don't understand if .ssh/authorized_keys must be on home user directory in server or in usb stick?
.ssh/authorized_keys goes on the server (user homedir) and contains the public key. Private key goes on the USB key fob.
Is there any documentation for this?
That's nothing X2Go-specific. If you're lacking experience with SSH authentication methods, you should turn to the SSH documentation. :-)
Also seems users need to have their own stick to attach in station they want to use.
Indeed, that's the idea behind two-factor authentication.
- I can store session and public keys in exported fs (not recommended).
No. Storing *private* keys anywhere where more than one person can access them is not recommended. But that's what you'd have to do if you're looking for a way users neither have to carry a USB key fob NOR have to enter any password at all.
Also I am in doubt if users change their Linux account's password or they access from different station, I need to introduce changes in publickeys.
I'm not sure what you're trying to say here - but maybe you'd also like to take a look at the PAM (Pluggable Authentication Module) documentation (PAM is a standard Linux thing, nothing X2Go-specific)? After all, with proper settings, you can enforce minimum password requirements and regular password changes for standard Unix/Linux passwords just fine. It's only the password complexity for private key files that you don't have any control over. And although I've never needed it - as far as I know, it is also possible to define which user is allowed to log into the server from which machine. After all, that's something that even Microsoft Windows could do more than 10 years ago, and these guys are usually way behind Unix/Linux when it comes to security and multiuser stuff.
-Stefan