2FA for SSH sounds great but I can only imagine how cumbersome it must be for using on a daily basis. I've recently started permanently locking my SSH ports and only briefly whitelisting them for only my IP with a bash scripts whenever the access is needed https://pawelurbanek.com/ec2-ssh-dynamic-access
SSH hacks – a little sanity for remote workers
81–90 of 230 posts
Re: SSH hacks – a little sanity for remote workers
#82> 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 use the Socks-Proxy only for internal Websites:
You habe to create a local "proxy.pac" file with the following contents:
function FindProxyForURL(URL,host) { host = host.toLowerCase(); if (shExpMatch(host,"*.my-company.com")) { return "SOCKS5 127.0.0.1:9090"; } return "DIRECT"; }
Then set "file:///path/to/proxy.pac" as auto-config URL in the Firefox-proxy-settings. Don't forget to enable DNS-Requests over SOCKS5.
For services, which you can't proxy with SOCKS5, you can use LocalForward in your ssh_config: Match host your-workstation !exec "nc -vz xmpp.my-company.com 5222 &>/dev/null || { echo 'xmpp.my-company.com not reachable, using LocalForward' 1>&2 && exit 1 ; }" LocalForward 127.0xcafe1:5222 xmpp.my-company.com:5222
Then add the following line to your /etc/hosts: 127.12.175.225 xmpp.my-company.com
Re: SSH hacks – a little sanity for remote workers
#83Earlier 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…
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???
Re: SSH hacks – a little sanity for remote workers
#84I 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 private keys for separate servers doesn't help if they're all sitting next to each other on one device.
I do set a password on my private key, though.
Re: SSH hacks – a little sanity for remote workers
#85Are 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?
Re: SSH hacks – a little sanity for remote workers
#86Earlier quoted context omitted.
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…
I think it's purely for performance, but it does make a big difference. There's a lot of round trips to set up an SSH connection, and depending on the RTT to the server, that can feel like a real delay if there's another host in the connection. If you use a Proxy host for jumping, and it's got a better RTT to most servers you connect to, reusing the existing connection to it might actually make it feel like it connec…
This is especially important in some cases where you have local shell wrappers around commands that execute on a remote server with SSH.
I do this for my email, for example, where the actual programs for dealing with my email sits on a server, but on each host I have shell scripts with the same name as the original program, except all they do is SSH to the server and run the actual program there. When navigating a GUI that runs these shell wrappers, you get a lot of opening and closing of SSH sessions very quickly.
Re: SSH hacks – a little sanity for remote workers
#87I 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
#88One that has come in handy a few times: When a machine is so starved for resources that it can't even allocate a pts for you, but you want to run some forensics, use `-T`: $ ssh -T user@host Even if you're plumb out of file descriptors for example, you can run... $ ssh -T user@host lsof ...or whatever, and get your command output dumped to the screen, even if you don't get the niceties of a terminal.
Specifying a command to run automatically implies '-T'.
Unless you have "RequestTTY yes" in your ~/.ssh/config.
Re: SSH hacks – a little sanity for remote workers
#89Earlier 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…
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.
Re: SSH hacks – a little sanity for remote workers
#90My favorite SSH trick is to have a machine at work SSH back to my home domain, and provide a tunnel back for Remote Desktop or what have you. Wee, no VPN to deal with. No lack of a VPN for remote access to deal with. https://cygwin.com/pipermail/cygwin/2020-April/244384.html
That's likely to be a firing offence, no? If I were running things I wouldn't want employees deliberately subverting my network's security measures in the name of their own convenience.
If you have to spend time wrestling the VPN while you're on the clock, that's their own time being wasted.