Hi there)) I am trying to configure x2go/pxe and this is my first question.
I did a clientsession in server and scp transfer to pxe server. PXE server is ready, client booted but I can't login cause this message appears (in client):
"Access denied: Authentication that can continue...."
while it was possible to login from a linux box. The idea is that a any user can access to his account from anyclient. how can I store this publickeys?
thanks in advance,
-- Saludos!!
Luciano Andino GNU/Linux user #185103 Santa Fe - Argentina
Am 24.12.2013 02:33, schrieb Luciano Gabriel Andino:
Hi there)) I am trying to configure x2go/pxe and this is my first question.
I did a clientsession in server and scp transfer to pxe server. PXE server is ready, client booted but I can't login cause this message appears (in client):
"Access denied: Authentication that can continue...."
while it was possible to login from a linux box. The idea is that a any user can access to his account from anyclient. how can I store this publickeys?
I'm not sure what went wrong there, but I'm also not quite sure what you're trying to accomplish. So I've typed down the answers to the three most likely interpretations of your question that I can come up with. If none of this matches what your intention is, please rephrase your question, explain in greater detail what you're trying to accomplish (expected behavior versus actual behavior), and post again.
The following is assuming that while you want every user to be able to use every client, you *do* want authentication (i.e. every user has a dedicated account that no one else should be using):
The easiest way would be using passwords only. You do not HAVE to use public key files, though of course they provide greater security WHEN - and ONLY WHEN - implemented and used correctly.
If you want to use two-factor authentication, my guess is that you could either 2a) put the secret keys (the public key of each user needs to be in the user's home directory, in a subdirectory called ".ssh", and a file named "authorized_keys", with proper restrictive permissions in place) on a USB key fob, set up the Thin Client Environment so that it looks for USB devices and tries to mount them automatically, and have a symlink from .ssh/id_rsa or id_dsa on the TCE user's home directory on the thin client point to the mountpoint of the USB device (which needs to contain a linux filesystem so the permissions work) or 2b) use Smartcard-Based authentication, which requires cards and reader hardware. This is something I've never used myself, though, so you should contact one of the core developers (Mike Gabriel seems to be the most active one these days) about how that works.
Now, assuming that you don't care about security at all, because you want everyone to be able to log in as everyone (think Infokiosk), you could of course dump all the secret keys for your pseudo-users into id_rsa_something or id_dsa_something files (as above, with proper restrictive permissions in place), make them part of the TCE NFS image and reference them in your sessions file - but that is something you should really only do if you DO NOT NEED NOR WANT ANY SECURITY AT ALL and are simply looking for a way that users aren't bothered with having to enter a password.
If you think you should use Keyfiles AND Passwords to the keyfiles, AND are looking for a way to centrally store the keyfiles so nobody needs a USB key fob or smartcard, you are making your system LESS secure than a password-only solution without keyfiles. So if that was your intent, DO NOT DO THAT. The reason is that while you can regularly change passwords on secret keyfiles, ANY copy of a secret keyfile with a known password WILL ALWAYS grant access to the account with the matching public keyfile. So if anybody at any time gets hold of the keyfile AND the then-current password, changing the password on your keyfile DOES NOT LOCK HIM OUT. You NEED to generate completely NEW keyfiles in that situation. THIS IS BAD. So avoid this approach at all costs.
Sorry that this message is rather long, but these are some newbie mistakes I'm seeing again and again, and I'd like to keep you from making these mistakes, if only for the sake of your users.
-Stefan
2013/12/24 Stefan Baur <newsgroups.mail2@stefanbaur.de>
Am 24.12.2013 02:33, schrieb Luciano Gabriel Andino:
Hi there)) I am trying to configure x2go/pxe and this is my first
question.
I did a clientsession in server and scp transfer to pxe server. PXE server is ready, client booted but I can't login cause this message appears (in client):
"Access denied: Authentication that can continue...."
while it was possible to login from a linux box. The idea is that a any user can access to his account from anyclient. how can I store this publickeys?
I'm not sure what went wrong there, but I'm also not quite sure what you're trying to accomplish. So I've typed down the answers to the three most likely interpretations of your question that I can come up with. If none of this matches what your intention is, please rephrase your question, explain in greater detail what you're trying to accomplish (expected behavior versus actual behavior), and post again.
The following is assuming that while you want every user to be able to use every client, you *do* want authentication (i.e. every user has a dedicated account that no one else should be using):
The easiest way would be using passwords only. You do not HAVE to use public key files, though of course they provide greater security WHEN - and ONLY WHEN - implemented and used correctly.
If you want to use two-factor authentication, my guess is that you could either 2a) put the secret keys (the public key of each user needs to be in the user's home directory, in a subdirectory called ".ssh", and a file named "authorized_keys", with proper restrictive permissions in place) on a USB key fob, set up the Thin Client Environment so that it looks for USB devices and tries to mount them automatically, and have a symlink from .ssh/id_rsa or id_dsa on the TCE user's home directory on the thin client point to the mountpoint of the USB device (which needs to contain a linux filesystem so the permissions work) or 2b) use Smartcard-Based authentication, which requires cards and reader hardware. This is something I've never used myself, though, so you should contact one of the core developers (Mike Gabriel seems to be the most active one these days) about how that works.
Now, assuming that you don't care about security at all, because you want everyone to be able to log in as everyone (think Infokiosk), you could of course dump all the secret keys for your pseudo-users into id_rsa_something or id_dsa_something files (as above, with proper restrictive permissions in place), make them part of the TCE NFS image and reference them in your sessions file - but that is something you should really only do if you DO NOT NEED NOR WANT ANY SECURITY AT ALL and are simply looking for a way that users aren't bothered with having to enter a password.
If you think you should use Keyfiles AND Passwords to the keyfiles, AND are looking for a way to centrally store the keyfiles so nobody needs a USB key fob or smartcard, you are making your system LESS secure than a password-only solution without keyfiles. So if that was your intent, DO NOT DO THAT. The reason is that while you can regularly change passwords on secret keyfiles, ANY copy of a secret keyfile with a known password WILL ALWAYS grant access to the account with the matching public keyfile. So if anybody at any time gets hold of the keyfile AND the then-current password, changing the password on your keyfile DOES NOT LOCK HIM OUT. You NEED to generate completely NEW keyfiles in that situation. THIS IS BAD. So avoid this approach at all costs.
Sorry that this message is rather long, but these are some newbie mistakes I'm seeing again and again, and I'd like to keep you from making these mistakes, if only for the sake of your users.
-Stefan
X2Go-User mailing list X2Go-User@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-user
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. 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?
In this option, I don't understand if .ssh/authorized_keys must be on home user directory in server or in usb stick? Is there any documentation for this? Also seems users need to have their own stick to attach in station they want to use.
I can store session and public keys in exported fs (not recommended).
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.
-- Saludos!!
Luciano Andino GNU/Linux user #185103 Santa Fe - Argentina
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
-
Luciano Gabriel Andino -
Stefan Baur