0

I have a project that calls users' SSH servers to do some tasks. For now, I am storing users' passwords at my service as hashed (Username, hashed password and salt), but the SSH password (username, encrypted password and host address) is only encrypted by a known secret I have stored in server configurations with admin access only. The user count was very low, so that seemed okay, but now I'd like to improve this situation because I'm afraid that if my database or server gets accessed, they can access my users' servers too.

My question is how to store SSH credential my service needs to do maintenance job for other users?

Okoba
  • 5
  • 2
  • you can encrypt them with an unstored password that must be entered by a human each time the system reboots. – dandavis Jan 22 '23 at 10:00
  • I hoped for a better way to handle users passwords. And the risk of your way is that if the server restarts, it will need human interfere and risk of lower availability as it is a manual task. – Okoba Jan 22 '23 at 10:43
  • welcome - so in summary you have: 1) a number of `ssh` commands that run periodically and automatically and must be able to do so with no human intervention; 2) an offline copy of your db that contains all the various `ssh` credential meta and which you're concerned might be stolen; and 3) you also want to mitigate the risk that your live server is accessed leaving the decrypted `ssh` credentials exposed? – brynk Jan 22 '23 at 10:44
  • @brynk thank you and yes. I like to improve the situation of handling users SSH credentials, in anyway that I can. – Okoba Jan 22 '23 at 10:47
  • as far as i'm aware, due to the automation the best you can hope for is to spread the risk - assuming you want these jobs to run and results logged on the maintenance server? would it be possible to kick the job off on your maint.svr, but from a different "kick-off" host? ie. from the kick-off host, connect to maint.svr and launch client job with `ssh` new creds, wait a bit, then connect to the client host and replace the creds, so connection to client hosts from the maintenance host is quickly disabled, eg. via api or as @mentallurg suggests using `ssh` public keys in `authorized_keys` – brynk Jan 22 '23 at 11:19
  • See similar question at https://security.stackexchange.com/questions/12332/where-to-store-a-server-side-encryption-key. – mti2935 Jan 22 '23 at 11:31
  • @brynk As I commented on the answer, I don't have access to the client except using SSH. Is there a way for me to create new credentials for the client? – Okoba Jan 22 '23 at 11:32

1 Answers1

4

Using passwords can be dangerous. If the attacker has already a legal access to some users' servers, then obtaining users' passwords will allow switching to their accounts.

You can use key pairs for SSH login to their servers. Generate a key pair for each server and put private keys to your server. Rotate the keys time to time, so that even if the attacker obtained private keys, they will be valid for some limited period of time. Allow SSH access to users' servers from particular IPs or IP ranges only. If users use already key pairs for SSH access, your key pairs should be independent on those.

Then in a worst case the attacker will obtain only private keys for SSH access. Users' passwords will remain secret. And the attacker will not be able to use these keys from arbitrary IPs, but only from those that you allowed. Also, as Steffen Ulrich suggested, you can restrict what commands can be executed on the SSH server.

mentallurg
  • 10,256
  • 5
  • 28
  • 44
  • So in summary you suggest, moving from password to special ssh keys, and use better firewall rules to only access from my servers. But in this way, if again my server get accessed, with those keys, they can access the users servers and do malicious things to them, right? – Okoba Jan 22 '23 at 10:54
  • @Okoba: Correct. The difference to using passwords is, that it will have less risks compared to using passwords. Knowing passwords, the attacker can get an idea about how particular users generate their passwords, are there any patterns or they seem to be random. Also passwords remain unchanged for a relatively long time, because of usability. Where as you can rotate keys as often as you want, e.g. every time you login to the your server. – mentallurg Jan 22 '23 at 11:04
  • @Okoba: If the attacker can compromise your account, then the attacker can do everything *you* can do, no matter how you access the users' servers. If you want to run some jobs *automatically*, so can do also the attacker. The normal way to prevent this is to require some interaction with you, e.g. enter some password after each reboot, as "dandavis" suggested. If this is an option to you, you can encrypt all private keys and decrypt them only manually, by entering a password after each reboot. – mentallurg Jan 22 '23 at 11:13
  • Thank you. Can you elaborate more on "rotating keys"? How can I change client keys? I don't have access to their server except using the SSH connection, secured by a password or key that the user provided. – Okoba Jan 22 '23 at 11:30
  • By rotating I mean generation and replacement of the keys. If you have SSH access, you can configure user server to accept key pair login, generate a key pair and put public key on the user server. The private key remains on your server. In your .ssh/config you can specify what private key you want to use for what server. Then time to time generate a new key pair, login to the user server, put there new public key and remove the old one. – mentallurg Jan 22 '23 at 11:45
  • 1
    *"And the attacker will not be able to use these keys from arbitrary IPs,"* - to add to this hardening advice: [restrict the commands the client can actually run](https://www.virtono.com/community/tutorial-how-to/restrict-executable-ssh-commands-with-authorized-keys/) so that the impact of a compromise is reduced. – Steffen Ullrich Jan 22 '23 at 12:26
  • Thank you. I can not upvote but I will accept this as the answer. Although I like to find better options if there will be any. – Okoba Jan 22 '23 at 12:40
  • @SteffenUllrich: Thanks. – mentallurg Jan 22 '23 at 15:49