Live data from Hacker News

SSH hacks – a little sanity for remote workers

smallstep.com

221–230 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#221

My 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.

Maybe not a firing offense, but if you ran 'ssh -R' at $JOB-1, you'd pretty much immediately have someone from the security ops team messaging you to ask what you're up to.

Re: SSH hacks – a little sanity for remote workers

#222
post #44

This skips my favorite reason to use mosh: it has predictive local echo and so makes high latency connections much more useable

the only reason I don't use mosh by default is that ssh preserves CMD+up/CMD+down to jump to the previous/next prompt, but mosh breaks the behavior. If I could keep this, I'd be sold

Re: SSH hacks – a little sanity for remote workers

#223
post #183

Earlier quoted context omitted.

Terminals can have mouse support. It works with some TUI apps like vim.

All the terminal software with mouse support I've found so far just messes with things, I wasn't aware that people actually use this (e.g. in vim enabling mouse support messes with the yank buffer and doesn't let me select things for clipboard copying anymore, I immediately turn that off in setups where some overzealous maintainer default-enabled it). The amount of software with support is very low anyway, so if one…

?? Sounds like mosh is the only program in the stack that doesn't support this

Re: SSH hacks – a little sanity for remote workers

#224

Earlier quoted context omitted.

It’s probably the easiest way, but also very vulnerable. Never seen this use case or anything similar myself. Do you have other examples? I want to broaden my horizons

In general I'd say SSHing from a remote box to another remote box is a non-issue since you can always use some sort of tunneling/bastioning to make that work. It's when you want to use some other tool that tunnels over SSH -- scp, git, sftp, rsync, etc. -- that you run into trouble. Consider a remote development instance. So I'm an engineer, and instead of developing on my local I do development on an EC2 instance in…

Thanks. When faced with similar issues, I have always set up an ad-hoc channel (e.g. created a local key, ssh-copy-id it, use it, and remove both the keyfile and the authorized_keys line afterwards). It's more work, but gives exactly the minimum required trust and no more. I've never even considered using agent forwarding for this case.

That said, I don't have to do that often; If I did, I'd probably look for a simpler way (or ignore my paranoia and use ssh agent forwarding...)

Re: SSH hacks – a little sanity for remote workers

#226
post #67

I always create and heavily use ~/.ssh/config Host x Hostname full.host.name.com (or 1.2.3.4) User IdentitiesOnly yes IdentityFile ~/.ssh/id_x_ed25519 I give hosts short names so you can `ssh x` to do automatic login, I generate identities for some machines ssh-keygen -t ed25519 -f ~/.ssh/id_x_ed25519 use ssh-copy-id to copy the identity to the target machine so it lets you in: ssh-copy-id -i ~/.ssh/id_x_ed25519.pub…

That multiplex feature is really cool. Is there a way to make it work for pem files? It'll be super useful to specify "-i pem" once and use that for all subsequent ssh/scp. Same goes for the username.

Re: SSH hacks – a little sanity for remote workers

#227

Earlier quoted context omitted.

Interesting. Any likely reasons why not having IPv6/AAAA make the site inaccessible to them? Sounds like most of the internet would be inaccessible to them as well?

A broken AAAA record, perhaps. Sometimes the AAAA is invalid or broken without getting noticed by the sysadmin. I've personally reported broken AAAA records before.

I see. Although from the mmalone's comment it sounded like an AAAA record wasn't set at all, rather than set incorrectly.

Re: SSH hacks – a little sanity for remote workers

#228
post #29

Earlier quoted context omitted.

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.

Well, if IT is running a tight ship then only corporate owned/managed machines can access the VPN and not a home domain. Those machines might be just as hackable, but they should at least have some logging in place that allow detection or postmortem analysis.

Re: SSH hacks – a little sanity for remote workers

#229
post #211

Earlier quoted context omitted.

The core API's of Windows are so stable that if someone got it working once on WIndows NT, the executable should work for everyone on Windows 2000, Windows XP, Windows Vista, Windows 7, 8 and 10, ...

Yup - one of my smarter colleagues had a go at getting it compiled on Windows, and basically gave it up as the library dependencies were such a mess on that platform. No one seems to have packaged up binaries for it either.

> Win32 (with Cygwin)

Is that good enough support?

Re: SSH hacks – a little sanity for remote workers

#230
post #229
post #211

Earlier quoted context omitted.

Yup - one of my smarter colleagues had a go at getting it compiled on Windows, and basically gave it up as the library dependencies were such a mess on that platform. No one seems to have packaged up binaries for it either.

> Win32 (with Cygwin) Is that good enough support?

Are you saying that's an environment in which you can compile it?

We tried.

MinGW refers to headers from BSD sockets, which doesn't exist on windows.

Post reply on HN