If you are working on an HPC cluster:
[1] The ssh package for vscode is great
https://code.visualstudio.com/docs/remote/ssh
[2] Also check out rsub which allows you to open a file in your terminal locally
SSH hacks – a little sanity for remote workers
151–160 of 230 posts
Re: SSH hacks – a little sanity for remote workers
#152My favorite SSH trick is to have a machine at work SSH back to my home domain, and provide a tunnel back for Remote Desktop or what have you. Wee, no VPN to deal with. No lack of a VPN for remote access to deal with. https://cygwin.com/pipermail/cygwin/2020-April/244384.html
At a large company, I imagine IT would be concerned about this setup. Though it’s on them to make the proper VPN solution more usable. Hacking your home domain would give someone a powerful jumping off point for hacking other things on your corporate network.
Less of a surface than in the scenario that the home domain is hacked and there is VPN running.
Re: SSH hacks – a little sanity for remote workers
#153My favorite SSH trick is to have a machine at work SSH back to my home domain, and provide a tunnel back for Remote Desktop or what have you. Wee, no VPN to deal with. No lack of a VPN for remote access to deal with. https://cygwin.com/pipermail/cygwin/2020-April/244384.html
That's likely to be a firing offence, no? If I were running things I wouldn't want employees deliberately subverting my network's security measures in the name of their own convenience. If you have to spend time wrestling the VPN while you're on the clock, that's their own time being wasted.
All you would have to do is disallow outbound SSH.
Re: SSH hacks – a little sanity for remote workers
#154I'd recommend wemux[0] for anyone wanting to share tmux sessions with other people (or even just themselves). It supports several modes:
- mirror: to attach to server in read-only mode.
- pair: attach to server in pair mode, allowing the client to control the terminal as well.
- rogue: attach to server in rogue mode, which allows both editing with the host and switching to windows independently from the host.
I personally use rogue to share tmux sessions between my own devices without affecting whatever I'm doing on the other devices.
Re: SSH hacks – a little sanity for remote workers
#155I've also long used SSH in various simple tunnels for my personal laptop's Web browser and/or mail client, such as through EC2 instances (and at one point also through a filtering HTTP proxy). Here's one version of it.
while true ; do
# TODO: make this do desktop notifications instead of osd_cat
echo "TUNNEL CONNECTING" | osd_cat --pos=middle --align=center --lines=1 \
--font="-unregistered-latin modern sans-bold-r-*-*-140-*-*-*-*-*-*-*" \
--color=green1 --outline=2 --outlinecolour=white --delay=1
ssh -2 -4 -a -k -n -x -y -N -T -D 127.0.0.1:1234 user@example.com
sleep 3
done
Re: SSH hacks – a little sanity for remote workers
#156Earlier quoted context omitted.
Of course if the multiplex stalls or goes down so do all of the connections you have running through it. It's like screwing up Gnome Terminal or similar that uses a main server and multiple clients. Screw one pooch and you're whole session of things is similarly screwed.
True, but I never see SSH go down, unless there's a network issue, in which case I lose all my connections anyway.
Indeed; however, if you have a lingering control file (because an old ssh process was killed, or there was a power failure and it was somehow not removed), it will either refuse to use it, or (occasionally, and I haven't been able to pinpoint when), would just wait there forever.
edit: a typo
Re: SSH hacks – a little sanity for remote workers
#157Earlier quoted context omitted.
I use a config file for all my regular SSH connections as well. But I stopped using more than one key when I could not think of a threat model that it addressed. If the bad guys get a copy of my public key off one remote server, they can't use it to access any other remote server. They would need the private key, which is on my laptop. And if the bad guys get my laptop, then they get all my keys; having separate priv…
If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) all systems that ssh key grants them access to. See also: https://github.com/FiloSottile/whoami.filippo.io Using a private key per system or set of systems means that such an attacker would only gain access to what that key grants them access to. My "github" key…
The SSH-agent forwarding model is the problem, I think; Every couple of years someone finds another semi-common scenario where it becomes vulnerable.
I have, since 2010, practiced "jumps" only - that is, if I need to connect to a non-routeable host through a routeable one ("bastion host" or "jump host"), then the intermediate host is only used as a transport, by way of -L/-R forwarding of the final destination's ssh port, or by netcat, or (since a couple of years ago) SSH's internal ProxyJump or ProxyCommand; compared to agent forwarding, this is less efficient CPU-wise and traffic-wise, but not by much; and it is as safe as connecting to the final destination directly, unlike agent forwarding.
Re: SSH hacks – a little sanity for remote workers
#158ssh not having support for --password argument is a big drawback. Usually requires to use some weird workarounds, especially when copying ssh keys to the machine are not an option.
`sshpass` or `expect`?
Re: SSH hacks – a little sanity for remote workers
#159I would like to mention sshuttle if your access only is via a jumphost and you don't want to have to create a port forward for every single host/port you want to connect to on the internal network. It basically acs like a cheap VPN:
Re: SSH hacks – a little sanity for remote workers
#160Earlier quoted context omitted.
Word of warning: using jump hosts shift your mindset towards building an internal network with lax security, the crunchy outside/soft tasty inside security antipattern. (Yes you don't intend it at the start, but the realities of your later evaluations of where to invest effort security-wise will leave the internal network to rot since you won't think of the scenarios of how it would be compromised)
Isn't that typically already the mindset, since most people set up networks with non-routable (10, 192.168 etc) IP addresses?
It's a chicken-and-egg situation, yep. But the world seems to be moving towards zero trust networks, distaste towards complexity and opacity brought on by ambiguous rfc1918 addresses, and wide availability of ipv6.