Xrdp: VNC Password failed when picking existing session

[Fabiosilvero]

Hello everyone,

I'm having trouble configuring xrdp with VNC on a debian 9 VM.

VNC server used : tigervnc-standalone-server

I'm using these settings in xrdp.ini :

[xrdp0]
name=OldSession
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=5910
delay_ms=5000

[xrdp1]
name=NewSession
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
delay_ms=5000

Creation of a new session works fine, but when I want to pick my older session, I have the following message : VNC Password Failed.

I was however using the same credentials.

Any ideas ?

Thanks !

[Adonai]

IIRC sesman uses autogenerated passwords to create sessions. So your scenario won't work.

[metalefty]

Can you confirm if the issue is identical to #1006, #1007?

[metalefty]

Looks not.

[tunip]

I have the same issue (xrdp 0.9.5). My workaround is creating a vnc password with vncpasswd and copy passwd over the sesman_username_passwd:10 file. Then i can reconnect to my session.

If sesman uses autogenrated passwords, how can we reconnect to an existing session?

[Adonai]

Leave -1 in port. If resolution and bpp didn't change, sesman will reconnect you to existing one.

[Fabiosilvero]

Thanks Adonai, that was the information I was lacking :)

When I'm setting the resolution (for example : 1366 x 768), no prob, sesman reconnects me to my older session. Tested with RDP Client on Windows 10.

But with Guacamole resizing automatically the resolution (sometimes with non-standard resolutions, causing sesman to create a new session), that scenario isn't possible unless if I set the resolution myself to a given value in user-mappings.xml. In that case, sesman will reconnect me because there was no resizing.

Is there any value that can help me in xrdp.ini ? I read somewhere that AllowVNCresize=1 could work, but it doesn't in my case...

[Adonai]

@Fabiosilvero I tried my best with xrdp.ini 4 months ago and didn't achieve anything. For now I'm just using vncserver -geometry WxH :1 and connect with TigerVNC Viewer. With Guacamole I suppose it's not the solution you seek.

I guess you'll have to dive into the code and dig out the part where sesman decides you're eligible for reconnection and propose a change to maintainers with pull-request.

[liwaiwai]

@Adonai What if there is a session of which resolution and bpp are unknown/forgotten, is there a way to regain that session?

[Adonai]

@liwaiwai just to clarify, I'm not the developer of xrdp.

I don't know how to recover lost session. Believe me, I tried.

[bgstack15]

Someday I hope to re-add the feature where you can choose the tcp port number and just reconnect to the session you had before (like it used to be). But I'd have to learn how to actually program first.

In the mean time, to discover what your current xvnc sessions are, use a shell script. This is adapted from my personal bgscripts project. Here's the one-liner version, to get you started. The linked script includes the color depth as well.

{ echo "user pid Xdisplay port"; { ps -ef | awk '/Xvnc :[[:digit:]]+/ {print $1,$2,$9}' | while read tu tpid tvnc; do sudo netstat -tlpn | awk -v "tpid=${tpid}" '$0 ~ tpid {print $4;}' | sed -r -e 's/^.*://;' -e "s/^/${tu} ${tpid} ${tvnc} /;" ; done ; } | sort -k3 ; } | column -c4 -t

It outputs something like the following:

user      pid     Xdisplay  port
bgstack15   2439    :10       5910
anotheruser  122207  :11       5911

[noncom]

Same problem here. Does anyone have a solution yet?

[sabquat]

Here is my observation-
Leave the port number as -1, it will reconnect/create a session with TCP port 5910. However, specifying the port number as 5910 causes password failure. Even, it is not allowing me to create multiple sessions.
Does anyone have a solution yet?

[taylorjtamu]

Just spent entirely too long fighting with xrdp.ini on this issue. We have users who travel sometimes and use xrdp to access our servers when giving presentations, and expect to be able to access the same session they left since they're logging in with their normal credentials. Obviously, xrdp will provide a new session since it's a different device with different settings.

We've also had times where xrdp just randomly disconnects and refuses to let them access their old session, since it creates a new session without notice and then just reconnects to that one.

In the past, it was clearly an option to be able to use the port to reconnect to an existing session. Will this become a feature again in the future, even if it's using a different mechanism?

[matt335672]

Hi @taylorjtamu

I can't answer your specific question, but I can give you some background and suggest a workaround. This workaround may not be ideal for you, but it may give you some further ideas.

You haven't mentioned the Xorg backend (which supports resizing). I'm going to assume you've discounted Xorg for other reasons, and I'll stick to discussing the Xvnc backend below.

Looking at the current code, it seems for the Xvnc backend a random password is generated for each session. This was introduced by #497 which in turn was prompted by a Debian security issue CVE-2013-1430. This password is known only to the session manager. In order to connect directly to the VNC session, you'd need to know this password which isn't currently possible to do.

In other words, at the moment you'll need to go through the session manager and convince it to connect to the required session.

The session matching code when you reconnect is controlled by the "session allocation policy" in sesman.ini. By default, for the Vnc backend this looks for a match of user, colour depth and screen resolution. The screen resolution part of the match is enforced in code in the routine session_get_bydata(). You could try messing with the policy setting in sesman.ini, but I'd heavily recommend sticking with the default policy and working with that.

So to reconnect to the required session, the user, colour depth and resolution of the RDP client must match the user, colour depth and resolution of the target session.

I'll assume your travelling users are using some version of Windows on a laptop when travelling, and know the colour depth and resolution of the target session.

Target session is lower resolution than laptop

Run mstsc.exe, and display the options. On the 'Display' tab, choose the required resolution on the slider and choose the colour depth on the dropdown. You should then be able to reconnect to the target session, which will be smaller than the laptop screen.

Target session is higher resolution than laptop

In this instance more effort is required. This is because the mstsc.exe display tab slider will not let you set larger resolutions than the screen you are running on.

Run mstsc.exe, and setting all the parameters you need except the resolution. Set that to 800x600. Then on the General tab, save the settings to an RDP file somewhere.

Edit the file you've just saved in notepad. Find these lines:-

desktopwidth:i:800
desktopheight:i:600

Replace the numbers with the required resolution values and save the file.

You should now be able to double-click on the file in Windows explorer and connect to your session. In this case the session will be larger than the laptop screen, so you'll need to use scrollbars to move around it.

I hope this is useful - please feel free to come back to me if I've made bad assumptions about your situation, or I've not been clear enough.