Invalid user prp

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
misdemo.temple.edu

I ran this command:

creating new virtual host with this command:
<VirtualHost *:443>
ProxyPreserveHost on
SSLProxyEngine on

ProxyPass /rentzen/ https://127.0.0.1:8222/
ProxyPassReverse /rentzen/ https://127.0.0.1:8222/

ProxyPass /rentzen https://127.0.0.1:8222/
ProxyPassReverse /rentzen https://127.0.0.1:8222/

<Location /rentzen>
RewriteCond /rentzen/(.*) https://127.0.0.1:8222/$1
</Location>

It produced this output:

Apache restart fails - the output is in this journal

– Subject: Unit httpd.service has failed
– Defined-By: systemd
– Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

– Unit httpd.service has failed.

– The result is failed.
May 22 09:00:30 misdemo.temple.edu systemd[1]: Unit httpd.service entered failed state.
May 22 09:00:30 misdemo.temple.edu systemd[1]: httpd.service failed.
May 22 09:00:30 misdemo.temple.edu polkitd[1395]: Unregistered Authentication Agent for unix-process:83885:15922506 (system bus name :1.820,
May 22 09:00:35 misdemo.temple.edu sshd[83916]: Connection from 123.206.103.61 port 56552 on 129.32.84.223 port 22
May 22 09:00:36 misdemo.temple.edu sshd[83918]: Connection from 213.32.78.219 port 38776 on 129.32.84.223 port 22
May 22 09:00:36 misdemo.temple.edu sshd[83916]: Invalid user prp from 123.206.103.61 port 56552
May 22 09:00:36 misdemo.temple.edu sshd[83916]: input_userauth_request: invalid user prp [preauth]
May 22 09:00:36 misdemo.temple.edu sshd[83916]: pam_unix(sshd:auth): check pass; user unknown
May 22 09:00:36 misdemo.temple.edu sshd[83916]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.
May 22 09:00:36 misdemo.temple.edu sshd[83918]: Address 213.32.78.219 maps to ip-213-32-78.eu, but this does not map back to the address - P
May 22 09:00:36 misdemo.temple.edu sshd[83918]: Invalid user sei from 213.32.78.219 port 38776
May 22 09:00:36 misdemo.temple.edu sshd[83918]: input_userauth_request: invalid user sei [preauth]
May 22 09:00:36 misdemo.temple.edu sshd[83918]: pam_unix(sshd:auth): check pass; user unknown
May 22 09:00:36 misdemo.temple.edu sshd[83918]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=213.
May 22 09:00:39 misdemo.temple.edu sshd[83916]: Failed password for invalid user prp from 123.206.103.61 port 56552 ssh2
May 22 09:00:39 misdemo.temple.edu sshd[83918]: Failed password for invalid user sei from 213.32.78.219 port 38776 ssh2
May 22 09:00:39 misdemo.temple.edu sshd[83916]: Received disconnect from 123.206.103.61 port 56552:11: Bye Bye [preauth]
May 22 09:00:39 misdemo.temple.edu sshd[83916]: Disconnected from 123.206.103.61 port 56552 [preauth]

My web server is (include version):

Server version: Apache/2.4.6 (Red Hat Enterprise Linux)

The operating system my web server runs on is (include version):

Red Hat Enterprise Linux Server release 7.7 (Maipo)

My hosting provider, if applicable, is:
NA

I can login to a root shell on my machine (yes or no, or I don’t know):
yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 1.4.0

***** More detail

So … I recognise that this is probably off topic. I am trying to set up proxy/forwarding so that I can run a nodejs api on a specific port, but then get to that port over https.

question 1 - My big question is this user somehow related to let’s encrypt? - prp
question 2 - Is this IP address relevant to let’s encrypt? - 123.206.103.61

I am asking for answers to those 2 questions.
I’ll understand if this forum is unable to help me further…

I have done this sort of thing successfully over http - but adding in the element of https is tripping me up.


1 Like

LE doesn’t use usernames in their requests; much less to port 22.
So, no, to both of your questions.

1 Like

Wee! I got it. So my problem had a couple dimensions to it.

The big thing is that I ended up having to add a Location tag to the existing ssl.conf file. The incoming https requests were being picked up there… not in the conf file I was editing. (This was the “oh duh” moment for me.)

I left everything in the existing ssl.conf unchanged and added this in at the end:

<Location /rentzen>
    ProxyPass "http://127.0.0.1:8222"
    SetEnv force-proxy-request-1.0 1
    SetEnv proxy-nokeepalive 1
</Location>

Works. Note no ProxyPass reverse, and no rewrite… just look for the incoming path and if you see it… send the request over to the local port.

Happy times…