[tunneling] how to set up a reverse ssh tunnel on a Vps in the cloud?

Started by thomasb, December 17, 2021, 02:25:31 AM

Previous topic - Next topic

thomasb

When I try to open a forward tunnel on my Vps in the cloud, it works:

ssh -p 22 -i mykey user@vps-public-ip -L 10000:vps-private-ip:80

Then my local web browser shows the page on the Vps by typing the address http:/ /localhost:10000

But the reverse version doesn't work:
ssh -p 22 -i mykey user@vps-public-ip -R 10000:localhost:22

The goal would be to connect to my Pc at home from my workplace for example, or the opposite.

Any idea what goes wrong? The port 10000 appears open in the setting webpage of the Vps, and in file /etc/ssh/sshd_config both ports 22 and 10000 are explicitly open too.
"In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite." ― Paul Dirac

deanwebb

Do you have a firewall on your home side that blocks inbound connection attempts?

Personally, I would be VERY cautious about having port 22 open to the Internet, even if only to one IP address.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

thomasb

It could be: my daily drive is behind an homemade router running an homemade iptables firewall. The router is a converted old computer, just to train with networking configuration. Here are the rules:


#!/bin/sh
#
# firewall.sh

# WAN and LAN interfaces
IFACE_LAN=enp2s0
IFACE_WAN=enp0s29f7u7
IFACE_LAN_IP=172.168.1.0/24

# Accept all
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t nat -P INPUT ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t mangle -P INPUT ACCEPT
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

# Reset the counters
iptables -t filter -Z
iptables -t nat -Z
iptables -t mangle -Z

# Delete all active rules and personalized chains
iptables -t filter -F
iptables -t filter -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

# Default policy
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# Trust ourselves
iptables -A INPUT -i lo -j ACCEPT

# Ping
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT

# Established connections
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

# SSH
iptables -A INPUT -p tcp -i $IFACE_LAN --dport 22 -j ACCEPT
#iptables -A INPUT -p tcp -i $IFACE_WAN --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -i $IFACE_WAN --sport 10000 -j ACCEPT
iptables -A INPUT -p tcp -i $IFACE_WAN --dport 10000 -j ACCEPT
iptables -A INPUT -p tcp -i $IFACE_LAN --dport 10000 -j ACCEPT
iptables -A INPUT -p tcp -i $IFACE_LAN --sport 10000 -j ACCEPT

# Dnsmasq
iptables -A INPUT -p tcp -i $IFACE_LAN --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i $IFACE_LAN --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i $IFACE_LAN --dport 67:68 -j ACCEPT

# TCP
iptables -A INPUT -p tcp -i $IFACE_LAN --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -i $IFACE_WAN --dport 80 -j ACCEPT

# Packet forwarding activation
iptables -t nat -A POSTROUTING -o $IFACE_WAN -s $IFACE_LAN_IP -j MASQUERADE
sysctl -q -w net.ipv4.ip_forward=1

# NFS
iptables -A INPUT -p tcp -i $IFACE_LAN --dport 2049 -j ACCEPT

# Log refused packets
iptables -A INPUT -m limit --limit 2/min -j LOG --log-prefix "IPv4 packet rejected ++ "
iptables -A INPUT -j DROP

# Save the configuration
service iptables save


Do you see anything wrong? Once the tunnel is open from my Pc and that I try to connect to it from the router, I get the message:


$ ssh -v -i vps-ssh-key -p 10000 user@vps-public-ip
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 63: Applying options for *
debug1: Connecting to vps-public-ip [vps-public-ip] port 10000.
debug1: connect to address vps-public-ip port 10000: Connection refused
ssh: connect to host vps-public-ip port 10000: Connection refused





And when I try to open the tunnel from the router instead of my Pc, I get:


$ ssh -v -i vps-ssh-key vps-public-ip -R 10000:localhost:22
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 63: Applying options for *
debug1: Connecting to vps-public-ip [vps-public-ip] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa_aws_testnewkey type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa_aws_testnewkey-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to vps-public-ip:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Iq1fqtCCAmkyRHf4nZjmumg4nsUMiU9b3W58pTf/Y+Q
debug1: Host 'vps-public-ip' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa_key
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).





The ssh service on the router asks for a key, so opening port 22 shouldn't be too dangerous. But I'll change the port when I get it to work, thank you for the advice
"In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite." ― Paul Dirac

deanwebb

I'm not well-versed in the iptables, but I do see port 22 open there.
Then the connection refused indicates that the connection was attempted, but some device in the path received the connection attempt and then said, "no".
The PC errormessage indicates a key problem.

Is the key authority accessible by both parties in the conversation? That's another hole to open up, likely port 443 for HTTPS key validation checking.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

thomasb

Fixed. It seems that GatewayPorts yes was missing in my /etc/ssh/sshd_config, but I changed so many things I don't remember well what went wrong...
Thank you for you insights
"In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite." ― Paul Dirac

deanwebb

Quote from: thomasb on December 21, 2021, 10:13:19 AM
Fixed. It seems that GatewayPorts yes was missing in my /etc/ssh/sshd_config, but I changed so many things I don't remember well what went wrong...
Thank you for you insights

Ah, that can cut off some of the negotiation of the connection. Explains how it started and then failed.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.