views:

82

answers:

2

I have a server with which I cannot use pre-shared keys and ssh - all authentication is via interactive prompts.

That server also has cron and at disabled for non-root users.

I would like to be able to cron a job on my local machine that will run a script against the remote server to do periodic maintenance/reporting.

I've dallied with expect some, but have noticed that in order for it to automate putting the password to the prompt at the right time, it needs to be stored in cleartext.

Is there a way to secure the password in such a way that I enter it once, then it's scrambled/whatever locally (like passwd does), and then I'm not storing the plaintext password in the script itself?

+1  A: 

Storing passwords is always insecure (if you need access to the cleartext password). Your script will have to have the "un-encoding" logic. Anyone who has read-access to your script will then be able to figure out where the encoded password is stored and how to unencode it.

It's a judgement call for you. Which do you value more: automation (to save your time) or password security?

glenn jackman
+1  A: 

It's very insecure to stick with password-based authentication due to botnet-based attacks being able to blunt the utility of denyhosts. But if you must, you must...

What I'll do when stuck in that situation is put the password in a file separate from the script, make that password file only readable by me, and make the directory it is in only readable (and executable) by me as well. I'll also take great care to ensure that the password is never passed as an argument or in an environment variable; both of those are trivially snoopable with ps. Passing the name of the password file is OK (can secure the path) and passing the password through an unnamed pipe is also safe.

Donal Fellows
I'm not concerned about botnets with this server: it's on a segmented network with no outside connectivity
warren