SSH hacks – a little sanity for remote workers • Hacker News Board

Re: SSH hacks – a little sanity for remote workers

#91

Post by Piskvorrr » Thu, Apr 30, 2020, 9:16 AM UTC

snowwrestler wrote: post #84

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…

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…

It leaks information: "we have seen this one pubkey on multiple servers, therefore it's likely to be a key for everything plus the kitchen sink"

Re: SSH hacks – a little sanity for remote workers

#92

Post by hawski » Thu, Apr 30, 2020, 9:18 AM UTC

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 and does hole punching and whatever you need to work. You can connect to your computer via tethering from a puny little laptop while sitting on a bench outside your house. If you are a home admin for your family you can add those computers to your virtual LAN. Or your friends can also join. Then you can easily share photos or whatever straight with Samba or even an intranet of sorts.

Re: SSH hacks – a little sanity for remote workers

#93

Post by Piskvorrr » Thu, Apr 30, 2020, 9:19 AM UTC

MaxBarraclough wrote: post #89

orbitingpluto wrote: post #79

Earlier quoted context omitted.

I used to do this all the time over port 53. My closest coffee shop would allow people to access Wi-Fi only if you gave them full access to your Facebook account. DNS was the only port open to the outside world.

Interesting that they permit TCP port 53, rather than just UDP port 53.

My guess is that it stems from lax firewall defaults. "Allow port 53 - [tcp/udp/BOTH]?" (Yeah, I know that DNS can also work over 53/tcp, but it's rare compared to the 53/udp volume)

Re: SSH hacks – a little sanity for remote workers

#94

Post by zepearl » Thu, Apr 30, 2020, 9:19 AM UTC

kqr wrote: post #85

Are the numbers for the ServerAliveCountMax and ServerAliveInterval accidentally swapped? Wouldn't it make much more sense to check every second, and fail if five consecutive checks failed, rather than check only every five seconds, and then fail immediately if one check is dropped due to very transient network issues?

Yeah, I would set as well a higher value for "ServerAliveCountMax".

Re: SSH hacks – a little sanity for remote workers

#95

Post by kubanczyk » Thu, Apr 30, 2020, 9:23 AM UTC

MaxBarraclough wrote: post #89

orbitingpluto wrote: post #79

Earlier quoted context omitted.

I used to do this all the time over port 53. My closest coffee shop would allow people to access Wi-Fi only if you gave them full access to your Facebook account. DNS was the only port open to the outside world.

Interesting that they permit TCP port 53, rather than just UDP port 53.

RFC7766 "Recursive server (or forwarder) implementations MUST support TCP so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients."

large responses == some DNSSEC, some IPv6

Re: SSH hacks – a little sanity for remote workers

#96

Post by Piskvorrr » Thu, Apr 30, 2020, 9:23 AM UTC

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/

Whoa! Now that's mighty useful, thanks! (Note that this works even without the ProxyJump option, but requires a sane netcat on the jumphost; older busyboxes only had a netcat)

Re: SSH hacks – a little sanity for remote workers

#97

Post by skocznymroczny » Thu, Apr 30, 2020, 9:25 AM UTC

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.

Re: SSH hacks – a little sanity for remote workers

#98

Post by Piskvorrr » Thu, Apr 30, 2020, 9:26 AM UTC

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…

It's not even establishing the connection: it just goes through the existing ControlMaster. This gets me about ~0.5 sec for a fresh connection, and just-about-instant response for a multiplexed one.

Re: SSH hacks – a little sanity for remote workers

#99

Post by Piskvorrr » Thu, Apr 30, 2020, 9:32 AM UTC

axegon_ wrote: post #60

A few I can't live without off the top of my head: * "-D" for ssh tunneling. * "-L" for forwarding all traffic on a specific port. * sshfs - mount small directories over ssh on your local machine (works with big ones but way too slow, for big ones I go rsync).

If you work with a large tree where a few files at a time change, you may want to look at lsyncd - backed by inotify and rsync, syncs the local changes to remote. Not really suited for interactive edits, but if you find yourself running rsync in a loop, this is a better replacement.

Re: SSH hacks – a little sanity for remote workers

#100

Post by Piskvorrr » Thu, Apr 30, 2020, 9:33 AM UTC

asdff wrote: post #64

xioxox wrote: post #63

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

Changing the cipher supposedly helps, too. Probably placebo though.

That's obsolete advice: could have helped 10+ years ago...