If you check the man page for ssh, you'll find that the syntax for -R reads:
When bind_address is omitted (as in your example), the port is bound on the loopback interface only. In order to make it bind to all interfaces, use
ssh -R \*:8080:localhost:80 -N email@example.com
ssh -R 0.0.0.0:8080:localhost:80 -N root@...
-g works for local forwarded ports, but what you want is a reverse/remote forwarded port, which is different.
What you want is this.
Essentially, on example.com, set GatewayPorts=clientspecified in /etc/ssh/sshd_config.
--- previous (incorrect) answer ---
Use the -g option. From ssh's man page:
-g Allows remote hosts to connect to local ...
METHOD 1 (use ssh-key on inter)
If you want to retain the authentication flow
local -- authenticate --> inter -- authenticate (ask password) --> final
This cannot be done with .ssh/config proxyhost.
What you need is bash shell alias (I hope you are using bash).
In ~/.bashrc, add following line
alias ssh-final='ssh -t inter ssh firstname.lastname@example.org'
This has already been answered best here.
put the following in ~/.ssh/config
ProxyCommand ssh email@example.com nc %h %p 2> /dev/null
and then simply scp to target.machine any time you want to proxy via proxy.machine!
Also works for ssh, so will save you ...
not exactly the solution for your problem, but also handy sometimes:
From within an ssh session:
type ~ and then #
shows you a list of all open connections over your tunnels for that session.
Can be achieved transparently with this snippet in ~/.ssh/config:
ProxyCommand ssh -D 3128 localhost nc -q 1 localhost 22
RemoteForward 3128 localhost:3128
ProxyCommand ssh -W target:22 sockstunnel
We want a reverse DynamicForward. This is achieved using two ssh commands:
ssh -D 3128 localhost
ssh -R ...
Here's my answer for completion:
I ended up using ssh -R ... for tunneling, and using socat on top of that for redirecting network traffic to 127.0.0.1:
tunnel binded to 127.0.0.1:
ssh -R mitm:9999:<my.ip>:8084 me@mitm
mitm$ socat TCP-LISTEN:9090,fork TCP:127.0.0.1:9999
Other option is to do a local-only tunnel on top of that, but i find ...
To set up a SSH tunnel, use the following format:
ssh -L 9999:host2:22 user@host1
This command connects to host1 as user and tunnels port 9999 on the computer issuing the command to port 22 on host2. -N is optional, or you can use something like top or watch to keep the session alive if needed.
Then, simply scp to host2 on localhost:9999.
Yes. Goto Extras->Options->General ...click on "Configure" for proxy settings. Change to manual proxy and for Proxy IP enter socks5://127.0.0.1 and the port you are using. Obviously change the 127.0.0.1 to whatever IP you are wanting to use.
You can also use a double forward if you won´t or can change /etc/ssh/sshd_config.
First forward to temporary port (e.g. 10080) on loopback device on the remote machine, then use local forward there to redirect port 10080 to 80 on all interfaces:
ssh -A -R 10080:localhost_or_machine_from:80 firstname.lastname@example.org "ssh -g -N -L 80:localhost:10080 localhost"
If it wasn't created with multiplex enabled, you cannot.
Next time, start the background session like this:
ssh -f -N -M -S ~/.ssh/S.email@example.com -D 9000 firstname.lastname@example.org
Here -M enables multiplex master mode, and -S sets the socket path.
Now you can use ssh -S ~/.ssh/S.email@example.com dummyhost to open a second session over the same connection. It's ...
In case anyone else finds this, there is a work around... you just need to reformat the tunnel with a specific bind address like this:
ssh -L 127.0.0.1:8022:220.127.116.11:22 firstname.lastname@example.org
From reading through the bug listing linked in the other answer, it looks like the issue is in the IPv6 subsystem, so I'm guessing this works by forcing IPv4.
Since OpenSSH 7.3, you can use -J or -o ProxyJump to specify the bastion/jump host. Therefore, to SSH to node2 via node1:
ssh -J you@node1 you@node2
SCP doesn't have the -J argument, but it does allow -o, so this works:
scp -o ProxyJump=you@node1 file.txt you@node2:~
Yes, if I understand it correctly, local port forwarding from a to b should be identical
to remote port forwarding from b to a (and vice versa). An outgoing tunnel from a to b (viewed from a) should be equal to an incoming tunnel from a to b (viewed from b).
Local port forwarding creates an outgoing tunnel which can be used to bring a public internet ...
With some versions of scp (the version on the source computer seems to be the key), just re-executing the scp command will suffice to resume the transfer. But be careful! If your version doesn't support partial transfers, the partial file will simply be overwritten.
The following rsync switches are handy for resuming a broken transfer if scp doesn't support ...
Simple, run the command
ssh -L 25565:minecraftserverIp:25565 user@remotelinuxbox
Then add a server to your minecraft client localhost:25565
This will allow you to connect to the remote minecraft server via the ssh tunnel.
Better yet - use PuTTY and just set it up through that.
You don't need anything like ProxyCap, just point your browsers proxy setting for SOCKS to your loaclhost on whatever port you specified for your -D .
One IMPORTANT note on this. "Problem solved" isn't quite right. Whilst yes, your normal browser traffic http/s will go through the SSH tunnel there ...
I believe the OP is asking for a way to tunnel all traffic not just ones that let you set proxy settings. The problem is that some programs do not let you specify proxy settings which is where sshuttle comes into play. sshuttle allows any program to go through your tunnel not just ones that you specify a proxy server.
This is actually pretty easy to accomplish, even though it's somewhat buried in the ssh documentation. Assuming OpenSSH, the basic syntax is as follows:
ssh -R 8080:localhost:80 -N email@example.com
This will open a listening socket on port 8080 of your-server.dyndns.org, and any connections that are made onto your-server.dyndns.org:8080 will ...
The Bitvise SSH Client user interface does not provide an option to start the profile automatically when Windows 10 starts up. Instead, you can create a shortcut to Bitvise with the "-loginOnStartup" option. The steps below are a lot easier than creating a batch file.
In your Bitvise Profile, select these options:
Uncheck "Open Terminal"
Uncheck "Open ...
I feel that you are expecting firefox to connect to your Debian SSHD service directly?
If that's the case, your understanding of SSH tunnel is completely wrong.
You need to run ssh client on the client machine, to 1) connect to your server and 2) start a local socks proxy. Firefox would then connect to your local socks proxy.
See below diagram:
local$ ssh -R 1080 remote
remote$ curl --socks5 localhost https://example.com
since OpenSSH 7.6
ssh(1): add support for reverse dynamic forwarding. In this mode,
ssh will act as a SOCKS4/5 proxy and forward connections
to destinations requested by the remote SOCKS client. This mode
is requested using extended syntax for the -R and RemoteForward
I have tried to better explain the accepted solution below.
Let us assume "machine A" and "machine B" are both behind NAT firewall. While both have ssh access to a remote "machine R" (say a VPS).
R -> A
ssh -R 20000:127.0.0.1:22 user@RemoteHost
Above command executed on machine A.
Create a tunnel from R (port 20000 of R)
to A (port 22 of A) (reverse ...
I have drawn some sketches
For making it easier to understand the tunnel mechanisms, watch these sketches.
The machine, where the ssh tunnel command is typed is called »your host«.
local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.
ssh -L sourcePort:forwardToHost:...
If computer A is reachable via SSH, an SSH tunnel would be indeed the way to go:
computer-B$ ssh -L 1234:localhost:80 computer-A.example.com
Once you're logged in, point your browser to http://localhost:1234 and the webserver on computer A should respond.
With putty, there's a "Tunnels" menu underneath the "SSH" option (left side) where you can configure ...