SSH – SSH Shell via SSH Proxy

sshssh-tunneling

Yes, I'm aware that I wrote "SSH shell" in the title.

TL;DR: The first paragraph, the one with the link, and the one with the error message are most important.

I have my Raspberry Pi at home which I can access over the internet but only via IPv6. I'm currently in a location where I don't have IPv6.

I can execute commands on it by first logging in to a server which has both IPv4 and IPv6 and then logging into my pi from there. However, I use SSH on it for more than executing commands on it:

git
backups (Deja Dup)
accessing files (SFTP)
VNC (I tunnel through SSH and can then connect to localhost via VNC)

These are in decreasing order of importance. I want to access my git repos.

A few more details:

I can't simply make my Pi accessible via IPv4. The modem it's behind has an IPv4 address and an IPv6 subnet but I have to use hardware I didn't choose running software I can't change. That software is not only buggy and I can't even take a look at it, but furthermore, it doesn't allow IPv4 port forwarding it all.
I don't control the server with both IPv4 and IPv6 on it. I only have a normal user account on it and can't – for example – install new software if more than standard user rights are required for it.

Googling for a solution brought up this rather promising page, and it actually works for git. I set up new remotes for the repos I'm using, simply replacing the pi's domain name by localhost:3333.

But it looks much more promising than that. It looks like the solution for all of the above. And it kind of started to work out!

SFTP works and I can't really determine whether backups via Deja Dup work, yet, because my connection is too slow, but it hasn't failed yet, and something's causing network traffic, so that's good and promising.

But why can't I just do ssh localhost:3333 to connect to my laptop to get a shell on my pi? The command results in this error message:

ssh: Could not resolve hostname localhost:3333: Name or service not known

I'm mainly interested in why I can't get a shell the way I'd expect it to work.

Best Answer

You might want to look into ssh's ProxyCommand configuration, which allows for this to work more seamlessly, and will work for shells, SFTP, tunnels, and anything else you might want to proxy via ssh.

Let's say you have the following three hosts:

workstation.example.com - This is the machine you're physically working on
proxy.example.com - This is the machine you're routing your SSH traffic through
endpoint.example.com - This is where you want the traffic to ultimately end up

In ~/.ssh/config on workstation, add the following:

Host endpoint
    User EndpointUser # set this to the username on the destination host
    HostName endpoint.example.com
    ProxyCommand ssh username@proxy.example.com nc %h %p 2> /dev/null

On the proxy host, make sure nc (netcat) is installed.

Then, on workstation, you can ssh endpoint or sftp endpoint and you will be transparently proxied to the machine by way of your proxy host.

Related Solutions

SSH login via IPv6 successfull while using IPv4 to the same host yields “Permission denied”

After things getting stranger and stranger (see the thread of comments in my question) I finally figured it out. First things first: The authentication process did fail in pam_access.so however not due to some misconfiguration in /etc/security/access.conf as it was suggested.

To understand why, we must look at the setup of this box in particular: It acts as a router toward IPv4 which goes natively over the PPP link and IPv6 which is over a 6in4 tunnel. Also this box acts as a DNS recursive resolver, and here it is getting interesting. I did configure the resolver in a way that IPv4 reverse lookups are resolved recursively starting with the IPv4 root servers and IPv6 reverse lookups start with the IPv6 root servers. This setup did work when I first installed it.

Now my ISP enters the pictures and people who don't understand, how DNS amplification attacks work. To make a long story short: I know for sure that my ISP messes with incoming DNS packets at random, i.e. some things must be resolved through their own resolvers for some time now, while resolving other DNS addresses recursively on your own works – the official reason is to mitigate DNS amplification attacks, but they're doing it wrong then^1.

Since I didn't want to largely change my setup I just threw my ISP's DNS resolvers at the end of my local DNS resolver as nonrecursive forward, so if the recursive resolving attempt times out it tries my ISP's resolvers. This works so far. But when I did configure this I made a small mistake: I entered the ISP's DNS resolvers to work only from hosts within my local scope, i.e. 192.168.0.0/16 but forgot about localhost, aka my router, which is the host I tried to SSH into, for which the resolver would not take the ISP's resolvers into account.

pam_access.so attempts a reverse lookup on the peers address; and this closes the circle: Because for IPv6 reverse lookup the DNS IPv6 root servers would be accessed the packets would go though the 6in4 tunnel without my ISP messing with them, getting a response. But IPv4 reverse lookup would not be done over the ISP's resolvers by my own, which would receive no response and would ultimately report a NXHOST (or it would run in a timeout). Anyway pam_access.so won't see something it likes and just says "you shall not pass".

After I fixed that resolver configuration everything now works like a charm again. But I really have to step onto my ISP's toes now…

As to how I did resolve it? Well, by yanking up logging verbosity intensely studying /var/log/everything to see in which order things unfolded. When I saw my resolver logging the reverse lookup attempts I knew what was going on.

1: from a DNS amplification mitigation point of view this is complete nonsense, because I did test and outgoing DNS packets get through just fine – however those are the packets they should filter. In fact every end customer ISP should drop all UDP packets which sender address doesn't match those of their customers

SFTP – How to Use SFTP Over Reverse SSH Tunnel

First, this is a prerequesite (at least for me): Remote desktop over SSH reverse tunnel to replace TeamViewer

The reverse SSH tunnel looks like this:

laptop(SFTP client)--->nat--->middleman<--nat<--desktop(SFTP server)

On laptop edit ~/.ssh/config and add this:

Host SftpToDesktop
  HostName localhost
  Port %p
  User admin
  PasswordAuthentication no
  IdentityFile ~/.ssh/my_id_rsa

Then, with an existing SSH leg from laptop to middleman established already (as per above link), do the following:

$ ssh -fNL 1234:localhost:1234 -i ~/.ssh/some_id_rsa admin@middleman.com

Finally, open Dolphin (if using KDE like me) and enter this location:

sftp://SftpToDesktop:1234

Best Answer

Related Solutions

SSH login via IPv6 successfull while using IPv4 to the same host yields “Permission denied”

SFTP – How to Use SFTP Over Reverse SSH Tunnel

Related Question