Windows 10 client presents certificate, then fails to connect #1857
Comments
|
You can remove TLS from the connection by setting With that said, tt very much looks like a network issue to me in that the connection looks like it's being interrupted by something. Are server and client on the same subnet? |
It looks like my initial issue is related to TLS; hopefully this will help if someone else has this problem in the future. Any pointers on how to troubleshoot that? Or is "use RDP instead" a common workaround? xrdp.log xrdp-sesman.log |
|
Thanks for the additional info. There seem to be two issues here - TLS and Xvnc. As a bonus we could look at the Xorg later. The TLS issue log suggests the client is closing the connection after the server thinks the connection has been established. That's really unusual. Looking at the TLS protocol, the very last step is the server sending a MAC of all the messages it's sent. If the signature on the MAC is incorrect, the client will close the connection. In other words, there may be a mismatch between your TLS certificate and your private key on the server side. I'm not aware of any logs we could look at on the client side to confirm this however, and the server should really be checking this so it's only a hunch. What are the outputs of these two commands? They should be the same. If not we can regenerate files as appropriate. As far as the Xvnc issue goes, your log above is useful. It suggests the desktop isn't starting properly. Can you try the following to get a fuller log of system activity?
Additionally there may be information in |
Looks the same to me. I do have a I deleted the file and tried rdp->Xvnc, the file did not regenerate. I tried rdp->Xorg and let that time out, the file did not regen. I also checked journalctl shows that xfce is flat-out crashing, which is a little odd as I can login directly just fine. I'm actually posting this from the server 🤨 I guess that's another reason to retry rdp before logging back into the server. (Everything before this snip matches the previous Since I said I was going to log out anyway, I'm going to update the server and reboot it as well. I'll add another comment once I have those results. |
|
I did a quick google search for "xfce4-session segfault" and got a couple interesting hits, but nothing immediately useful. I'm also running out of troubleshooting spoons for tonight. Most likely I will pick this up again over the weekend :) |
|
Another short note--the xfce4-session crash doesn't happen till after I close the "Unable to contact settings server" error. So I'm going to focus back on that error message instead of the segfault. |
|
I noticed some errors from PAM that may or may not be related to my actual issue. Journalctl error I tried the fix referenced there (comment out "-account [success=1 default=ignore] pam_systemd_home.so" in Journalctl before futzing with PAM: [ and then I got the above popup error, and xfce4-session crashed once that was closed ] after the PAM edit: [ long crash dump continues, lmk if it would be helpful to include ] the gpg-agent stuff is new, I just don't know whether or not this is a step forward. stopping systemd-homed doesn't seem to change anything after commenting it out of I will reboot the server and try again Just In Case, but I don't expect that to change anything new. (edits for clarity and typos, because it's late) |
|
Well! Next step is trying to turn TLS back on--but I need some sleep first 😁 |
|
|
Thanks for the updates. The systemd thing, including workarounds, is better documented in #1684. In a nutshell, the systemd PAM module expects the same PID to authenticate and start the session. We don't do this, and I'm not aware of anything in the PAM docs which says that it's necessary. I'd like to move us over to doing things the way systemd is assuming, but it requires some rather massive changes which aren't going to happen quickly. The TLS issue is odd. It's not been reported before, and it looks to me from the errors you've got that it's the client closing the connection after it's been established. I can't think of any reason why this should be happening. Debugging this might require other software. You might get something useful out of using remmina/freerdp to connect from another Linux machine. Alternatively, running wireshark on the connection will show the TLS handshake (even though it doesn't occur at the start of the connection) and make it clear which end closes the connection. The one login session is, I'm afraid, now standard if you're using When your Xorg is timing out, do you get anything in |
As it seems to be a Windows client issue (and I can use freeRDP as a workaround), I'll accept if you think I should close this out and ask Microsoft about their client. If you still have any troubleshooting/debugging suggestions, I'm all ears 😸 |
|
Thanks for the update. If you run freerdp from the command line, do you get any useful console output? Also, have you been experimenting with NLA settings on the Windows side? We don't yet support NLA, but a pre-requisite for using it is that TLS security is enabled. I'm unable to reproduce your issue by using an IP address here. On way forward might be for you to regenerate your cert using a different private key. If the new one works, that's great - problem solved. If it doesn't you can post the new private key and cert here in PEM format and we can try to reproduce the problem. |
|
A quick run of freerdp doesn't give anything that looks useful to me: I haven't intentionally done anything with NLA, and I don't see the option in the Windows client. (I'm using Windows 10 Home, so it has the RDP client but won't run an RDP server.) If there's anywhere else I should doublecheck, please point me to it. I was finally able to make a new cert & private key without typos, and the results are the same: I can login via wfreerdp but Windows RDC shows me the (new) certificate then dies when I hit "yes" to continue. Just in case, I've also run window's wfreerdp's output looks the same as above, but with a different certificate details to confirm it's seeing the new certificate. including back-to-back /etc/xrdp/phase2_cert.pem /etc/xrdp/phase2_key.pem I don't see how to get a version # for RDC/mstsc, but my version of Windows is now |
|
I've just loaded your cert and key above, with the following settings in xrdp.ini on Ubuntu 20.04 running an xrdp 0.9.15 build. They look much the same as yours except the Connecting with IP address works as expected, so there's nothing wrong with your cert. Winver reports what you've got above. If I right-click on I don't have an Arch VM to hand, but I've just updated a Manjaro one, and that supports connecting via IP with no problems. There's one weird thing in your freerdp log which I don't understand:- This can be sent from the server to the client when the user logs off. However, we don't actually support this message in xrdp - the code to send this PDU is commented out at the moment. So I don't understand where this can have come from. In brief, I'm out of ideas at the moment as I seem unable to reproduce this. |
|
I tried with tls_ciphers uncommented, no change. I also confirmed I have the same version of Thanks for going through all this with me. As everything seems to match and you are unable to duplicate, my next step is to check the MS self-diag logs. Then I will take this to them and see if they have any suggestions why the TLS connection would die. If I get really bored, I may check whether the Arch AUR repo has that error message un-commented out somehow 😁 It claims to be xrdp version 0.9.15, but maybe it's on the wrong branch or had some tweaks afterwards, or something? I will close this for now, until/unless I am able to locate the cause in this repo. |
I'm using xrdp as a server on a Archlinux box, and was able to connect successfully from my Win10 machine until April 1 (strangely enough).
As far as I'm aware, nothing changed on either machine at the time; I have since updated the server box and rebooted both machines. The issue has persisted.
The Win10 "Remote Desktop Connection" client shows a name mismatch on the security certificate, as usual--I'm connecting by ip address, and it says the name on the certificate is www.xrdp.org --but when I hit 'Yes' to complete the connection, I get an error "This computer can't connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator." When I hit 'OK' there, I'm back to the initial RDC screen.
systemctl status xrdp-sesman
that looks like sesman never sees a connection...
systemctl status xrdp
I'm assuming the last errors here are relevant, but google hasn't been of much help finding any similar issues.
(The first two "unknown tag" errors also showed up when everything was working, so I'm assuming they're not related.)
Here's the full xrdp.log from the related time period:
I've tried with UFW enabled and disabled, no difference. Since the above log says the TLS connection was made, I'm assuming it's not a network issue.
xrdp.ini
I'm not sure where to go from here. Is it possibly an encryption failure somehow?
I'll be happy to post additional settings or logs if they would be useful.
The text was updated successfully, but these errors were encountered: