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

211–220 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#211

Post by Jedd »

kazinator wrote: post #196
Jedd wrote: post #49

Earlier quoted context omitted.

I worked for an organisation that decided to stop outbound SSH for reasons that weren't adequately well explained, exceptions were painful to get re-applied, so most people just cranked up corkscrew and did precisely this. Only challenge is that getting corkscrew compiled on Windows is a massive pain. [n] https://github.com/bryanpkc/corkscrew

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.

Re: SSH hacks – a little sanity for remote workers

#212

Post by pletnes »

xelxebar wrote: post #52
mmalone wrote: post #13

Earlier quoted context omitted.

That `tmux` bit is clever. Wonder if you could do that in a `ForceCommand` or something like that so you don’t need to type that part either?

A combination of `RemoteCommand` and `RequestTTY` should do the trick: Host ... RequestTTY yes RemoteCommand tty The problem is that this will mess up your one-off command invocations of ssh, git ssh connections, etc : $ ssh ls Cannot execute command-line and remote command. However, we can use `Match` blocks to get around that! There are a thousand ways to skin this cat, but one way is to use an environment variable…

I simply have two configs for machines I ssh to often - one to the «normal shell» and one to a tmux instance with standard name.

Re: SSH hacks – a little sanity for remote workers

#213

Post by pletnes »

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…

Also for tab completion of directories to rsync on the remote. Otherwise you’d have to type your password on every . You can use ssh keys and agents to achieve the same, but it’s much slower, and harder to set up IMO.

Re: SSH hacks – a little sanity for remote workers

#214

Post by beagle3 »

mmalone wrote: post #206
beagle3 wrote: post #157

Earlier quoted context omitted.

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…

That works for bastions, but not other use cases. One common one is pushing & pulling from git on a remote dev box. Or if you want to SCP something between remote machines without having to pull it down locally. Agent forwarding is the best way to do this (outside of possibly generating an ephemeral key pair and copying public keys around for a single use then destroying them... but ain’t nobody gonna do that).

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

Re: SSH hacks – a little sanity for remote workers

#215

Post by jarvist »

zengargoyle wrote: post #107
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.

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.

I have these shell aliases configured, to check and delete the master connections. (Often I end up with stale connections when I have a VPN up, and then just sleep my laptop.)

alias ssh-MasterConnection-check="ssh -O check " alias ssh-MasterConnection-exit="ssh -O exit "

+ then you use them as 'ssh-MasterConnection-check host' etc.

Re: SSH hacks – a little sanity for remote workers

#216

Post by GrinningFool »

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…

     ssh-copy-id -i ~/.ssh/id_x_ed25519.pub x
Thanks for mentioning this - I've been SSH'ing for a long time and never run across it.

Re: SSH hacks – a little sanity for remote workers

#217

Post by d33 »

Surprise not to see tmate.io get more attention:

https://tmate.io

It's packaged for most Linux distributions and offers a seam-less "share your terminal" experience over the web. Has an optional read-only mode. Users can access the terminal via https and ssh. Great for low-bandwidth videoconferencing.

Re: SSH hacks – a little sanity for remote workers

#218

Post by davidcollantes »

itsjloh wrote: post #62
segfaultbuserr wrote: post #4

> What are your favorite SSH tips & tricks? $ ssh -J user1@host1 user_final@host_final or $ ssh -J user1@host1,user2@host2 user_final@host_final Not many people know it, you don't need to launch a SSH within a SSH session - SSH has built-in support of using one SSH server as a proxy to another SSH server. Useful for hacking servers accessing servers behind a firewall, or using your own server as a proxy to bypass a b…

Jump hosts are fantastic! With a little bit of sed magic you can also setup wildcard jump hosts, eg: Host *-via-dc1 ProxyCommand ssh you@jump-01.example.com nc $(echo %h | sed 's/-via-dc1$//') %p I wrote about it ages ago here https://jloh.co/posts/dynamic-ssh-jump-hosts/

Let's say all machines are named in the form "vm12345," but the jump server itself is also named in the same form. How would you go to include all vm in a wildcard, but the jump server itself?

Re: SSH hacks – a little sanity for remote workers

#219

Post by mmalone »

beagle3 wrote: post #214
mmalone wrote: post #206

Earlier quoted context omitted.

That works for bastions, but not other use cases. One common one is pushing & pulling from git on a remote dev box. Or if you want to SCP something between remote machines without having to pull it down locally. Agent forwarding is the best way to do this (outside of possibly generating an ephemeral key pair and copying public keys around for a single use then destroying them... but ain’t nobody gonna do that).

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 AWS (there are a variety of reasons this may be preferential or even required). If I'm pushing & pulling code from GitHub to/from this development instance I'm gonna need to either have a private key on that development instance or have agent forwarding back to my local.

Now suppose I want to copy a large database snapshot between two instances on EC2. There are obvious benefits to being able to transfer directly between these two instances, on the same private network, versus bringing the data to your local (where you might not even have sufficient disk space) and pushing it back up.

Not sure what other use cases exist, but these two alone I think justify the existence of agent forwarding.

SSH agent forwarding does have subtle security issues. But so does putting a private key on a remote server. If you're the only one who has access to the remote server, neither option is problematic. If someone else has root, and you don't trust that person, then both are problematic (and which is worse is debatable).

Re: SSH hacks – a little sanity for remote workers

#220

Post by rubatuga »

downerending wrote: post #20
tashian wrote: post #7

Earlier quoted context omitted.

And on an international keyboard it’s ~~, because ~ defaults to being a character modifier. If you nest SSH sessions, then you add more ~s. So in your fifth nested SSH session on an international keyboard the escape sequence would be \n~~~~~~~~~~.

Hmm. Is that right? I thought you could type ~~ to send a ~ through to the destination. So, ignoring the international aspect, I was thinking you'd type ~ to escape your first target, ~~ for the second, ~~~~ for the third, and ~~~~~~~~ for the fourth. (Too lazy to test it.) Perhaps better is to set a different escape char for layers you care about.

I think the parent is still right, just a problem with international keyboards.
Post reply on HN