4 ms·

This tool makes me afraid. Anyone that can successfully use AutoSSH is not monitoring their private key usage. You should always need to approve each time your

This tool makes me afraid. 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.

epimenov 11y ago
I have a key generated for AutoSSH only. 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 Pretty nifty.
- sleepychu 11y ago
  On the server side, right?
  - creshal 11y ago
    Yes, in the authorized_keys
- tomkinstinch 11y ago
  I've gone so far as to create a separate autossh user with separate key, with no shell access (by setting the user's shell to /bin/false). It still permits tunneling (call ssh with -N), but does not allow shell sessions. Perfect for when you want to access remote systems via a remote tunnel but do not want to give shell access on the relaying machine to the tunnel origin. It trusts that the machine originating the tunnel will not initiate a reflection attack (by making a local forward to the remote port itself on the originating machine and causing some log messages to appear until all file descriptors are in use)[1], but that's not so unreasonable. 1. http://www.semicomplete.com/articles/ssh-security/ http://www.semicomplete.com/articles/ssh-security/
  - epimenov 11y ago
    Same here actually, the user has /bin/false as shell.
everythingcli 11y ago
This is not how it is meant. When you use AutoSSH/SSH and need to enter a password for your key anytime you do a connection (which probably happens every 10min as a system engineer/admin/etc) it is probably useless. 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.
- Tiksi 11y ago
  On top of that, you can always use a separate user for the tunnel that doesn't have a login shell. Obviously still a problem if someone gets the private keys but not nearly as much so, as they'll basically be limited to tunneling/forwarding.
- everythingcli 11y ago
  @Tiksi: 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`.
dspillett 11y ago
The tool does nothing more in that sense than SSH itself. If you have an unprotected key it doesn't matter if you use it with just core SSH tools, your own scripts to restart things upon connection difficulty, or tools like AutoSSH. 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.
pjc50 11y ago
You should always need to approve each time your SSH key is used Why? I don't need to retype my password for every line of shell executed.
- VLM 11y ago
  Please don't give "them" ideas, thank you.
scbrg 11y ago
Interesting. Does ssh-agent(1) also make you afraid? http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-agent.1 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
- daurnimator 11y ago
  The default settings are bad for the majority of sysadmins. See http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec 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.
  - LinuxBender 11y ago
    That is bad. Even worse was a default that the OpenSSH developers quietly added and folks have become addicted to. It also enables me to phish any company and get access to all their servers, bypassing 2FA with almost no logging. 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.
    - Piskvorrr 11y ago
      Does that boil down to "if root is malicious, Bad Things can happen to other users"? Well...duh. Why not keylog all terminals instead of fumbling with ssh-agent and connection multiplexing?

epimenov 11y ago

I have a key generated for AutoSSH only. 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 Pretty nifty.

sleepychu 11y ago
On the server side, right?
- creshal 11y ago
  Yes, in the authorized_keys
tomkinstinch 11y ago
I've gone so far as to create a separate autossh user with separate key, with no shell access (by setting the user's shell to /bin/false). It still permits tunneling (call ssh with -N), but does not allow shell sessions. Perfect for when you want to access remote systems via a remote tunnel but do not want to give shell access on the relaying machine to the tunnel origin. It trusts that the machine originating the tunnel will not initiate a reflection attack (by making a local forward to the remote port itself on the originating machine and causing some log messages to appear until all file descriptors are in use)[1], but that's not so unreasonable. 1. http://www.semicomplete.com/articles/ssh-security/ http://www.semicomplete.com/articles/ssh-security/
- epimenov 11y ago
  Same here actually, the user has /bin/false as shell.

everythingcli 11y ago

This is not how it is meant. When you use AutoSSH/SSH and need to enter a password for your key anytime you do a connection (which probably happens every 10min as a system engineer/admin/etc) it is probably useless. 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.

Tiksi 11y ago
On top of that, you can always use a separate user for the tunnel that doesn't have a login shell. Obviously still a problem if someone gets the private keys but not nearly as much so, as they'll basically be limited to tunneling/forwarding.
everythingcli 11y ago
@Tiksi: 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`.

dspillett 11y ago

The tool does nothing more in that sense than SSH itself. If you have an unprotected key it doesn't matter if you use it with just core SSH tools, your own scripts to restart things upon connection difficulty, or tools like AutoSSH. 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.

pjc50 11y ago

You should always need to approve each time your SSH key is used Why? I don't need to retype my password for every line of shell executed.

VLM 11y ago
Please don't give "them" ideas, thank you.

scbrg 11y ago

Interesting. Does ssh-agent(1) also make you afraid? http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-agent.1 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...

daurnimator 11y ago
The default settings are bad for the majority of sysadmins. See http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec 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.
- LinuxBender 11y ago
  That is bad. Even worse was a default that the OpenSSH developers quietly added and folks have become addicted to. It also enables me to phish any company and get access to all their servers, bypassing 2FA with almost no logging. 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.
  - Piskvorrr 11y ago
    Does that boil down to "if root is malicious, Bad Things can happen to other users"? Well...duh. Why not keylog all terminals instead of fumbling with ssh-agent and connection multiplexing?