Live data from Hacker News

SSH hacks – a little sanity for remote workers

smallstep.com

101–110 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#101
post #63

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

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.

Re: SSH hacks – a little sanity for remote workers

#103

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

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?

Re: SSH hacks – a little sanity for remote workers

#104

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 all other use cases, copy SSH keys securely.

Re: SSH hacks – a little sanity for remote workers

#105

The most gain I've had in the recent years was having vscode remote. Instead of fiddling with terminal editors forever, just have a decent ssh config with all your host, and connect instantly. Still looking for a way to make sftp/scp work fast.

I've tried that for a while but our servers / VMs are so slow (I/O is a bottleneck I suspect) that that was unworkable.

At the moment I use intellij which has a "sync with remote" function; I can run the things local and push them to the remote testing environment whenever I feel like it.

(my predecessor would use git a lot, ugh)

Re: SSH hacks – a little sanity for remote workers

#106
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 connections over ZeroTier are noticeably more responsive. Like slightly but noticeably.

Re: SSH hacks – a little sanity for remote workers

#107
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.

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.

Re: SSH hacks – a little sanity for remote workers

#109
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?

Re: SSH hacks – a little sanity for remote workers

#110
post #63

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

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?
Post reply on HN