Hey @stokito,

While I greatly appreciate the idea and effort you put into this, I think it significantly increases the complexity of the list. I've already considered dropping the overlay network section altogether for the same reason.

Additionally, while many of the SSH-based solutions can be used with a plain SSH client (which I see as the main benefit of breaking it in to a separate section), not all of them can. In some cases SSH is just an implementation detail.

Well, as for me it simplifies the list. I specifically looked for SSH service and in future maybe to deploy my own. I working on self hosting on routers with OpenWrt. So for the routers with small disk of 16mb or even 4mb any other tunnel will be too bloat because they usually are written in Golang and their size starts at 17mb. But SSH clients already exists in all such routers.

The section also groups articles about the SSH tunnel into one place.

considered dropping the overlay network section altogether for the same reason.

Please don't do that. The overlay networks are probably the best option for everything else.

More sublists is actually really helpful and doesn't hurt complexity. There's a reason for why all awesome lists use them!

Any updates?

Hi @Pandapip1. No plans to merge this. As I mentioned above I'm pretty sure not all the SSH options will work with generic SSH clients. At the very least they would all need to be tested. For any that are verified to work so, I'm happy to accept PRs that mention that in the entry for the specific tool. If enough of them are confirmed to work this way, I would consider accepting a PR to move them to a separate section.

Looks like @stokito is maintaining his fork, so if you prefer separated sections you can probably follow his list directly.

Looks like @stokito is maintaining his fork, so if you prefer separated sections you can probably follow his list directly.

If you're not maintaining this repository, could you please archive it?

not all the SSH options will work with generic SSH clients. At the very least they would all need to be tested.

Why are you care that much about stability of the approach? If anything doesn't work it's a problem of users and developers. Currently there are not so many of SSH clients and de facto it's almost always OpenSSH (even in Windows).

There is also DropBear's dbclient used in some embedded systems and it indeed lacks of some tunneling features (e.g. dynamic port forwarding via SOCKS) but still it's used successfully for port forwarding and as a basic VPN in OpenWrt routers.

I personally sent a few PRs to the DropBear to improve it's compatibility with OpenSSH. Also I improved sshtunnel package for OpenWrt so that it can work with the dbclient instead of a bigger openssh-client. I also added a GUI for OpenWrt admin panel (luci-app-sshtunnel).

You see, literally almost every server has OpenSSH. And with NetworkManager-ssh plugin anyone can easily configure a VPN with a GUI. Without any need to set up any additional software on a server. The SSH also not blocked by most firewalls which makes it working in countries who protects their citizens. Still DPI can detect TLS over SSH but usually they just making the connection slow. Then you'll feel uncomfortable to watch videos or download something but at least you can work in console or expose your local HomeAssistant.

If we are talking about stability of SSH tunnel providers then here things aren't that good but definitely not bad.
Services like localhost.run or ssh-j.com are working for a long period but the market for them is not that big yet.
One of the main reason is that many users simply don't know about them or they struggled to configure an SSH tunnel.
And your awesome list is exactly the best place where they can learn about this when they doing a research.

The SSH has drawbacks but still this is a number one option for tunneling.

Please, don't worry about complexity - each solution was created because of some reason. People really want to see more options. If they came to the list then they already looking for many options.

I'll update the PR to resolve a conflict. Almost all the SSH options that I added I checked myself and they works.

not all the SSH options will work with generic SSH clients. At the very least they would all need to be tested.

Why are you care that much about stability of the approach? If anything doesn't work it's a problem of users and developers. Currently there are not so many of SSH clients and de facto it's almost always OpenSSH (even in Windows).

There is also DropBear's dbclient used in some embedded systems and it indeed lacks of some tunneling features (e.g. dynamic port forwarding via SOCKS) but still it's used successfully for port forwarding and as a basic VPN in OpenWrt routers.

I personally sent a few PRs to the DropBear to improve it's compatibility with OpenSSH. Also I improved sshtunnel package for OpenWrt so that it can work with the dbclient instead of a bigger openssh-client. I also added a GUI for OpenWrt admin panel (luci-app-sshtunnel).

You see, literally almost every server has OpenSSH. And with NetworkManager-ssh plugin anyone can easily configure a VPN with a GUI. Without any need to set up any additional software on a server. The SSH also not blocked by most firewalls which makes it working in countries who protects their citizens. Still DPI can detect TLS over SSH but usually they just making the connection slow. Then you'll feel uncomfortable to watch videos or download something but at least you can work in console or expose your local HomeAssistant.

If we are talking about stability of SSH tunnel providers then here things aren't that good but definitely not bad. Services like localhost.run or ssh-j.com are working for a long period but the market for them is not that big yet. One of the main reason is that many users simply don't know about them or they struggled to configure an SSH tunnel. And your awesome list is exactly the best place where they can learn about this when they doing a research.

The SSH has drawbacks but still this is a number one option for tunneling.

Please, don't worry about complexity - each solution was created because of some reason. People really want to see more options. If they came to the list then they already looking for many options.

I'll update the PR to resolve a conflict. Almost all the SSH options that I added I checked myself and they works.

@stokito not sure we're talking about the same thing. What I'm saying is that if we're going to have a separate category for tools that only require a generic SSH client, we need to be sure every tool in that section of the list works that way. For example, in this PR you added chisel to the SSH section, but as near as I can tell chisel requires you to use their client, because the fact it's based on SSH is an implementation detail. So if you're including tools like chisel in that section, I'm not sure I understand the purpose of the section.

Looks like @stokito is maintaining his fork, so if you prefer separated sections you can probably follow his list directly.

If you're not maintaining this repository, could you please archive it?

Sorry, didn't mean to suggest I'm not maintaining this list. I am, though I'm quite a bit behind at the moment. What I was trying to say is that @stokito has a version of the list that's formatted the way you want and it's currently maintained, so that seems like it would be a better fit for you.