Live data from Hacker News

SSH hacks – a little sanity for remote workers

smallstep.com

121–130 of 230 posts

Re: SSH hacks – a little sanity for remote workers

#121

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

I have been doing the same thing for awhile. It allows me to access all the services we have set up on the intranet in the office. With Tmux I move around from machine to machine and keep all the work stuff in the office.

The office is also a large university. Therefore, I have access to many additional library and other subscription services.

It’s great as a lot of the office struggled to get a work setup in place. I’m happily the only one who didn’t need Gotomypc. It also helped me save time durning this transition by not having to answer my less technical coworkers questions about getting Gotomypc set up.

Re: SSH hacks – a little sanity for remote workers

#122
I often ssh then open a vim on the server. But it would make more sense to me if vim had support for open remote files via its own ssh connection instead. Does this exist (for vim or some other editors)? Then I could always use my local config and it would be easier to type on a bad connection.

Re: SSH hacks – a little sanity for remote workers

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

I don't know much about it, but I'm fairly sure that compressing the Xorg data stream with lossy compression is going to mess it up completely and would require a complete overhaul of the protocol to make that work. VNC is indeed the more standard unix thing (insofar as remote GUIs can be considered standard on unix-likes) that applies lossy compression to the pictures being sent over.

Re: SSH hacks – a little sanity for remote workers

#124
post #122

I often ssh then open a vim on the server. But it would make more sense to me if vim had support for open remote files via its own ssh connection instead. Does this exist (for vim or some other editors)? Then I could always use my local config and it would be easier to type on a bad connection.

i don't know about vim but in emacs tramp mode allows this. However, you could just mount the remote filesystem via sshfs which makes it work everywhere (its slow though).

Re: SSH hacks – a little sanity for remote workers

#125

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.

> My closest coffee shop would allow people to access Wi-Fi only if you gave them full access to your Facebook account. What the???

I've seen this on Ubiquity hardware as an option too. Apparently it requires you to "check-in" via facebook to use it, whatever that means exactly. There is also an option to login via facebook without this though.

Re: SSH hacks – a little sanity for remote workers

#126
post #122

I often ssh then open a vim on the server. But it would make more sense to me if vim had support for open remote files via its own ssh connection instead. Does this exist (for vim or some other editors)? Then I could always use my local config and it would be easier to type on a bad connection.

Emacs supports e.g. /ssh:my.server.net:/path (with host name completion too e.g. /ssh:my.)

Re: SSH hacks – a little sanity for remote workers

#127

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.

> Still looking for a way to make sftp/scp work fast.

Making it fast while still using it, not sure. But I can share an alternative, since a friend had the same issue and this was a literally ten times faster for a lot of small files (in the order of 30 minutes instead of 5 hours):

    cd path/to/target/location
    ssh user@target 'tar c /tmp/example' | tar x
Quick guide to tar, since it's super simple:

    c for compress
    x for extract
    f for file (since we send it to stdout / read from stdin, I don't use the f option)
    v for verbosity (not sure if that works on the remote side)
    z for zlib compression (ssh can do compression already, so also unused here)
    t for testing (reading) an archive without extracting it ("tar tv 
That's all I've ever needed.

So what this will do is run "tar create " on the remote system and, tar being a classic tool, it'll just output that binary archive data to stdout since you didn't specify a file ("tar cf your.tar "). On the receiving side, you pipe it to another tar command that reads from stdin (since, again, no file was specified) and extracts the files from the incoming data stream.

Re: SSH hacks – a little sanity for remote workers

#128

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.

i think that is fine actually. however, if i would implement such thing i would probably redirect DNS traffic to my DNS server as long as you are not authenticated :)

Re: SSH hacks – a little sanity for remote workers

#129
This reminds me of the ugliest hack I have ever written.

For context: passwords rotate every 90 days, there are different passwords for client facing and "internal" servers, (and different passwords for linux machines vs Windows machines).

All connections to client facing servers (which is my job) must go via:

1) a VPN

2) a "local" jumphost (both ssh/rdp), only accessible via VPN

3) a "remote" jumphost (also, both ssh/rdp), only accessible via the "local" jumphost".

Additionally; The majority of my servers are Windows based.

So, what do you do when everything goes wrong? well, you VPN with your "normal" password, and your 2FA RSA token. Then you rdp (or SSH) to the local jumphost with the same password as the vpn, then you rdp (or, ssh) to the remote jumphost with a different password, then you finally RDP into the machine that is interesting.

So, being the lazy git that I am, I wrote a program that scrapes my passwords from 1password, and ssh's into those jumphosts creating a tunnel all the way through. Then I call freerdp on localhost.

For this to work I had to do a bunch of ugly things like:

1) figure out the dimensions of my display and scale everything, because freerdp doesn't do this automatically.

2) call python from bash because getting a unique random socket requires binding to "port 0" which is not something I think is possible inside of bash.

3) do the same on each hop.

4) determine which password is needed based on the "domain" of the machine

5) detect if the machine is actually accessible or not (IE; are you on the VPN? is the machine actually "local"?)

Anyway, I should share the code, we can all revel in its ugliness.

Re: SSH hacks – a little sanity for remote workers

#130

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.

True, but I never see SSH go down, unless there's a network issue, in which case I lose all my connections anyway.
Post reply on HN