[X2Go-User] pxe: "Access denied: Authentication that can continue...."

[Stefan Baur]

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:
> 1) 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 
- plug in, click on the session you want to start, and you're in - and 
passwords without keyfiles - select the session, type in the password, 
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.


> 2) 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.


> 3) 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