1. This is authorized. I just need to figure out how to do it.

  2. I want to forward web traffic from the target machine to my local machine such that when something on the remote machine tries to communicate over port 443 (https), it's perspective is from my local box.

Problem I'm trying to solve is as follows:

We have docker training going on in one specific machine we built just for this task. Right now, it can't access github and we need that for the training. Our team is authorized access to github explicitly.

Having what I think is probably just a lot of trouble with the syntax.

From my desktop machine, have tried:

ssh -vnNT -R 443:[ my ip addr from remote's perspective ]:443 [ remote host name ]

What I'm seeing in the debug output is:

debug1: Authentication succeeded (publickey).
Authenticated to remoteHostName ([remoteIpAddr]:22).
debug1: Remote connections from LOCALHOST:443 forwarded to local address [ my ip ]:443
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Server has disabled port forwarding.
debug1: remote forward failure for: listen 443, connect [my ip]:443
Warning: remote port forwarding failed for listen port 443
debug1: All remote forwarding requests processed

Now you would think that the above would mean that port forwarding was not configured on the server or set to 'no'. What I have set is:

AllowTcpForwarding yes
GatewayPorts yes

...and I've restarted it twice. :-/

  • Why not use an IPTABLES dnat rule rather then ssh? – davidgo Jan 4 at 1:31

1) sshd_config is not the only source of forwarding options.

Even if the server allows forwarding globally, individual connections (specific public keys) may be restricted using options specified in the remote ~/.ssh/authorized_keys file.

If you use OpenSSH "certificates", then restrictions may be encoded within the certificate itself. Use ssh-keygen -L to check.

2) You need root privileges on the remote system for this.

SSH port forwarding involves ordinary sockets listening for TCP connections on one end, making connections on another. (So it's more like proxying than the packet-level port forwarding seen on routers.)

With -R, the listening sockets are set up by the sshd worker process that handles your connection. That process runs under your own (remote) user ID, so it is subject to the same restrictions as your own programs would. In particular, it isn't allowed to bind sockets to a port below 1024 (the "privileged port" range) unless it has root privileges or something similar – which directly means that you must log in as root@ to the remote system.

  • Regarding authorized_keys, you mean the user@host information at the end of the key? – NonYaBidnezz Jan 4 at 14:47
  • Logging in as root is a non-starter. :-/ – NonYaBidnezz Jan 4 at 15:03
  • ssh-keygen -L returns "invalid Key: invalid format" Note that this is a Mac. – NonYaBidnezz Jan 4 at 15:10

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.