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

11–20 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#11

Post by kbenson »

I was tired enough of losing connections to work systems I was working on when network topology changes, or my laptop was moved, or it went to sleep, or I moved to a new computer (e.g. I'm at home) that I wrote a simple script to jump all my ssh connections through a VM at work, but with the extra step that the connection from the jump VM happens in a tmux that's named based on the desired host, and with options to reconnect to an existing session if it exists.

With the script named "go", Here's what that allows in practice:

go foo.bar - Connects to host foo.bar

go foo.bar - Second connection to host foo.bar that uses same session, so keystrokes show in both, even if they originate from separate locations, like home and work.

go foo.bar 2 - Additional param is added to session name, so you get a new connection to foo.bar.

go -list - Lists all connection sessions, and only connection sessions, because there's a special prefix to distinguish them from normal tmux sessions that might exist on the VM.

go -restore - Spawn a new terminal for all open connections. Useful for getting all terminals back after the network drops, or you reboot, or you're on your home computer instead of work, etc.

Currently this is implemented in a batch script on windows with some ugly hacks to make it work well with what PuTTY's command line options support (commands for the remote host need to be in a file you specify...), and it's pretty ugly, but I'll share if if anyone is interested. It would be much easier in bash with openssh (it's even possible OpenSSH supports enough features to do this in the ssh config).

Re: SSH hacks – a little sanity for remote workers

#12

Post by mmalone »

nprescott wrote: post #8
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…

This is a good one. I've used this in the past in order to get onto IPv6-only networks as well. In my case I don't have IPv6 enabled on my home internet (thanks Verizon!) and I had a tiny virtual machine with Vultr, which at their lowest price point aren't offering IPv4 address space any more. Using a jump through another machine with both 4 and 6 address space saved me from having to cough up more money solely for a…

You can also use the `ProxyJump` directive in your `~/.ssh/config`, which is the same as `-J` on the command line. So, for example:

    Host host_final
        ProxyJump user1@host1
will do the same thing as `-J user1@host`, but will allow you to just type:

    ssh user_final@host_final
If you're using an older SSH you can do this with a `ProxyCommand` (requires netcat on the jump box, but that's pretty standard):

    Host host_final
        ProxyCommand ssh user1@host1 nc %h %p
There are a bunch of variations on this technique, but these are the most common configs. Super easy transparent bastioning.

You can get really fancy with this stuff, particularly with `ProxyCommand`. We use it to trigger auto-login for our "Single sign-on for SSH" product at smallstep. When you have a `ProxyCommand` configured, instead of opening its own socket, OpenSSH just execs your proxy command and expects stdin & stdout to end up connected to a socket to the remote server. It doesn't care how that happens or what else happens before you get there. So we (ab)use this as a hook to check if you have a valid SSH certificate in your `ssh-agent` and, if you don't, trigger a single sign-on flow. It's nifty.

If you've never read the man pages for `ssh_config` and `sshd_config`, I highly recommend it. It's not that long and there's a lot of good stuff in there.

Re: SSH hacks – a little sanity for remote workers

#13

Post by mmalone »

davb wrote: post #10
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…

And in your ~/.ssh/config that's the ProxyJump directive. Adding a proper configuration for the bastion/jump host and for the target host means you can just to "ssh target". In my case, I usually do "ssh target -t tmux -2 att" to attach to my tmux session, then when I detach it will close the SSH connection (and all of my tunnels).

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?

Re: SSH hacks – a little sanity for remote workers

#14

Post by outluch »

mosh + tmux for sessions of uptime length

ssh-copy-id to never enter passwords again

~/.ssh/config add servers to never write hostnames etc again

and repo on gitlab with bash script that installs all of this and sets up own config of zsh and tmux for me on any new ubuntu server machine.

what else to dream about? curious

Re: SSH hacks – a little sanity for remote workers

#15

Post by montroser »

One that has come in handy a few times: When a machine is so starved for resources that it can't even allocate a pts for you, but you want to run some forensics, use `-T`:

    $ ssh -T user@host
Even if you're plumb out of file descriptors for example, you can run...

    $ ssh -T user@host lsof
...or whatever, and get your command output dumped to the screen, even if you don't get the niceties of a terminal.

Re: SSH hacks – a little sanity for remote workers

#16

Post by mxfurman »

montroser wrote: post #15

One that has come in handy a few times: When a machine is so starved for resources that it can't even allocate a pts for you, but you want to run some forensics, use `-T`: $ ssh -T user@host Even if you're plumb out of file descriptors for example, you can run... $ ssh -T user@host lsof ...or whatever, and get your command output dumped to the screen, even if you don't get the niceties of a terminal.

Whoa, this is cool. Been here an embarrassing number of times ...

Re: SSH hacks – a little sanity for remote workers

#19

Post by shawnz »

montroser wrote: post #15

One that has come in handy a few times: When a machine is so starved for resources that it can't even allocate a pts for you, but you want to run some forensics, use `-T`: $ ssh -T user@host Even if you're plumb out of file descriptors for example, you can run... $ ssh -T user@host lsof ...or whatever, and get your command output dumped to the screen, even if you don't get the niceties of a terminal.

Specifying a command to run automatically implies '-T'.

Re: SSH hacks – a little sanity for remote workers

#20

Post by downerending »

tashian wrote: post #7
downerending wrote: post #5

Earlier quoted context omitted.

Yup. I have no idea why they call it an escape character . It's an escape sequence , always of length two.

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.

Post reply on HN