It also has much better performance when used over a flaky connection because it doesn't do TCP-over-TCP.
It doesn't really create a persistent tunnel like this thingy, but it seems worth mentioning to people who might find autossh interesting.
sshuttle –dns -rv firstname.lastname@example.org 0/0 –exclude 192.168.0.0/9 # start sshuttle
-rv remote server details (v for verbose output)
-exclude to not send traffic from local addresses over the link (not sure if this is required)
Our prototype used autossh actually but later we needed something a bit easier to manage. Disclaimer: I am not a networking or security expert.
while true; do ...; done
... Some scripts use a while loop, others encourage you to run a remote command (such as tail) to make sure you don’t run into timeout and various others. But actually, you don’t want to re-invent the wheel and stick to bullet-proof already existing solutions.
but the only case where that makes sense, and where a simple while loop will fail you, is if the ssh command hangs. Only then will this start making sense.
Very quickly, the "simple loop" starts being decidedly unsimple, and you'll find yourself reinventing a square wheel. Been there, done that. Then I found that someone else has already been through the same issues and made a comprehensive tool for it: autossh.
On the other handle it comes off as much too hacky for something I'd trust my production services with. It also involves two levels of authentication (PKI + whatever is built-in to the system).
Description=SSH remote forwarding to here
ExecStart=/bin/ssh -N -o PasswordAuthentication=no -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 2222:localhost:22 -o TCPKeepAlive=yes -p 9196 -i /home/autossh/.ssh/autossh email@example.com
Anyone that can successfully use AutoSSH is not monitoring their private key usage. You should always need to approve each time your SSH key is used; whether via typing in your password, swiping your smartcard, or pressing the button on your yubikey.
I have many different SSH keys, each with different long passwords.
What u are looking for is `ssh-agent` which can take care of all the password handling.
Also unattended rsync (over ssh) backups rely on no user interaction at all.
Couldn't reply to your thread directly, so here:
It shouldn't be a problem when someone steels your key. At least not when it is protected with a strong password.
As I said, you can and should always use `ssh-agent` and protect all of your keys with a password.
Now that it was mentioned, I am really not sure, if `ssh-agent` also works for processes started by `cron`.
Why? I don't need to retype my password for every line of shell executed.
Also you can limit to which hosts/ports it can connect with:
no-agent-forwarding,no-X11-forwarding,command="read a; exit",permitopen="host:port" ssh-ed25519 AAAA
Sometimes unprotected keys are unavoidable for automated admin functions - in this case you have to be careful what access is granted to logins via those keys, and be extra careful to secure the keys themselves including (if you don't generally) having a revocation procedure in place (even if that is as simple as a list of locations the key is accepted to you can remove it from them all) so you can easily deal with one being compromised.
With the ssh-agent defaults, if I have root/sudo access on a server you are logged into with ssh on, I practically have free use of your private SSH key.
I use gpg's ssh-agent emulation (See the man page for gpg-agent under --enable-ssh-support), and store my ssh private key on my yubikey. With this setup, the yubikey's light flashes when something wants to use my private key, and you can just touch the button on it to approve.
Yes, root can also simply `su - user` and then do all stuff you do.
But you should also not put YOUR private keys on a system that has a root user who should not have access YOUR keys.
> The problem with ssh-agent defaults is that someone with root on the server you're SSH'd into can use your SSH private key (which is on your local machine).
> ssh-agent is like temporarily uploading your private key to each remote server logged into.
That is very different (and much more common) than an attacker having root on your local machine.
Some time read up on SSH Multiplexing. The default is MaxSessions 10. You auth once, my phishing exercise can utilize your session to connect anywhere you have connected. Nothing will show up in syslog. I can take care of `lastlog` entries since folks cache sudoer privs for so long; or in some cases, don't even require a pw.
I will set up a github with a working example of how to set up a backdoor leveraging ssh multiplexing. I got the idea from a coworker (whitehat) that used a simple ruby script to completely pwn my system. The cool part is, it doesn't require exploiting anything beyond the helpful developer or sysadmin.
ssh-agent is like temporarily uploading your private key to each remote server logged into.
The GP is mixing together SSH agent with agent forwarding, and private keys with key signing by agent.
There is last week's CVE-2016-0777, which is a vulnerability that enables the exploit you are describing, but in a properly patched configuration, without agent forwarding (nb: this feature is off by default), this is not the case. Same with connection multiplexing: off by default (for good reasons). In other words, either a) please explain how that would work, or b) please stop spreading FUD.