SSH hacks – a little sanity for remote workers • Hacker News Board

Re: SSH hacks – a little sanity for remote workers

#161

Post by beagle3 » Thu, Apr 30, 2020, 2:47 PM UTC

mmalone wrote: post #50

lathiat wrote: post #48

Earlier quoted context omitted.

A good trick to combine with this is ControlSockets.. you can have multiple SSH/SCP connections over the same actual SSH connections. And starting a new SSH over the existing connection is much faster than the initial connection particularly if you are on higher latency (e.g. from Australia at 250-400ms) ``` Host xyz HostName 1.2.3.4 ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h-%p ControlPersist 600 ``` Then i…

I've always wondered what this is useful for. So it's purely for performance? Why is it faster to establish the connection? Does it re-use the authentication from the existing ControlMaster too, so you skip the handshake? Seems like it could be dangerous if you're not careful. I guess that's why you can configure it to use `ssh-askpass` for conformation (which, btw, is missing on macOS these days). The other neat-loo…

> So it's purely for performance?

It's not just for performance - it "reuses authentication" by not needing it. The authentication is an encapsulation, within which multiple channels get used. Usually, it's just the main "shell" channel; but occasionally it's also forwarding (-L / -R / -D), sftp; what ControlMaster does is let you open more "shell" channels when you run the "ssh" command again, instead of establishing a whole new connection.

> The other neat-looking directive that I've never tried is `ProxyUseFdpass`,

It's so you can use whatever weird communication hardware/protocol you like (serial? non-tcp satellite modem?), and all you have to do to get all of ssh's wonderful features over it, is make provide a file descriptor that works well enough (serial port; pipe you create; etc.)

Re: SSH hacks – a little sanity for remote workers

#162

Post by carapace » Thu, Apr 30, 2020, 2:51 PM UTC

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 there through tar again, all in one CLI line. Blew my mind at the time. UNIX philo FTW.

Re: SSH hacks – a little sanity for remote workers

#163

Post by lozf » Thu, Apr 30, 2020, 2:53 PM UTC

ransom1538 wrote: post #142

screen. If you are out there and you DO NOT want to lose your session due to a network error screen is for you! Even better, you can have your coworkers join your screen or reattach to it and watch you use ssh.

I loved screen in the 90's, but many of us prefer tmux these days.

Re: SSH hacks – a little sanity for remote workers

#164

Post by modo_ » Thu, Apr 30, 2020, 2:58 PM UTC

mrweasel wrote: post #87

m463 wrote: 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…

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.

Re: SSH hacks – a little sanity for remote workers

#165

Post by beagle3 » Thu, Apr 30, 2020, 2:58 PM UTC

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 (and does some UDP magic to make DNS work, but not UDP in general). It's only one way (no one on the destination network can "call you back", as you don't have an IP on that network). The only config is which network addresses get routed across the sshuttle (no policy / rules / firewall / anything else). You appear to come from the computer you shuttled to (so, unlike a real VPN, for better or worse - no policy along the way can tell you are coming from outside)

Re: SSH hacks – a little sanity for remote workers

#166

Post by snowwrestler » Thu, Apr 30, 2020, 3:14 PM UTC

mfontani wrote: post #111

snowwrestler wrote: post #84

Earlier 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…

Ah. I don't use forwarding so didn't consider that. Thanks.

Re: SSH hacks – a little sanity for remote workers

#167

Post by e12e » Thu, Apr 30, 2020, 3:26 PM UTC

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…

Note that upstream suggests rsync rather than scp in the general case. Of course pipes work too. I sometimes forget, and the remember half way through a big recursive scp operation. Just use rsync.

Re: SSH hacks – a little sanity for remote workers

#168

Post by mmalone » Thu, Apr 30, 2020, 3:57 PM UTC

pawurb wrote: post #81

2FA for SSH sounds great but I can only imagine how cumbersome it must be for using on a daily basis. I've recently started permanently locking my SSH ports and only briefly whitelisting them for only my IP with a bash scripts whenever the access is needed https://pawelurbanek.com/ec2-ssh-dynamic-access

Check out our single sign-on for SSH stuff at smallstep (where I work). Either in open source[1] or our product[2]. The hassle of 2FAing all the time is one of the big reasons I love single sign-on for SSH. Basically, you do 2FA when you're pushed through single sign-on. But then you're issued a short-lived certificate that gets put in your ssh-agent. You only need to 2FA to get a certificate. So you can tune 2FA challenge frequency based on certificate lifetime.

It's sort of like a browser session where you "login" and then you can browse until your cookie expires. Here you "login" and you can SSH until your certificate expires. So you have strong authentication, but you're only asked to do it periodically.

[1] https://smallstep.com/blog/diy-single-sign-on-for-ssh/

[2] https://smallstep.com/sso-ssh/

Re: SSH hacks – a little sanity for remote workers

#169

Post by aarbor989 » Thu, Apr 30, 2020, 3:59 PM UTC

lozf wrote: post #163

ransom1538 wrote: post #142

screen. If you are out there and you DO NOT want to lose your session due to a network error screen is for you! Even better, you can have your coworkers join your screen or reattach to it and watch you use ssh.

I loved screen in the 90's, but many of us prefer tmux these days.

Can I ask why? I've tried it out (albeit, very briefly), and it just seems like the same thing but with different command shortcuts. Is it just because it's newer?

Re: SSH hacks – a little sanity for remote workers

#170

Post by Steltek » Thu, Apr 30, 2020, 4:02 PM UTC

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.

scp and sftp will multiplex too. Remote tab-completion for file transfers also becomes much more approachable this way.

scp remote:~/err[tab] .[enter]

Also, bastion connections get multiplexed as well so connecting to multiple different hosts behind the bastion goes faster.