Closed Hyper200 closed 6 years ago
The relevant log is xrdp.log or just try running xrdp at the foreground ‘xrdp -ns’ and examine the output.
Also try to set the ‘tls_ciphers’ config to something else or just comment it out. בתאריך יום ו׳, 20 ביולי 2018 ב-16:18 מאת Hyper200 <notifications@github.com
:
Hi all,
Trying to configure TLS on xrdp but having issues.
`[Globals] ; xrdp.ini file version number ini_version=1
; fork a new process for each incoming connection fork=true ; tcp port to listen port=3389
address=127.0.0.1
; 'port' above should be connected to with vsock instead of tcp use_vsock=false ; regulate if the listening socket use socket option tcp_nodelay ; no buffering will be performed in the TCP stack tcp_nodelay=true ; regulate if the listening socket use socket option keepalive ; if the network connection disappear without close messages the connection will be closed tcp_keepalive=true
tcp_send_buffer_bytes=32768
tcp_recv_buffer_bytes=32768
; security layer can be 'tls', 'rdp' or 'negotiate' ; for client compatible layer security_layer=tls ; minimum security level allowed for client ; can be 'none', 'low', 'medium', 'high', 'fips'
crypt_level=medium
; X.509 certificate and private key ; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365 certificate=/etc/xrdp/cert-mottmac.pem key_file=/etc/xrdp/key-mottmac.pem ; set SSL protocols ; can be comma separated list of 'SSLv3', 'TLSv1', 'TLSv1.1', 'TLSv1.2' ssl_protocols=TLSv1,TLSv1.1,TLSv1.2 ; set TLS cipher suites tls_ciphers=HIGH
; Section name to use for automatic login if the client sends username ; and password. If empty, the domain name sent by the client is used. ; If empty and no domain name is given, the first suitable section in ; this file will be used. autorun=
allow_channels=true allow_multimon=true bitmap_cache=true bitmap_compression=true bulk_compression=true
hidelogwindow=true
max_bpp=32 new_cursors=true ; fastpath - can be 'input', 'output', 'both', 'none' use_fastpath=both ; when true, userid/password must be passed on cmd line
require_credentials=true
; You can set the PAM error text in a gateway setup (MAX 256 chars)
pamerrortxt=change your password according to policy at http://url
; ; colors used by windows in RGB format ; blue=009cb5 grey=dedede
black=000000
dark_grey=808080
blue=08246b
dark_blue=08246b
white=ffffff
red=ff0000
green=00ff00
background=626c72
; ; configure login screen ;
; Login Screen Window Title
ls_title=My Login Title
; top level window background color in RGB format ls_top_window_bg_color=009cb5
; width and height of login screen ls_width=350 ls_height=430
; login screen background color in RGB format ls_bg_color=dedede
; optional background image filename (bmp format).
ls_background_image=
; logo ; full path to bmp-file or file in shared folder ls_logo_filename= ls_logo_x_pos=55 ls_logo_y_pos=50
; for positioning labels such as username, password etc ls_label_x_pos=30 ls_label_width=60
; for positioning text and combo boxes next to above labels ls_input_x_pos=110 ls_input_width=210
; y pos for first label and combo box ls_input_y_pos=220
; OK button ls_btn_ok_x_pos=142 ls_btn_ok_y_pos=370 ls_btn_ok_width=85 ls_btn_ok_height=30
; Cancel button ls_btn_cancel_x_pos=237 ls_btn_cancel_y_pos=370 ls_btn_cancel_width=85 ls_btn_cancel_height=30
[Logging] LogFile=xrdp.log LogLevel=DEBUG EnableSyslog=true SyslogLevel=DEBUG ; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug
[Channels] ; Channel names not listed here will be blocked by XRDP. ; You can block any channel by setting its value to false. ; IMPORTANT! All channels are not supported in all use ; cases even if you set all values to true. ; You can override these settings on each session type ; These settings are only used if allow_channels=true rdpdr=true rdpsnd=true drdynvc=true cliprdr=true rail=true xrdpvr=true tcutils=true
; for debugging xrdp, in section xrdp1, change port=-1 to this:
port=/tmp/.xrdp/xrdp_display_10
; for debugging xrdp, add following line to section xrdp1
chansrvport=/tmp/.xrdp/xrdp_chansrv_socket_7210
; ; Session types ;
; Some session types such as Xorg, X11rdp and Xvnc start a display server. ; Startup command-line parameters for the display server are configured ; in sesman.ini. See and configure also sesman.ini. [Xorg] name=Xorg lib=libxup.so username=ask password=ask ip=127.0.0.1 port=-1 code=20
[X11rdp] name=X11rdp lib=libxup.so username=ask password=ask ip=127.0.0.1 port=-1 xserverbpp=24 code=10
[Xvnc] name=Xvnc lib=libvnc.so username=ask password=ask ip=127.0.0.1 port=-1
xserverbpp=24
delay_ms=2000
[console] name=console lib=libvnc.so ip=127.0.0.1 port=5900 username=na password=ask
delay_ms=2000
[vnc-any] name=vnc-any lib=libvnc.so ip=ask port=ask5900 username=na password=ask
pamusername=asksame
pampassword=asksame
pamsessionmng=127.0.0.1
delay_ms=2000
[sesman-any] name=sesman-any lib=libvnc.so ip=ask port=-1 username=ask password=ask
delay_ms=2000
[neutrinordp-any] name=neutrinordp-any lib=libxrdpneutrinordp.so ip=ask port=ask3389 username=ask password=ask
; You can override the common channel settings for each session type
channel.rdpdr=true
channel.rdpsnd=true
channel.drdynvc=true
channel.cliprdr=true
channel.rail=true
channel.xrdpvr=true`
If i have security_layer=rdp the connection works and i can login.
If set to TLS my windows client gets the following error: [image: capture] https://user-images.githubusercontent.com/37409036/43004183-e6dae94e-8c26-11e8-91a9-8033983bc13b.PNG
Trying to debug the issue but the log is not that helpful:
`==> xrdp-sesman.log <== [20180720-14:09:16] [DEBUG] Closed socket 5 (AF_INET6 ::1 port 3350) [20180720-14:09:16] [INFO ] starting xrdp-sesman with pid 1579 [20180720-14:09:16] [INFO ] listening to port 3350 on 127.0.0.1 [20180720-14:15:21] [INFO ] shutting down sesman 1 [20180720-14:15:21] [DEBUG] Closed socket 7 (AF_INET6 ::1 port 3350) [20180720-14:15:23] [DEBUG] libscp initialized [20180720-14:15:23] [DEBUG] Testing if xrdp-sesman can listen on 127.0.0.1 port 3350. [20180720-14:15:23] [DEBUG] Closed socket 5 (AF_INET6 ::1 port 3350) [20180720-14:15:23] [INFO ] starting xrdp-sesman with pid 1693 [20180720-14:15:23] [INFO ] listening to port 3350 on 127.0.0.1
==> xrdp.log <== [20180720-14:16:34] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 49928 [20180720-14:16:34] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389) [20180720-14:16:34] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389) [20180720-14:16:34] [DEBUG] TLSv1.2 enabled [20180720-14:16:34] [DEBUG] TLSv1.1 enabled [20180720-14:16:34] [DEBUG] TLSv1 enabled [20180720-14:16:34] [DEBUG] Security layer: requested 11, selected 1 [20180720-14:16:34] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)`
I can't seem to figure it out - Does anyone have any suggestions or does this look like a bug?
Its running on Kali linux, xrdp version is
'ii xorgxrdp 1:0.2.6-1 amd64 Remote Desktop Protocol (RDP) modules for X.org ii xrdp 0.9.6-1 amd64 Remote Desktop Protocol (RDP) server'
Thanks for any help.
Joe.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/neutrinolabs/xrdp/issues/1172, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTH1H3MN-MxK9xcpi5JzYtRa4Wx7-nDks5uIdiVgaJpZM4VYBTR .
-- Idan Freiberg
GPG FP: 8108 7EC9 806E 4980 75F2 72B3 8AD3 2D04 337B 1F18
Hi there,
Thanks for that
The errors are ovbious now, please see below:
[20180720-15:08:36] [INFO ] starting xrdp with pid 2247
[20180720-15:08:36] [INFO ] listening to port 3389 on 0.0.0.0
[20180720-15:08:47] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 49954
[20180720-15:08:47] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)
[20180720-15:08:47] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
[20180720-15:08:47] [DEBUG] TLSv1.2 enabled
[20180720-15:08:47] [DEBUG] TLSv1.1 enabled
[20180720-15:08:47] [DEBUG] TLSv1 enabled
[20180720-15:08:47] [DEBUG] Security layer: requested 11, selected 1
ssl_tls_print_error: SSL_accept: Failure in SSL library (protocol error?)
trans_set_tls_mode: ssl_tls_accept failed
xrdp_sec_incoming: trans_set_tls_mode failed
xrdp_process_main_loop: libxrdp_process_incoming failed
ssl_tls_print_error: SSL_shutdown: Failure in SSL library (protocol error?)
[20180720-15:08:48] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)
xrdp_mcs_disconnect - socket closed
Can't see what causes this issue though? i've tried tls_ciphers=HIGH and #tls_ciphers=HIGH with no result.
You might want to look at network capture using wireshark. I think the issue is probably lack of supported ciphersuites that windows allows. I think @kiwao meta@vmeta.jp was saying you the the ephemeral ciphersuites (ECDHE, DHE) to be enabled on the server machine (so xrdp will support them)
what is the server openssl version ?
[image: Mailtrack] https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& Sender notified by Mailtrack https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& 07/20/18, 5:14:41 PM
On Fri, Jul 20, 2018 at 5:11 PM Hyper200 notifications@github.com wrote:
Hi there,
Thanks for that
The errors are ovbious now, please see below:
[20180720-15:08:36] [INFO ] starting xrdp with pid 2247 [20180720-15:08:36] [INFO ] listening to port 3389 on 0.0.0.0 [20180720-15:08:47] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 49954 [20180720-15:08:47] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389) [20180720-15:08:47] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389) [20180720-15:08:47] [DEBUG] TLSv1.2 enabled [20180720-15:08:47] [DEBUG] TLSv1.1 enabled [20180720-15:08:47] [DEBUG] TLSv1 enabled [20180720-15:08:47] [DEBUG] Security layer: requested 11, selected 1 ssl_tls_print_error: SSL_accept: Failure in SSL library (protocol error?) trans_set_tls_mode: ssl_tls_accept failed xrdp_sec_incoming: trans_set_tls_mode failed xrdp_process_main_loop: libxrdp_process_incoming failed ssl_tls_print_error: SSL_shutdown: Failure in SSL library (protocol error?) [20180720-15:08:48] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389) xrdp_mcs_disconnect - socket closed
Can't see what causes this issue though? i've tried tls_ciphers=HIGH and
tls_ciphers=HIGH with no result.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/neutrinolabs/xrdp/issues/1172#issuecomment-406612488, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTH1MlCFn2TPyrSjeFLPi8aONzfsaCOks5uIeUSgaJpZM4VYBTR .
-- Idan Freiberg Mobile: +972-52-2925213
Openssl version is: OpenSSL 1.1.0h 27 Mar 2018
I would have thought there must be one supported cipher suite that windows/openssl supported within HIGH?
Does anyone know of one which works with windows and i can try that specific cipher?
ECDHE-RSA-AES256-GCM-SHA384
is one of supported cipher suites.
Can you show me the result of openssl ciphers HIGH
?
:/etc/xrdp# openssl ciphers HIGH ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:PSK-CAMELLIA128-SHA256
Looks like it!
I get the same issue with:
tls_ciphers=ECDHE-RSA-AES256-GCM-SHA384
@speidy
Wireshark isn't really tell me much bar there is a two way connection. Does this suggest it's not negotiation the TLS options yet?
I've also tried with an windows 10 client on the same LAN in case the SSH tunnel was somehow interfering with it.
Does anyone have any other suggestions? I've tried a few things but i'm not really getting anywhere at the moment.
Cheers
Joe.
Can you tell what is your client machine OS version / mstsc version?
Did you try to connect w/o ssh tunnel ?
Hi @speidy
Windows Version: Version 10.0.16299 Build 16299
MSTSC Version attached
I have also tried without the SSH tunnel and going directly, no luck.
Cheers
You should try other clients ex FreeRDP to break down the issue.
@metalefty
FreeRDP is the same, Working when security_level=rdp but not when security_level=tls
Show the FreeRDP log.
Does freerdp log by default or is there a required switch? - Can't seem to find a log at the moment.
(Using the windows freerdp client)
UNIX version writes log to the stdout/stderr but Windows version probably doesn't. Anyway, the issue still seems cipher suite issue.
I've tried from fedora 28 using freerdp
[12:19:06:162] [32166:32167] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[12:19:06:163] [32166:32167] [INFO][com.freerdp.client.x11] - No user name set. - Using login name: mad56570
[12:19:06:215] [32166:32167] [INFO][com.freerdp.crypto] - creating directory /home/mad56570/.config/freerdp
[12:19:06:215] [32166:32167] [INFO][com.freerdp.crypto] - creating directory [/home/mad56570/.config/freerdp/certs]
[12:19:06:215] [32166:32167] [INFO][com.freerdp.crypto] - created directory [/home/mad56570/.config/freerdp/server]
[12:19:06:260] [32166:32167] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_TLS_CONNECT_FAILED [0x00020008]
[12:19:06:260] [32166:32167] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
Does this tie in with your cipher suite suspecting? If so how do i fix it?
@Hyper200 can you provide the smallest repro VM ?
I can, leave it with me i'll create a VM - Can you send me an email i'll use OneDrive/Dropbox to send it across.
Cheers
Joe.
@Hyper200 I'm sorry. I missed that you're waiting for my email and I was waiting for you.
Can you send me the VM to meta@vmeta.jp ?
Hello. Maybe this info could help or not, but just in case... I tried with Debian Stretch both with XRDP version 0.9.8 (from backports) and 0.9.1. Both using XFreeRDP 2.0.0 and RDesktop 1.8.3. It connects only using plain RDP encryption. Thanks!!!
@ivanbaldo Your issue is your issue. Maybe you should add xrdp user to ssl-cert group. That is FAQ for Debian users.
Anyway, no feed back from the reporter more than a month, closing.
The issue is real, at least on Debian Stretch (current stable). I did add the xrdp user to ssl-cert group and restarted xrdp and sesman. I can give feedback and try almost anything you ask me. Thanks!!!
I know this issue is old and closed, but not resolved. I had the same issue today on only a single computer and found out the culprit was the used ssl certificate (in my case the default snakeoil ssl certificate). The solution was a simple renewal: sudo make-ssl-cert generate-default-snakeoil --force-overwrite
I have the same issue on Arch host and Windows Vista. Working fine on 10 though, but the laptop is too outdated for it.
What I get is An authentication error has occurred (Code: 0x80090302)
on Vista and
Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] SSL_accept: Failure in SSL library (protocol error?) Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] SSL: error:0A000102:SSL routines::unsupported protocol Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] trans_set_tls_mode: ssl_tls_accept failed Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] xrdp_sec_incoming: trans_set_tls_mode failed
by entering systemctl status xrdp.service
For those still struggling: older packages of XRDP (eg in older distros like Ubuntu Focal Fossa, Debian Bullseye etc) do not support ephemeral certificates due to XRDP hardcoded to look for RSA certificates.
See also: https://github.com/neutrinolabs/xrdp/issues/1776 https://github.com/matt335672/xrdp/commit/ea582429e1d0413c7d53b718419f6a73142dd3c7
Hi all,
Trying to configure TLS on xrdp but having issues.
If i have security_layer=rdp the connection works and i can login.
If set to TLS my windows client gets the following error:
Trying to debug the issue but the log is not that helpful:
I can't seem to figure it out - Does anyone have any suggestions or does this look like a bug?
The RDP connection is being sent via a SSH tunnel hence the 127.0.0.1 addresses.
Its running on Kali linux, xrdp version is
Thanks for any help.
Joe.