Everyone probably already knows this, but enabling compression (-C) makes running remote X programs more usable over slower connections.
SSH hacks – a little sanity for remote workers
101–110 of 230 posts
Re: SSH hacks – a little sanity for remote workers
#102Re: 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…
Re: SSH hacks – a little sanity for remote workers
#104ssh 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.
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
#105The 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.
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
#106At 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…
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
#107I 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.
Re: SSH hacks – a little sanity for remote workers
#108Re: SSH hacks – a little sanity for remote workers
#109Everyone probably already knows this, but enabling compression (-C) makes running remote X programs more usable over slower connections.
It's not something I know a lot about. Is this where VNC steps in?
Re: SSH hacks – a little sanity for remote workers
#110Everyone 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.