Conversation
Pull request sshuttle#502 made -r/--remote required. However, the documentation still indicates that using no remote is a valid way to test sshuttle (see Examples section of man page). I think this mode might be useful for testing performance local without ssh, local with ssh, and remote with ssh. This patch adds a warning when -r/--remote is missing but restores the previous behavior.
brianmay
left a comment
brianmay
left a comment
There was a problem hiding this comment.
I am a bit unclear - what does happen if you start sshuttle without a remote? Does it still call ssh?
|
If you run sshuttle without a remote, it starts both the server and the client locally without ssh. Instead of the socketpair connecting the client and ssh, it connects the client and the server together directly. In this mode, it continues to set up the firewall to route traffic to the client. Therefore, it can work with only one machine and without ssh (and provides no security benefits). Line 112 in a266e7a There is no good reason to run sshuttle this way besides testing. For testing, it can be handy if you are making modifications to the client and server and wish to confirm that it works without having to repeatedly set up an SSH connection after every change. Similarly, it may also help with future performance testing because it gives the option of running sshuttle without ssh or a network. Since it is only useful for testing, it makes sense to warn users when they run it this way. If people accidentally forget -r but sshuttle runs as expected, they may think that their traffic is being securely routed through a remote host that they wished they had provided. Issue #455 has a couple of examples of this (although at that time, the error message sshuttle printed wasn't helpful). I suppose another option would be to add a --testing-local argument and only allowing sshuttle to run in this mode when that argument is supplied. That would require a different patch and a documentation update. |
|
Does running sshuttle without a remote implicitly use/require the TTL hack? See #240. I guess I would like to remove this hack, and don't want particularly want to add code that requires it... |
|
Yes, but isn’t the ttl hack needed as long as the user can use “-r localhost” (and variations thereof)? It seems that no matter what we do, we need to determine if client and server are on the same machine to either exit with a clear error message (as you seem to suggest) or to automatically enable the hack only when it is needed (my preference, with clear feedback to the user about it). I agree that using the ttl hack when client and server are on different machines isn’t great. |
2 participants
Pull request #502 (issue #455) made -r/--remote required. However, the
documentation still indicates that using no remote is a valid way to
test sshuttle (see Examples section of man page). I think this mode
might be useful for testing performance local without ssh, local with
ssh, and remote with ssh.
This patch adds a warning when -r/--remote is missing but restores the
previous behavior.