SSH Tunneling Explained(goteleport.com) |
SSH Tunneling Explained(goteleport.com) |
I made it free to the HN community a few years back [1]. There is a paid interactive lab portion (details in the repo) if you are looking for hands-on experience.
Book Overview
This book is packed with practical and real world examples of SSH tunneling and port redirection in multiple realistic scenarios. It walks you through the basics of SSH tunneling (both local and remote port forwards), SOCKS proxies, port redirection, and how to utilize them with other tools like proxychains, nmap, Metasploit, and web browsers.
Advanced topics included SSHing through 4 jump boxes, throwing exploits through SSH tunnels, scanning assets using proxychains and Metasploit's Meterpreter, browsing the Internet through a SOCKS proxy, utilizing proxychains and nmap to scan targets, and leveraging Metasploit's Meterpreter portfwd command.
You might also want to look at Apache Guacamole or Boring Proxy. I’d love other recommendations!
This uses the escape mechanism. For help on that, hit return, type "~?" and hit return again.
From there you will see that "~#" will list them. And "~C" takes you to a line-oriented command prompt where you can add them.
For example, type return "~C", then at the prompt type "-L1234:localhost:22". Then in another window, type "telnet localhost 1234". Then back in the ssh window, type return "~#" and you will see the tunnel being used.
Another trick: if you don't need a shell and only want to forward ports, run "ssh -N" instead of "ssh".
That is, hit enter, type "~C", then prompt appears, then "help" and hit enter again.
The fact is that ssh tunnels are bound to an interface on one side and the other can be any (reachable) host:port. So if example.com:1234 isn’t reachable from your host network, you can do a local port forward to example.com:1234 from an intermediary host that can reach example.com:1234
my personal preference has been to use ssh -D and tsocks for this. it doesn't require root on either side and tsocks is elegant for inbueing just the processes you want with the ability to use the tunnel.
(pwnat is pretty cool, but I don't think it does quite what I'm looking for)
What’s also very interesting is that the article links to page from TrendMicro about malicious Android apps using Java’s version of SSH to infiltrate internal corporate networks.
TrendMicro’s own Android app ALSO contained the same Java SSH sdk.
The manual page says, "By default, the local port is bound in accordance with the GatewayPorts setting."
I don't see GatewayPorts in any of the config files, so the binary (at least mine) is probably built to have this off by default. Which seems like a sensible setting.
EDIT: It can't hurt to be sure, though. Especially if you're running ssh commands on different computers or writing a script that runs ssh.
I was wondering if there is a better way to setup a central bastion host with RBAC such that the attack vector is also not centralised. Does anyone here have ideas?
After reading this article I started a port forwarding session and can access the remote notebook without issue. All it took was the ssh port forwarding. Amazing.
I always laugh when I ssh into AWS, then into the RPI (over the internet and then a 900MHz bridge). Then sometimes I ssh or ftp into a data logger running in the field. Good times and has worked relatively flawlessly for a few months. (I don’t have any uptime metrics for the network connection but no noticeable problems.)
I’m planning a few more which would be much more remote. Any other suggestions for managing such a setup? Some sites may have cellular connections and so I’m not sure I want 24/7 ssh tunnel (though I don’t think it uses too much data).
Edit: I see others recommending WireGuard for similar situation. Never heard of it will check out.
What was the gain here exactly? The same port scanners are hitting your AWS instance now. If it concerned you before with the RPi (which it shouldn’t btw), I don’t see why it wouldn’t concern you with the AWS instance as well…
My concern is that I'm running an experiment and don't want things corrupted by some script kiddies simply because I'm not a great network/Linux admin. This merely reflects my lack of knowledge... hence my ask. (Which I guess people hate enough to downvote? haha ok)
Hah, same. Didn't really go that deep into the failed login attempts though: private key authentication + I have a static IP so iptables is sufficient. In addition I have a script that sends a text to my phone each time someone logs into any of my computers/servers(even if it's me) and if not, I have one or two kill switches at my disposal.
Some things to note:
- The sshReach.me logo in the topbar links to https://sshreach.me/init/default/index.html rather than https://sshreach.me. Expected the latter to have a clean URL to bookmark.
- At the very bottom of https://sshreach.me/init/default/index.html, the links {debian,arch,mint,...} link to the distro homepages. I expected links going to distro-specific guides on how to set these distros up to use our service.
- The Yocto project is quite popular for building embedded devices. It would probably push your service, if you would provide yocto recipes which make the created systems maintain reverse ssh tunnels to your service.
I actually used it for working around NAT with a cheap VPS which now acts as an ingress and proxies the requests for all of the ports over to one of my homelab servers that i want to expose: https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
(disclaimer: the above blog post is pretty simplistic and shouldn't necessarily be followed to the letter, in most cases you'll want to expose ports on a case by case basis)
TailScale might be an interesting alternative. Even more so as with headscale there is an Open Source server side implementation. Have not tested neither of those though.
Then basic RBAC with sudoer file according rights depending on your role. The only root account was accessible through two locked up yubikeys, and the passwords of those were in a password manager owned by the architect and manager.
When i left, we were starting a V2 on this with internal LDAP for server/proxy access, first for us then for our clients.
> Who should use Session Manager?
> ...
> Users who want to connect to an instance with just one click from the browser or AWS CLI without having to provide SSH keys.
Perfect, how do I get started? > Step 8: (Optional) Enabling and controlling permissions for SSH connections through Session Manager
> ...
> Create or verify that you have a Privacy Enhanced Mail certificate (a PEM file), or at minimum a public key, to use when establishing connections to managed instances. This must be a key that is already associated with the instance.
Uh oh, what's going on?Well, I think I understand now that using SSH with SSM is optional. You can use the AWS Console or the AWS CLI to connect to a shell on the instance without using SSH. Then you don't need keys and even grants additional benefits like the ability to shell into instances without a public IP and without opening any ports. However, SSM+SSH has some advantages like SCP which I don't believe is supported by SSM alone.
Another thing I've been looking into is AWS CloudShell which is free. When opening CloudShell essentially a virtual instance is created within your VPC with Amazon Linux installed. You can then use this shell to SSH into instances. I haven't looked into it much because I would rather use SSM but I believe this could be used to essentially be an ephemeral bastion that is secure in that it doesn't accept public requests, it can only be accessed via the Console.
You can use SSH Certificates, but management is kind of a pain. Not only the certs, but to do quasi-RBAC you'd need to configure the host to accept/deny certain certs for certain users to certain things, but that's still not really RBAC.
You could set up your hosts to use an LDAP server, but the LDAP server would be the central attack vector.
Honestly, Teleport is probably the only thing that provides a complete solution for what you want and more. I have tried to get my company to pay for it because it would save us so much time trying to cobble together something that's almost the same, but they balked.
This whole situation is really interesting to me. Nobody has invented a piece of technology to solve the problem we really want solved. We don't really want to "port forward through a bastion host", we want to grant specific users limited access to a private network. I think what would solve this is an SSO-authenticated Wireguard that can forward to arbitrary Wireguards - does anyone know if that's a thing?
- Both links lead to the same place but thanks for the advice, we will change the link on the logo.
- There are no distro specific guides because for every distro the setup is the same - just download our client script and run it. It is made to work with minimal python install and to work on every distro.
- I haven't heard of Yocto project, I will definitely look into it, thanks for the info.
We use bastions to connect to RDS instances. The bastions aren't accessible from the internet; only via SSM. You can wrap up all of the steps in a shell script that calls `ssh`, or with a bit more effort, concoct a ProxyCommand script that does everything for you and makes e.g. `ssh aws-bastion` just work.
We have a script used as an SSH ProxyCommand that:
1) queries EC2 to find a bastion host based on tags (the bastions are in an ASG and can change)
2) generates an SSH key
3) adds the generated private key to ssh-agent temporarily (using the `-t` parameter to `ssh-add`)
4) sends the generated public key to the selected host using ec2-instance-connect
5) starts an SSH session using `ssm start-session`
Then a `~/.ssh/config` entry that intercepts connections for host `aws-bastion` and specifies the ProxyCommand (as well as keepalive and ControlMaster to make subsequent connections fast).
Adding the key to the agent temporarily is a trick since there's no other way to pass information from a proxy command to the outer `ssh` process, and I couldn't find any other hook. I've found at least one instance where that trick doesn't work: when connecting to a database from within IntelliJ's database tools. For that, I added an option to the proxy command script to pick a key already registered in the agent rather than generating a new one (e.g. `ssh-add -L | head -1`).