What does HackerNews think of sslh?

Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)

Language: C

Another option is an ssh/https multiplexer like sslh: https://github.com/yrutschle/sslh

It allows you to listen for https and ssh traffic on a single port.

Another option for that is sslh [1] Running https + ssh + vpn all on port 443 at the same time.

[1] - https://github.com/yrutschle/sslh

most the engines out there weren't made for security but performance. It's disturbing and relaxing at the same time to see how easy it is to bypass them. Something that works 100% is to multiplex a channel, changing it protocols after some packages. You do the SSL handshake, than after some amount of time, you switch it to SSH, I think something like that https://github.com/yrutschle/sslh (couldn't find the real repository that I used, but that one looks similar) could be used after the detection to bypass filters
Does this help?

https://github.com/yrutschle/sslh

"sslh accepts connections on specified ports, and forwards them further based on tests performed on the first data packet sent by the remote client."

I still think they should have used layer 4 CDN endpoints that use generic names on several of the CDN providers that support L4. It would be endless whack-a-mole to block that. Not perfect, but not perfect is probably useful enough for those impacted by blocks as it would mean periodic latency vs. being locked out entirely. Moxie, if you are reading this, to mitigate some of the probing or fingerprinting, consider borrowing some of the code from sslh [1] and I acknowledge this would be an endless arms race.

[1] - https://github.com/yrutschle/sslh

Suggestion to the folks in China: Consider using a combination of port knocking and conditional DNAT's in iptables, so that legit sources port knocking with the right key will go to shadowsocks and probes will go to something that could be mistaken as it, but is harmless in the eyes of those managing the GFW.

There is a tool that does something similar, SSLH [1], that will route SSH, HTTPS and VPN traffic to the right daemon. Similar idea, different implementation. Perhaps you could contact the author and have them add support for Shadowsocks. Then have two daemons, the legit Shadowsocks, and a dummy daemon that is something else. Perhaps even get the devs for SS and SSLH to brainstorm together on this.

[1] - https://github.com/yrutschle/sslh

Well, it's hard to get a DNS response when you aren't talking to a DNS server...

So, yeah, I can serve up DOH on my own server with a custom endpoint, custom client configuration, and generate cover traffic. But that's not exactly easy. And http doesn't help: I can do that without http, something like https://github.com/yrutschle/sslh, or using SNI (which, as of TLS 1.3, is encrypted).

And merely saying something is impossible doesn't make it so. It doesn't even make it hard.

Disclaimer: Using the following methods could be seen as bypassing the intent of the port restrictions set by your org.

I commit to github using ssh on port 443.

    # git remote set-url origin git@:/
From ~/.ssh/config

   Hostname ssh.github.com
    Port 443
    User git
    IdentityFile ~/.ssh/.github
Consider using Dovecot on your mail server for port 443. I was not aware that Discord stopped supporting websockets over 443. I run my own Mumble voice chat server so I can put it on 443, but I understand people have a lot of friends on Discord. I am just not happy with their chat logging policy [0].

You could also run a proxy or VPN on port 443. You can also use sslh [1] to have SSH+SSL+Proxy+VPN all on the same port 443. You can do similar things using HAProxy + SNI + SSL, but that is a bigger subject.

For other things that must use other ports or protocols, you can sometimes wrap them using tsocks [2] in your VPN or SSH tunnels to port 443.

[0] - https://blog.discordapp.com/how-discord-stores-billions-of-m...

[1] - https://github.com/yrutschle/sslh

[2] - https://www.redpill-linpro.com/sysadvent/2015/12/13/socks-pr...

With sslh you can use port 443 for both tinc and https. https://github.com/yrutschle/sslh

Also you can configure haproxy to do the same.

HTTPS is mostly allowed so why not use port 443 for ssh or something like sslh? https://github.com/yrutschle/sslh.
sslh [1] (which is packaged and included in may linux and BSD distributions) has grown to support HTTP, SSL, SSH, OpenVPN, tinc, XMPP from the same port. It claims it can be extended to filter anything that can match with a regex.

What I find lacking lately is I've mostly wanted to extend the forwarding/routing of ssh connections based on username (or better by identity) to different VMs or hosts, but I have no idea how to achieve that at the moment (without creating dummy users on the sshd server).

[1] http://www.rutschle.net/tech/sslh.shtml

Github: https://github.com/yrutschle/sslh

From the repo the project creator linked in the README (https://github.com/yrutschle/sslh): "A typical use case is to allow serving several services on port 443 (e.g. to connect to SSH from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port."