sslh 2.0 crashes abit after execution.
JoshuaPettus opened this issue · comments
I just tried the 2.0 version. When running, it will crash after a few seconds
I'm using Ubuntu 22.04 and it was working with 1.22c
Ive tried both sslh-select and sslh-ev
I put in the new logging commands and got this:
common.c:268:matching [cloud.domain.com] with [turn.domain.com]
sprintaddr:getnameinfo: Temporary failure in name resolution
sprintaddr:getnameinfo: Temporary failure in name resolution
common.c:268:common.c:268:
I suspect I have the wrong options chosen in the makefile
ENABLE_SANITIZER= # Enable ASAN/LSAN/UBSAN
ENABLE_REGEX=1 # Enable regex probes
USELIBCONFIG=1 # Use libconfig? (necessary to use configuration files)
USELIBWRAP?= # Use libwrap?
USELIBCAP= # Use libcap?
USESYSTEMD=1 # Make use of systemd socket activation
USELIBBSD?= # Use libbsd (needed to update process name inps)
COV_TEST= # Perform test coverage?
PREFIX?=/usr
BINDIR?=$(PREFIX)/sbin
MANDIR?=$(PREFIX)/share/man/man8
On that note what do the question marks mean after some options?
Thank you!
I see nothing wrong with the options. The question marks mean "set if there is not already a value", which makes it possible for a distribution maintainer to e.g. always set USELIBWRAP and the Makefile won't touch it. I am honestly not sure that's a good idea, or used by anyone.
common.c:268 would suggest sslh is trying to bind the peer side of the socket to perform transparent proxying. It's odd that you're not getting the actual error message. Do you see anything in the logs? (usually that would be /var/log/auth)
Also, do you have transparent on, and if yes does it work if you turn it off?
Thank you! I did have it on. It does seem to work when I have it off. Unfortunately I do need it for fail2ban, and probably somewhere else.
I did find the actual error in the journal
Aug 31 16:31:41 JoshServ sslh-ev[1062800]: setsockopt IP_TRANSPARENT: Operation not permitted
Very strange that it complains about that now, as it worked before.
Oh! in my config file I have it running as the sslh user. Taking that out to make it run as root will make it run with transparency. I generally don't like to run services as root, is there a way I can give the service user the specific permission?
Still very weird that it worked before...
Yes, it's definitely ungood that it would work as root.
Like you say, it's weird that it worked before and no more: what version were you running? I don't think any of the transparent, or the privilege dropping, code, has changed in years. If you were using Ubuntu's package, maybe it sets something differently from the build from source?
Another direction: did you coincidentally change kernel version or iptable rules? What bothers me here is that `setsockopt() is not supposed to return EPERM, according to the manual page I have here (the errors I see listed actually do justify killing the process: invalid file descriptor, unknown option, ... so, they would only occur in case of a bug in sslh, which is not the case here), so I wonder if maybe the kernel changed behaviour (unlikely), but I see Netfilter can also set return values.
oh, more likely, exerpt from config.md:
On Linux (only?), you can compile sslh with `USELIBCAP=1` to
make use of POSIX capabilities; this will save the required
capabilities needed for transparent proxying for unprivileged
processes.
Alternatively, you may use filesystem capabilities instead
of starting sslh as root and asking it to drop privileges.
You will need `CAP_NET_BIND_SERVICE` for listening on port 443
and `CAP_NET_RAW` for transparent proxying (see
`capabilities(7)`).
You can use the `setcap(8)` utility to give these capabilities
to the executable:
sudo setcap cap_net_bind_service,cap_net_raw+pe sslh-select
Then you can run sslh-select as an unprivileged user, e.g.:
sslh-select -p myname:443 --ssh localhost:22 --tls localhost:443
=> I see you do not have LIPCAP, maybe you ran setcap on the executable years ago and lost that in the build?
sslh-select -p myname:443 --ssh localhost:22 --tls localhost:443
You may try the ENABLE_SANITIZER=1 option and upload the printed sanitizer callstack. That'll make it more easy to find the cause of the crash.
oh, more likely, exerpt from config.md:
Son of a gun, that was it! I really need to make notes for myself (knew I was forgetting something at the config stage). SSLH has been so reliable I don't generally touch it often :)
You may try the
ENABLE_SANITIZER=1option and upload the printed sanitizer callstack. That'll make it more easy to find the cause of the crash.
Thank you! That is actually a good to know! I was playing with the new resolve_on_forward option but having some trouble and need to do a lot more digging before I open another ticket.