I'm away from home, regularly accessing my computers at home. Easy: ssh into a gateway machine and ssh from there into the internal machine of my choice. Nested ssh sessions. It gets a little more annoying when I want to transfer a file. The new-to-me ssh/scp option "ProxyJump" handles this conveniently. Consider the example of transferring a file "f" from machine "home" through machine "gw" to machine "away", all done from an xterm on "away". Note: because "away" is behind NAT, "gw" cannot scp to it. Note: -A enables ssh-agent to avoid some manual authentication Note: things become more complicated if f has slashes. [away] $ ssh -A gw [gw] $ scp -p home:f . [gw] $ exit [away] $ scp -p gw:f . [away] $ ssh -A gw [gw] $ rm f [gw] $ exit This can be simplified because the ssh command allows shell commands as arguments. That's not a habit I've developed. [away] $ ssh -A gw scp -p home:f . [away] $ scp -p gw:f . [away] $ ssh -A gw rm f The ProxyJump option makes this a lot simpler: [away] $ scp -p -o 'ProxyJump gw' home:f . I have no need for more than one intermediate hop so I haven't figured out how that would work.
I've had to do the kinda of multiple proxy jumps Hugh is alluding too. It was common in a Managed Service Provider I worked for. FYI, the ProxyJump directive was only introduces in OpenSSH version 7.3. As we had a lot of legacy RHEL/CentOS 6 systems, which were not yet on that version, we had to use the older pattern of ProxyCommand and NetCat (nc). Combining ProxyJump along with User, Port and IdentityFile directives in your .ssh/config file, you can preform some amazing back-flips and lateral moves through infrastructure. I think my record was 5 layers of depth, but a don't have those config files any more. Dropping your public keys, and 'ForwardAgent yes' in .ssh/config in ever user/system along the proxy chain means you can have a single SSH command take you all the way to the end of the chain without being prompted for a password at each hop. --- # === SITE 1 === # Best-practice firewall rules means jump-box is the only host reachable via VPN, so is always our first hop. Host jump-box HostName jump-box.example.org User someone Host stargate ProxyCommand ssh -q someone@jump-box nc stargate.example.org 22 Host stargate2 ProxyCommand ssh -q someone@jump-box nc 192.168.133.7 22 # === SITE 2 === Host jump.site2.other.org ProxyCommand ssh -q someone@stargate2 nc 10.30.40.20 22 # === SITE 3 === Host 192.168.3.* ProxyCommand ssh -q someone@stargate nc %h 22 # === SITE 5 === Host 10.90.5.* ProxyCommand ssh -q someone@stargate nc %h 22 User differentuser # Examples # ssh someone@192.168.3.12 # A double jump, host/ip wildcard says we need to connect via 'stargate', which will resolve further to 'jump-box' which is canonically 'jump-box.example.org' --- On 8/29/20 11:55 AM, D. Hugh Redelmeier via talk wrote:
I'm away from home, regularly accessing my computers at home. Easy: ssh into a gateway machine and ssh from there into the internal machine of my choice. Nested ssh sessions. It gets a little more annoying when I want to transfer a file.
The new-to-me ssh/scp option "ProxyJump" handles this conveniently.
Consider the example of transferring a file "f" from machine "home" through machine "gw" to machine "away", all done from an xterm on "away".
Note: because "away" is behind NAT, "gw" cannot scp to it. Note: -A enables ssh-agent to avoid some manual authentication Note: things become more complicated if f has slashes.
[away] $ ssh -A gw [gw] $ scp -p home:f . [gw] $ exit [away] $ scp -p gw:f . [away] $ ssh -A gw [gw] $ rm f [gw] $ exit
This can be simplified because the ssh command allows shell commands as arguments. That's not a habit I've developed.
[away] $ ssh -A gw scp -p home:f . [away] $ scp -p gw:f . [away] $ ssh -A gw rm f
The ProxyJump option makes this a lot simpler:
[away] $ scp -p -o 'ProxyJump gw' home:f .
I have no need for more than one intermediate hop so I haven't figured out how that would work. --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
-- Scott Sullivan
On 8/29/20 6:31 PM, Scott Sullivan via talk wrote:
FYI, the ProxyJump directive was only introduces in OpenSSH version 7.3. As we had a lot of legacy RHEL/CentOS 6 systems, which were not yet on that version, we had to use the older pattern of ProxyCommand and NetCat (nc).
While I was looking for that version number, I actually pulled up a more generalized version that uses only SSH, no netcat required. Host remote-host ProxyCommand ssh bastion-host -W %h:%p From this 2019 redhat article. https://www.redhat.com/sysadmin/ssh-proxy-bastion-proxyjump -- Scott Sullivan
On Sat, Aug 29, 2020 at 06:50:45PM -0400, Scott Sullivan via talk wrote:
On 8/29/20 6:31 PM, Scott Sullivan via talk wrote:
FYI, the ProxyJump directive was only introduces in OpenSSH version 7.3. As we had a lot of legacy RHEL/CentOS 6 systems, which were not yet on that version, we had to use the older pattern of ProxyCommand and NetCat (nc).
While I was looking for that version number, I actually pulled up a more generalized version that uses only SSH, no netcat required.
Host remote-host ProxyCommand ssh bastion-host -W %h:%p
Man, this would have been VERY useful, when I was working for POS/ERP company. We had to do it manually, one jump at a time, making note (on paper) where we were each jump. :-) -- William Park <opengeometry@yahoo.ca>
On Sat, 2020/08/29 09:20:35PM -0400, William Park via talk <talk@gtalug.org> wrote: | We had to do it manually, one jump at a time, making note (on | paper) where we were each jump. :-) There's a reason why my shell prompt includes the fully-qualified hostname. (And userid, if it's not my normal one.) I've seen people colour code their xterms by hostname as well. If you're "clever", you can probably change your xterm title string as you go, so you window title could end up with a label like: jumphost1 -> nexthop -> 3rdhop -> dbserver (e.g. xtitle from http://www.shelldorado.com/scripts/cmds/xtitle ) John
On Sat, 29 Aug 2020 23:05:04 -0400 John Sellens via talk <talk@gtalug.org> wrote:
On Sat, 2020/08/29 09:20:35PM -0400, William Park via talk <talk@gtalug.org> wrote: | We had to do it manually, one jump at a time, making note (on | paper) where we were each jump. :-) There's a reason why my shell prompt includes the fully-qualified hostname. (And userid, if it's not my normal one.) I've seen people colour code their xterms by hostname as well. If you're "clever", you can probably change your xterm title string as you go, so you window title could end up with a label like: jumphost1 -> nexthop -> 3rdhop -> dbserver (e.g. xtitle from http://www.shelldorado.com/scripts/cmds/xtitle )
I have not really thought of also allocating different colours, so simple, so obvious and that is such a cool add, thank you! (guess who is right now busy playing with various colours :) ) you could also combine hops into different screens depending on whether a hop is a hub, node, container, disposable, trip or whatever (and also include that in .bash_profile) by adding -t and screen -dr pts-3 so I can have something like: hop1 -> nexthop_19216810-74-p92-pts-2-fallback -> route7_ipv4-p22-pts-3 -> tripwire_ipv4 -> server1-etc-etc (so the ssh can look something like - ssh -t nexthop screen -dr pts-3, if you are using standard/normal screen of course) I usually add some of the ipv4/6 (and sometimes where I use zebra even add the as/bgp/etc) so I can instantly know where I am (or where I am supposed to be) - other useful things some may consider adding is lag (or average lag) so that you can even drop and connect different screens based on network (or you can have timers/cron/whatever running the screen connections) - depending on how much tinfoil you are wearing, of course :) Andre
| From: Scott Sullivan via talk <talk@gtalug.org> | Dropping your public keys, and 'ForwardAgent yes' in .ssh/config in ever | user/system along the proxy chain means you can have a single SSH command take | you all the way to the end of the chain without being prompted for a password | at each hop. I felt guilty leaving this out of my previous message: When you do a normal SSH into a host, you are not trusting that host much. (Of course things you actually do in your session could involve trust.) If you use -A (same as ForwardAgent yes), you are allowing the host to use your private key in dealing with other hosts. If the first host were subverted, you could be in trouble. For that reason I use -A sparingly. When you use -X (ForwardX11) feature, you are also trusting the host. X isn't a particularly safe protocol. So I use this sparingly too. In my .ssh/config: <<< # default dangerous things to "off" for hosts outside mimosa.com Host *.mimosa.com ForwardAgent yes ForwardX11 yes Host * ForwardAgent no ForwardX11 no
D. Hugh Redelmeier via talk wrote:
[away] $ ssh -A gw scp -p home:f . [away] $ scp -p gw:f . [away] $ ssh -A gw rm f
$ ssh -A gw "mkdir home && sshfs home:/home/hugh home" $ scp -p gw:home/f . You should be able to set up the sshfs mount once per reboot of gw and/or home (which were probably plugged into the same UPS anyway!) and this saves having to have local disk on gw and cleaning up all the files staged through it. (Note there's also the issue of whether a solution where "home" trusts "gw" is sufficient vs a solution where they don't trust each other and "gw" just tunnels an encrypted connection from "away" to "home". Also, you could use the proxy pipe to sshfs-mount "home" directly to "away" but in my experience the Internet isn't stable enough to want to depend on long-lived connections. Next, to look into sshfs-over-mosh?) -- Anthony de Boer
participants (6)
-
ac -
Anthony de Boer -
D. Hugh Redelmeier -
John Sellens -
Scott Sullivan -
William Park