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?

Improve this question
7
  • you can encrypt them with an unstored password that must be entered by a human each time the system reboots.
    – dandavis
    Commented Jan 22, 2023 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
    Commented Jan 22, 2023 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
    Commented Jan 22, 2023 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
    Commented Jan 22, 2023 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
    Commented Jan 22, 2023 at 11:19

1 Answer 1

Reset to default
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.

Improve this answer
7
  • 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
    Commented Jan 22, 2023 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
    Commented Jan 22, 2023 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
    Commented Jan 22, 2023 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
    Commented Jan 22, 2023 at 11:30
  • 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 so that the impact of a compromise is reduced.
    – Steffen Ullrich
    Commented Jan 22, 2023 at 12:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .