Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Package Update] sslh to 2.1.4 #6438

Open
lordvandal opened this issue Feb 3, 2025 · 13 comments · May be fixed by #6445
Open

[Package Update] sslh to 2.1.4 #6438

lordvandal opened this issue Feb 3, 2025 · 13 comments · May be fixed by #6445
Assignees
Labels
update request to update existing package

Comments

@lordvandal
Copy link

Software Name

sslh

Brief Description

Please update sslh package from from 1.21-6 (1.21c) to 2.1.4.

Thank you in advance!

There are some changes and enhancements in v2.x (https://github.com/yrutschle/sslh/blob/master/ChangeLog):

v2.0:

New sslh-ev: this is functionally equivalent to
sslh-select (mono-process, only forks for specified
protocols), but based on libev, which should make it
scalable to large numbers of connections.

New log system: instead of --verbose with arbitrary
levels, there are now several message classes. Each
message class can be set to go to stderr, syslog, or
both. Classes are documented in example.cfg.

UDP connections are now managed in a hash to avoid
linear searches. The downside is that the number of
UDP connections is a hard limit, configurable with
the 'udp_max_connections', which defaults to 1024.
Timeouts are managed with lists.

inetd merges stderr output to what is sent to the
client, which is a security issue as it might give
information to an attacker. When inetd is activated,
stderr is forcibly closed.

New protocol-level option `resolve_on_forward`,
requests that target names are resolved at each
connection instead of at startup. Useful for dynamic
DNS situations. (Paul Schroeder/milkpirate)

New probe for MSRDP (akappner).

Website

https://www.rutschle.net/tech/sslh/README.html

Documentation

https://www.rutschle.net/tech/sslh/README.html

Build/Installation documentation

https://github.com/yrutschle/sslh/blob/master/doc/INSTALL.md

Source code

https://github.com/yrutschle/sslh

OpenSource License

GPLv2

Other License

No response

@lordvandal lordvandal added the request request for new package label Feb 3, 2025
@mreid-tt mreid-tt added update request to update existing package and removed request request for new package labels Feb 3, 2025
@hgy59 hgy59 self-assigned this Feb 6, 2025
@hgy59
Copy link
Contributor

hgy59 commented Feb 6, 2025

@lordvandal we already have sslh v1.22c, but it was not published.

I first will update to v1.23.1
The current version 2.1.4 does not compile and might need some patches (or will never be supported for DSM).

hgy59 added a commit to hgy59/spksrc that referenced this issue Feb 6, 2025
- initially update to v1.23.1
@lordvandal
Copy link
Author

@hgy59 I understand and I very much appreciate your help. Thank you for your efforts!

@hgy59

This comment has been minimized.

@hgy59
Copy link
Contributor

hgy59 commented Feb 7, 2025

@lordvandal good news, all issues fixed and successfully created sslh-fork (aka sslh), sslh-select and sslh-ev.

shall we add sslh-select and sslh-ev to the package?

sslh is installed and runs as a service.
we can install all three variants, but only one of them for the service.
shall the package installation wizard ask whether to use sslh-fork (the same as before the update), sslh-select or sslh-ev for the service?
But if so, I guess we need to install different configuration files for each.

@hgy59 hgy59 linked a pull request Feb 7, 2025 that will close this issue
6 tasks
@lordvandal
Copy link
Author

lordvandal commented Feb 10, 2025

Hi @hgy59! That's wonderful! Thank you so much! You're my hero!

Could you please add sslh-select and sslh-ev if possible, to have all variants?
And maybe the wizard could ask which one to use, defaulting to sslh-fork?
Perhaps with the below short descriptions from the sslh install README in the selection dialogue?

The configuration is the same for all of them, so there only needs to be one configuration:

Binaries

The Makefile produces three different executables:
sslh-fork, sslh-select and sslh-ev:

  • sslh-fork forks a new process for each incoming connection. It is well-tested and very reliable, but incurs the overhead of many processes. If you are going to use sslh for a "small" setup (less than a dozen ssh connections and a low-traffic https server) then sslh-fork is probably more suited for you.

  • sslh-select uses only one thread, which monitors all connections at once. It only incurs a 16 byte overhead per connection. Also, if it stops, you'll lose all connections, which means you can't upgrade it remotely. If you are going to use sslh on a "medium" setup (a few hundreds of connections), or if you are on a system where forking is expensive (e.g. Windows), sslh-select will be better.

  • sslh-ev is similar to sslh-select, but uses libev as a backend. This allows using specific kernel APIs that allow to manage thousands of connections concurrently.

@hgy59
Copy link
Contributor

hgy59 commented Feb 10, 2025

Could you please add sslh-select and sslh-ev if possible, to have all variants?

Those are already available in the latest build. You can manually download and install the package created by github build action as artifact.
Just copy sslh-ev over sslh or edit the SERIVCE_COMMAND in /var/packages/sslh/scripts/service-setup after installation.

The next step will be to add an installation wizard to choose the variant to use.
I guess the solution will be to keep the original name of sslh-fork and to create a symbolic link sslh to the variant selected in the wizard at installation time.

@hgy59
Copy link
Contributor

hgy59 commented Feb 10, 2025

@lordvandal latest update provides the wizard.
you can always use a manual update with the same package version to change the service variant.

@lordvandal
Copy link
Author

I did some testing, and so far everything works fine.

I have the following 2 suggestions:

1. Updating /var/packages/sslh/var/sslh.cfg with the new version from https://github.com/yrutschle/sslh/blob/master/basic.cfg, with just changing the username: user: "sc-sslh", as some options have changed:

Starting sslh command /volume1/@appstore/sslh/bin/sslh -F/volume1/@appdata/sslh/sslh.cfg
Unknown settings:
/verbose:1
/timeout:5

2. Adding https://github.com/yrutschle/sslh/blob/master/example.cfg to /var/packages/sslh/var/, as (according to it) it is provided as documentation to show what is possible, and it contains lots of advanced configuration examples.
Probably the username change (user: "sc-sslh"`) would be useful - just in case.

@hgy59
Copy link
Contributor

hgy59 commented Feb 10, 2025

Unknown settings:
/verbose:1
/timeout:5

@lordvandal
I already removed those from sslh.cfg in the latest release.
On package updates the installed files in the var folder are always kept.
There is no update of the config file, but you find the updated version as sslh.cfg.new

The current config is almost the same as the basic example.

  • don't know why basic also have the unsupported timeout configured
  • package uses port 30000 instead of 443 (I guess to avoid conflicts with webstation, and DSM 7 prohibits the use of root i.e. privileged ports)
  • listening on ipv6 is removed
  • user, pidfile and logfile are defined for synology DSM integration

additionally I added the logging configuration taken from the example config (adjusted to use logfile only and to log config at startup) - this seems the replacement/refinement of the former verbose setting

the detailed log shows:

Landlock: not built in
capabilities: =

Do we need Landlock or additional capabilities?

@lordvandal
Copy link
Author

@hgy59 variant selection works as a charm, tested.

We don't need Landlock, as it's one of the Linux Security Modules, and I believe it's not our concern on Synology.

@hgy59
Copy link
Contributor

hgy59 commented Feb 10, 2025

We don't need Landlock, as it's one of the Linux Security Modules, and I believe it's not our concern on Synology.

Yes, synology toolchains do not support it

checking for linux/landlock.h... no

@hgy59
Copy link
Contributor

hgy59 commented Feb 10, 2025

and capabilities seem to work:

when configuring transparent: true;
and enabling capability with sudo setcap cap_net_raw+pe /var/packages/sslh/target/bin/sslh-ev

the log shows:

capabilities: cap_net_raw=ep

setcap does not work with symbolic link sslh, but the real service works when started as link.

Since sllh is not started under root, the capabilities must be set manually before.

@lordvandal
Copy link
Author

Yes, indeed, just checked. Cool, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
update request to update existing package
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants