On a second look it seems you are trying to use these tools designed for a client from your server "myserver
". My answer covers the situation where you are using them on the client, "mymachine
".
The documentation for this sshuttle
project seems rather unorthodox: even the How it works article tells only what it does. It compares the project to other tools mainly by telling how it doesn't work: it's not "like" a SSH port forward but it's not "like" a "stupid/complex VPN" either. Apparently the author seems to think he has invented something all new and of course better than anyone else has before.
What we can tell based on short read through of the documentation (requirements, usage) is that it
- can proxy all traffic to the other side, using
iptables
(NAT) or recmsg
(TPROXY)
- doesn't need admin access on the remote server, but root access on the client machine
- utilizes Python on both ends.
Based on that, also SSH to the remote side might get proxied, but that shouldn't matter, because you can probably ssh
from the remote server to itself using the external IP address; it doesn't make any difference from which side of the tunnel the connection originates.
I don't know what you are trying to do with your alternative solution as it's not even trying to achieve the same results than the first one. However, you can't bind to local port 22
unless you are root and there isn't sshd
already listening. Even if you succeed, I can't see how this adds anything useful. But, to answer the question: yes, you can still ssh
to remote:22
(+ the local port forwarded).