Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH hacks – a little sanity for remote workers

smallstep.com

Post reply on HN
Print view View original

171–180 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#171

Post by rsync »

carapace wrote: post #162

The coolest thing I ever saw in the wild, a guy I once worked with wanted to transfer a directory of files from my machine to his (and maybe show off a little.) This was long enough ago that I didn't know quite how to proceed (time before rsync, scp...? Nah...) so he asked if he could do it and I let him have the keyboard. He tar'd (with z) the dir, piped the output of tar to ssh, with a remote command to cat it out…

From a very old notes file I have ...

    tar cf - /mnt/data2 | ssh user@10.0.0.10 "cat > /mnt/data1/file1/file_data2.tar"
... and if the directory is large, you can 'split' it into multiple files:

    tar cfp - /mnt/data1 | ssh user@10.0.0.10 "split - -b 1024m /mnt/data1/file1/file_data2.tar"
This is really no longer relevant because, of course, we all just use rsync ... but in the modern world, my favorite example of the unix philosophy is:

    mysqldump -u mysql db | ssh user@rsync.net "dd of=db_dump"

Re: SSH hacks – a little sanity for remote workers

#173

Post by MaxBarraclough »

kazinator wrote: post #153
MaxBarraclough wrote: post #90

Earlier quoted context omitted.

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.

Sure, but if you break your employer's cybersecurity policies, you don't get to blame IT for failing to prevent you from doing it.

Re: SSH hacks – a little sanity for remote workers

#174

Post by donaldihunter »

beagle3 wrote: post #165
bogomipz wrote: post #159

I 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: https://github.com/sshuttle/sshuttle https://sshuttle.readthedocs.io/en/latest/overview.html

More votes for sshuttle! It's a poor man's one way VPN: It inherits encryption/integrity/authentication (and some authorization) from ssh; It works incredibly well; For most practical network purposes it puts you on the computer you are sshuttlling to; And all it needs on that computer is the ability to ssh into it and some version of python - no special privileges or prior installations. The bad: It only does TCP (a…

Yep, sshuttle is awesome. It's also used under the covers by telepresence for connecting into a k8s cluster.

https://www.telepresence.io/

Re: SSH hacks – a little sanity for remote workers

#175

Post by xioxox »

MaxBarraclough wrote: post #109
xioxox wrote: post #63

Everyone probably already knows this, but enabling compression (-C) makes running remote X programs more usable over slower connections.

Not a bad tip, but using gzip compression over the wire seems pretty stone-age. The proper solution is surely to use a modern lossy video-compression algorithm. Is that possible with X? It's not something I know a lot about. Is this where VNC steps in?

x2go and xpra allow some lossy compression algorithms.

Re: SSH hacks – a little sanity for remote workers

#176

Post by jandrese »

orbitingpluto wrote: post #134
mercora wrote: post #125

Earlier quoted context omitted.

I've seen this on Ubiquity hardware as an option too. Apparently it requires you to "check-in" via facebook to use it, whatever that means exactly. There is also an option to login via facebook without this though.

This was awhile back and was particularly nasty. No token, no check-ins, it was an unapologetic man-in-the-middle login prompt. Terms of service had wording that made mining all data in your Facebook account sound like the intent.

How about no. Or hell no. If I see a request like that it is an immediate disconnect. Might as well have a requirement that they do a full anal cavity sweep before they can sell you a cup of coffee.

Re: SSH hacks – a little sanity for remote workers

#177

Post by jandrese »

rsync wrote: post #171
carapace wrote: post #162

The coolest thing I ever saw in the wild, a guy I once worked with wanted to transfer a directory of files from my machine to his (and maybe show off a little.) This was long enough ago that I didn't know quite how to proceed (time before rsync, scp...? Nah...) so he asked if he could do it and I let him have the keyboard. He tar'd (with z) the dir, piped the output of tar to ssh, with a remote command to cat it out…

From a very old notes file I have ... tar cf - /mnt/data2 | ssh user@10.0.0.10 "cat > /mnt/data1/file1/file_data2.tar" ... and if the directory is large, you can 'split' it into multiple files: tar cfp - /mnt/data1 | ssh user@10.0.0.10 "split - -b 1024m /mnt/data1/file1/file_data2.tar" This is really no longer relevant because, of course, we all just use rsync ... but in the modern world, my favorite example of the u…

None of those are quite right IMHO:

tar -czvf - | ssh @ tar -xzf - -C

This is _much_ faster if you're sending over a directory with a lot of small files, especially if the link has even a modest amount of latency. The 'z' parameter can be omitted if the source files are not compressible (media files or already compressed).

If the files are highly compressible but very large you might consider this instead:

tar -cvf - | pbzip2 -c | ssh @ tar -xf - -C

Re: SSH hacks – a little sanity for remote workers

#178

Post by tgb »

enriquto wrote: post #148
tgb wrote: post #122

I often ssh then open a vim on the server. But it would make more sense to me if vim had support for open remote files via its own ssh connection instead. Does this exist (for vim or some other editors)? Then I could always use my local config and it would be easier to type on a bad connection.

> Does this exist (for vim or some other editors)? It does: vim scp://server//path Run :h netrw inside vim to learn all about editing remote files.

Thanks, this looks like what I want.

Re: SSH hacks – a little sanity for remote workers

#179

Post by dkdk8283 »

modo_ wrote: post #164
mrweasel wrote: post #87

Earlier quoted context omitted.

I love the multiplexing feature. We have a client who require password, ssh key and MFA. All services are behind a bastion host, which only accepts trafic from select IPs. SSH multiplexing and proxy configuration allows me to enter the password and TOTP just once instead of every time I need to access a service behind the bastion host.

Is there much of an upside to doing the multiplexing on the client side instead of on the server (with something like tmux)? It seems to me like the session persistence tmux gives would be worthwhile if you have a lot of simultaneous sessions going.

I never saw the value of tmux unless your running a command that can’t be interrupted.

Having multiple windows vs tabs on my desktop seems so much easier.

Re: SSH hacks – a little sanity for remote workers

#180

Post by dkdk8283 »

beagle3 wrote: post #156
mrweasel wrote: post #130

Earlier quoted context omitted.

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

Sounds more like a bug than a disadvantage
Post reply on HN