Hi - I have a sudden and intermittent issue where users are unable to authenticate into RStudio server on a domain joined RHEL7 VM. The login page is displayed to enter credentials, but after a long period of "Waiting for my_VM_hostname..." the attempt times out and the error below is shown. The issue occurs with both AD and local user accounts. Really appreciate help with figuring this out. Info below
Error shown in chrome window
This page isn’t working
my_hostname didn’t send any data.
ERR_EMPTY_RESPONSE
RStudio server version
1.2.1335
sessionInfo()
R version 3.5.3 (2019-03-11)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux Server 7.6 (Maipo)
I can wget localhost:443 and server-ip:443 Where rstudio server listens
I tried putting it on port 80 instead just to see what happens. Trying both methods above I can still wget the login page, however now I am unable to reach the login page from the company laptop [EDIT: I forgot to open the VM firewall when testing on port 80; this actually did work]. Not sure if this sheds light on the issue or may be an unrelated issue, so I change it back to 443.
ALSO, I am able to log in from on-site and from my phone/mobile-app. This must be some sort of VPN issue only affecting laptops. Might this be something I can resolve or get around from my end..?
This is a strange one, and debugging PAM can be tough. It sounds like this is RStudio Server open source, is that correct? In that case, you might download and install pamtester to give you a helpful tool for testing PAM interactively without having to go through the RStudio service. I suspect that is where your configuration is having trouble. pamtester ships with RStudio Server Pro, so you can follow a command like the example here, but the path will be wherever you install pamtester instead. You also may need to use a profile other than rstudio, as well. I think open source might use the login profile? I forget. Actually, it looks like you have an rstudio PAM profile... In any case, the example from the guide:
Yes this is the open source version, and I do have a rstudio file in /etc/pam.d. The OS is RHEL 7.
[localuser@my_hostname~]$ cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.6 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.6"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.6 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.6
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.6"
Pamtester results...This is strange and not sure what to make of it. In both the following cases I am ssh to the VM over my VPN. If I log on using my local/admin account, I get pamtester success passing both my local account and also my AD account ID as the user. However if I am logged on as my AD [non-privileged] user, I am only successful passing the same AD user ID/pw and fails when passing the local user. See below for this example:
I'm not sure if there's anything interesting in that. To be clear, I can access the server with both IDs through the normal browser login, provided I am not attempting from a device connected via VPN. I'm on my VPN right now as I test, so what I do is RDP into an on-prem machine, and then from the on-prem machine I can authenticate through the browser.
When RStudio Server is configured to use SSL the default behavior with respect to ports is:
SSL is bound to port 443 (enabling access using the standard https protocol within the browser)
The server also listens on port 80 and redirects all requests to port 443 (allowing users to specify the domain without the https protocol and be automatically redirected to the secure port)
However, if SSL is bound to another port (using the www-port option) then the automatic redirect behavior is not enabled. It’s also possible to disable automatic SSL redirects entirely using the ssl-redirect-http option as follows:
I have configured this server to listen at port 443, though I don't have ssl enabled. Grasping at straws, might I be confusing the server by putting it on 443?
$ cat rserver.conf
# Server Configuration File
www-port=443
EDIT: By moving the server to port 80 (http) in the config and opening the port on my firewall I am able to access rstudio over VPN.
Yes indeed. In my second post when I moved to port 80, I had apparently forgotten to open the firewall on the machine (sorry). So in fact it would have worked had I tested correctly.
Left unresolved is why it won’t authenticate when on 443 and over VPN. Maybe some issue with TLS/SSL on the VM? Or maybe it is VPN policies affecting the certificates. I’m a mere modeler so it’s all outside my wheelhouse.. thanks for the help!
Glad to hear it is working!! Yeah, it may very well be that the VPN is more strict about port 443, because things listening on 443 without TLS/SSL are "pretending" to do HTTPS. Usually browsers will throw an "Are you sure!? Be careful!!" warning in a user's face for this type of behavior, but it is certainly plausible that a VPN policy would be more restrictive... although the nature of the behavior is quite weird.
In any case, there are lots of ways to set up HTTPS for real! The Professional version of RStudio Server supports HTTPS out of the box, and you can always set up nginx, apache, or some other load balancer in front of the product to terminate the TLS communication if the pro version is not a good fit.
They can try to use proxies for this purpose. Our company extensively uses them to get in touch with foreign clients.
We also use proxies for ad verification because there are too many fake ads and clicks nowadays, so we have to be at least one step ahead of all the frauds. Proxies are an older technology, but they are more reliable and stable than VPNs because they can crash, and proxies work all the time. I am not sure that it will fit you 100%, but it was a great find for us because we use it daily. It’s better for small businesses that have most of their customers abroad.