Live data from Hacker News

SSH hacks – a little sanity for remote workers

smallstep.com

111–120 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#111
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 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 only grants access to my github repos, not to my bitbucket repos or to my DigitalOcean servers, or my Scaleway servers.

I have an SSH key for each "thing", and each key is kept in a different keyring via https://github.com/ccontavalli/ssh-ident, _precisely_ to avoid that problem.

As an example, an attacker gaining root on my Oracle Cloud free server will not be able to clone all my Github repos with it: I only use that key to connect to that server, and while I may have the github key unlocked at the same time - that's on a different keyring which the server has no visibility of.

Re: SSH hacks – a little sanity for remote workers

#112

Earlier quoted context omitted.

And while we're at it, if you need remote X, consider Xpra instead of ssh -X - it's way faster, can survive connection drops, and is far more flexible.

I've not heard of that, is it like VNC?

The best metaphor is "tmux for X programs": the X server runs on the same host as the X programs, xpra then "forwards" the windows over a configurable transport (e.g. via SSH) to the client. X was IIRC intended for local networks, so forwarding it over the Internet is sloooow (both by verbose protocol and naive latency handling) - this takes care of both issues.

IIRC it's written in Python, so it runs in most places: https://xpra.org/

Re: SSH hacks – a little sanity for remote workers

#113

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.

Another annoying "feature" is that opening a new shell with ssh -X will not enable the forwarding if the original master connection was not enabled with it.

Re: SSH hacks – a little sanity for remote workers

#114
post #21
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?

(Not OP) I personally don't type my advanced commands, I alias them. So I would use "ssh-target" as my alias there.

Same -- and I comment them heavily, so when (like today per this thread) I learn more about said advanced options, I'm "forced" to update my "docs". Always be capturing your knowledge! :)

Re: SSH hacks – a little sanity for remote workers

#115

Earlier quoted context omitted.

Another lesser known tunneling trick is that SSH will happily act as a SOCKS5 Proxy. I've been using this trick for going on 20 years now. Just do: ssh -D9090 user@remote Then, in Firefox, set it to use a SOCK5 proxy of localhost:9090 and "Proxy DNS when using SOCKS v5". Now, when you use Firefox it is as if you are using Firefox on the machine you are SSH'd into(including DNS resolution!). This is really handy for t…

Can I use this to potentially view a pdf on a remote server locally (as an alternative to an X server)? Would it be more efficient?

For those tasks I just use sshfs. I keep a ~/n/${host} directory where I access remote files like they were on my machine.

Re: SSH hacks – a little sanity for remote workers

#116
post #92

At your home install nss-mdns on Linux. It uses avahi for mDNS name resolution on your LAN. You can then forgo /etc/hosts and DHCP reservations between your machines at home. It is compatible with Mac's. I don't know what you can use on Windows for the purpose. Then to extend this a notch or two install Zerotier on all your hosts. Now you have virtual LAN between all your machines even outside of your home. It is P2P…

Strongly seconded! (Tossing some further dots to connect into the mix: Mosh and tmux and iTerm2's tmux integration fit very well in too. I think Visual Studio's Live Share should also work faster over ZeroTier - it should serve as a direct connection. I'm also really keen to try Emacs multiuser editing on a remote terminal over mosh and tmux.) And: I don't know if it's the placebo effect, but it seems to me that conn…

Connections on Zerotier itself often survive roaming. I was amazed when I went from tethering outside to home Wi-Fi and ssh session was still responsive. Although it can freeze and definitely can timeout. I'm yet to try mosh.

I did not hear about Live Share, but was planning on using Visual Studio Code Remote Development. For my current work ssh -CX is often enough for me. I also intend to use Xpra, as I found X2Go a bit more rough around the edges.

It could be interesting to measure the effect. Probably they did some testing already, but probably as you said - placebo ;)

Re: SSH hacks – a little sanity for remote workers

#117

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…

But if you use agent forwarding with other keys loaded into the agent, how does hat help?

Re: SSH hacks – a little sanity for remote workers

#119
post #62

> 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/

That's really smart!

I'd maybe even reverse it, having:

  Host my-jump-host
      Hostname my-jump-host.mydomain.example
      User myuser

  Host my-jump-host-*
      User myuser
      ProxyCommand ssh my-jump-host nc $(echo %h | sed 's/^my-jump-host-//') %p

This way, autocomplete in bash would work. Typing "ssh m", assuming m* doesn't match anything else, would suggest "ssh my-jump-host" (which I often ssh directly to anyway). Then just add "-myotherhost" so the whole sequence becomes "ssh m-myotherhost". Not a huge saving but I'm lazy and like autocomplete in the shell.

Re: SSH hacks – a little sanity for remote workers

#120

ssh not having support for --password argument is a big drawback. Usually requires to use some weird workarounds, especially when copying ssh keys to the machine are not an option.

It would put your password into your `~/.bash_history` and show up on the screen though; using a commandline argument to pass passwords is inherently unsafe. Sure you could have a secure system that only you use, but the people behind ssh cannot make that assumption. Removing the risk entirely is better than trusting the users. I'm sure there's a shell trick you could use to pass a password on the prompt anyway. For…

> It would put your password into your `~/.bash_history`

I'm fine typing (or pasting) my password in an interactive prompt when I'm interactively using it; that's not the problem. What I would like a --password option for is when I'm not interactively using it, like from a script. It'll still show up in the process list (ssh could overwrite it but there are some µs where it's there) but my laptop is single-user so that's no big deal.

> I'm sure there's a shell trick you could use to pass a password on the prompt anyway.

There is software that does it, but it's a real pain to find a short command that does it. Simply echo password | ssh user@host does not work, the openssh authors disabled that on purpose.

Ssh keys are, of course, the solution whenever possible, but that's not always possible. I'll be the first to admit that the legitimate uses for --password are rare, but they're definitely there and having to install extra software to make that crap work is just a real pain. I'd rather be able to shoot myself in the foot with unix tools.

Post reply on HN