Force reset connection about sish HOT 10 OPEN

The 'force' feature proposal (or any other way to guarantee a subdomain for the tunnel) seems to serve a very practical use case.

As per the discussions, it would be particularly beneficial for long running tunnels where there are many potential variables that could lead to a connection breakdown (like network issues, timeouts, system restarts etc.). After such a breakdown, on reconnection, there's a chance that the subdomain may not reliably be the same as before if another connection took over that subdomain in the mean time. This becomes a challenge for maintaining a consistent connection point for incoming traffic.

The --force option would make sure that a particular subdomain can always be reclaimed by the same connection upon a restart, thereby guaranteeing a stable connection point. This is particularly useful for automated scripts and would enhance the reliability and predictability of the connections.

from sish.

Hi @adhikjoshi ,
What you proposed would be a great thing.
It would solve my problem stated in:

#275

For example:

ssh -p 2222 -R mysubdomain:80:localhost:8080 sish.mydomain.it -force

The flag should clear any references to the subdomain in sish and make it available again when the tunnel is created.
This would be really useful when using sish in automatic scripts to avoid connection problems

We hope that @antoniomika implements this feature.

A thousand thanks

from sish.

Unfortunately, I don't particularly see the value in this feature. Properly set timeouts and tuned ssh connection settings (ping intervals) should be enough to solve for the automated sentinel usecase (that's what I do). Mind describing the use cases a bit more?

Just because it's something I don't see the value in doesn't mean I wouldn't accept a contribution for this!

from sish.

Hi @antoniomika
Unfortunately I'm not a go developer and I can't help you implement new features.
But if you need I can help you test the application, as I use it all the time and it solves a lot of teamworking problems for me.

I commented positively on the request of @adhikjoshi because I have the problem described in #275

I thought a flag that forced the connection was a good idea to solve the issue because it occurs randomly and is certainly difficult to debug.

Unfortunately the only way I have found to solve the problem now is to restart the sish server to clean and reconnect the subdomains that sish says are incorrectly already occupied.

My use case would be: for subdomains that are fixed and the connection to sish is handled via systemd script, one could use the -force flag to completely clean the connection and re-establish it again, bypassing the flags set server side

I'll write you an example of a systemd service that I use to connect to sish automatically and which often gives me the problem of a subdomain already used:

[Unit]
Description=Sish-test
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=ubuntu
Group=ubuntu
Restart=always
RestartSec=10
ExecStart=ssh -p 2222 -R mysubdomain:80:localhost:8080 sish.mydomain.com

[Install]
WantedBy=multi-user.target

With the introduction of the -force flag it would become:

ExecStart=ssh -p 2222 -R mysubdomain:80:localhost:8080 sish.mydomain.com -force 

or, in case of tcp tunnel:

ExecStart=ssh -p 2222 -R 2233:localhost:22 sish.mydomain.com -force

Furthermore, you could use a --permit-force-reconnect=true flag in sish server that enables or disables the client-side forced reconnect functionality (perhaps disabled by default and enabled only for specific cases, for example to handle this automatic use case where the subdomain and port are fixed and must always connect in any case)

Thank you.

from sish.

@manprint can you post your sish config/cli args you're using? We should be able to get your experience in a good place without that feature.

I use a similar setup (using autossh) and defined ping intervals and never have issues even with spotty networks.

from sish.

Hi @antoniomika
This is my configuration for sish server.

Are there any parameters I can change to avoid this issue?

Thanks

docker run -itd --name sish \
	-v $(pwd)/keys:/keys \
	-v $(pwd)/pubkeys:/pubkeys \
	-v $(pwd)/logs:/logs \
	--restart=always \
	-p 2222:2222 \
	-p 45000:45000/tcp \
	--log-driver=json-file \
	--log-opt max-size=5m \
	--log-opt max-file=2 \
	--log-opt compress=true \
	--network=adiprint-network \
	antoniomika/sish:v2.9.2 \
	--ssh-address=:2222 \
	--http-address=:80 \
	--https=true \
	--authentication-keys-directory=/pubkeys \
	--private-keys-directory=/keys \
	--tcp-aliases \
	--bind-random-aliases=false \
	--bind-random-ports=false \
	--bind-random-subdomains=false \
	--bind-any-host \
	--bind-root-domain \
	--force-requested-aliases \
	--force-requested-ports \
	--force-requested-subdomains \
	--authentication-password= \
	--domain=sish.mydomain.it \
	--idle-connection=false \
	--idle-connection-timeout=3600s \
	--cleanup-unauthed \
	--cleanup-unauthed-timeout=60s \
	--cleanup-unbound \
	--cleanup-unbound-timeout=60s \
	--ping-client=true \
	--admin-console \
	--admin-console-token=mytoken \
	--verify-ssl=false \
	--service-console-max-content-length=0 \
	--log-to-client \
	--log-to-file \
	--log-to-file-max-backups=5 \
	--log-to-file-max-size=5 \
	--log-to-file-max-age=7 \
	--log-to-file-path=/logs/sish.log \
	--log-to-stdout=true

from sish.

Is there a reason you've set your idle timeout to such a long duration?

from sish.

Because I would like the connection to remain open while transferring large files via webdav.
Maybe I misunderstood what this parameter is for.
Should I remove it and leave the default values?

from sish.

Is there a reason you've set your idle timeout to such a long duration?

For our usecase, tunnel is permanent and will be running for months. So there will be many network, timeout, restart issues.

If we can reset and open again on same URL. We can keep it alive for months.

from sish.

Sure, but a restart of the tunnel should establish the connection again. And as long as your ping intervals are set correctly, you shouldn't actually need to "force" reclaim the forward/bind. I'm going to close the other issues around this topic and leave this one if anyone (or I have the time) to implement it.

from sish.