How Can I Secure Credentials in a Scheduled Task for SSH Commands?

0
1
Asked By CleverPanda57 On

I'm trying to set up a scheduled task that runs some SSH commands on a device, but it requires a password, and I'm concerned about security. I've been exploring options, but I'm looking for advice on how to run this task safely. I know you typically encrypt the password, either through built-in options or third-party secret management tools, but I have my doubts about whether that's enough. Here are some considerations:

- I shouldn't run this task as SYSTEM because any admin, including potentially compromised ones, could access and decrypt the password.
- Scripts can be edited or replaced, even signed ones, to expose sensitive information like passwords.
- I'm considering base64-encoding the whole script to include it as an argument, but I'm worried about argument length limitations in scheduled tasks and I still need the service account password to update it.

It would be great if powershell.exe could check a file's hash before executing it, but I recognize that I need the service password to alter the scheduled task. Using '-ExecutionPolicy RemoteSigned' doesn't seem reliable since a malicious script can still be signed with a valid certificate. Any advice on best practices for securing this kind of scheduled task?

5 Answers

Answered By InfoSeeker20 On

Quick note — base64 encoding is not actually encryption! It's easily reversible, so it won’t provide the security you're looking for. Just something to keep in mind while you're working on this!

CleverPanda57 -

Thanks for the clarification! I had the wrong idea about that.

Answered By SafetyNinja99 On

There are definitely multiple layers you can add to this process. Start by restricting access to the server itself; if you can keep unauthorized users out, modifying scripts becomes trickier. Use the Secret Management Module so your script doesn't contain hardcoded passwords. Also, enforce signing of scripts and manage trusted certs through Group Policy. Make sure your scripts are stored securely with the right permissions so that only your gMSA has read access. This way, you'd minimize risks while keeping your server as secure as possible.

ProactiveOtter37 -

I appreciate that! We already restrict server access. Managing the Trusted Publishers is a new angle I hadn’t considered.

Answered By TechieGiraffe42 On

You're already touching on some crucial points. If you want to protect the script from admins, you might be out of luck, since they hold a lot of power when it comes to system access. That said, if your goal is just to shield it from non-admin users, you can consider signing your scripts and utilizing a Group Managed Service Account (gMSA) for running the task. This way, you avoid storing the password directly in the script. You can also use the -CmsMessage cmdlet to encrypt the password with a certificate so only your gMSA can decode it.

CuriousFrog83 -

Got it! So if I use 'AllSigned' as the Execution Policy, it'll only run if the signing certificate is trusted. That’s helpful to know!

Answered By FriendlyFox99 On

Have you considered using a system-managed identity for the task? You could then set up certificate-based authentication for SSH, which might be another way to securely handle this without needing to worry about the password in the script.

Answered By SecurityGuru88 On

Encrypting files as you suggested might raise alarms with your SIEM since it resembles malware behavior. The standard practice includes changing file permissions, running scripts via a managed service account, and auditing files for changes. It’s important to remember that security isn't about being completely impenetrable; it's about minimizing damage. Implementing effective change auditing can help keep track of any modifications.

ThoughtfulTurtle55 -

Absolutely, limiting access while also tracking changes makes a lot of sense. I'll look into file change auditing.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.