using ssh-agent from a perl script

Skeeve has asked for the wisdom of the Perl Monks concerning the following question:

I don't know where to start searching, so I thought maybe some of you could give me some good hints or share your thoughts about it.

I want to write some tools here which need to access databases and LDAP servers. For this they need some credentials. Usually here these credentials are shared ones but nevertheless I don't like them to be lying around in the filesystem unencrypted.

So my idea is to store them in an encrypted file which an ssh-agent should then be able to decrypt.

So every user who wants to use the tool needs to have a shared private key and he has to use a passphrase for it.

The tools then have, encrypted with the public key, the credentials they require.

When the user starts the script, it would try to contact the user's ssh-agent asking it to decypt the credentials.

Do you think this is a good idea?
Do you think it's feasible?
Do you know whether this was already done by someone?
Do you have an idea where to start searching?
Do you have a better idea?

s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e

Comment on using ssh-agent from a perl script Select or Download Code

Replies are listed 'Best First'.
Re: using ssh-agent from a perl script by Monk::Thomas (Friar) on Jul 24, 2013 at 09:10 UTC
Hmm. If you can not trust the local machine, then you are in trouble. It really does not matter how you secure the data - at some point you are holding an unsecured token which enables access to that secured data. What happens if someone gains access to your agent? So - for me the actual question is not on how to secure the token, but on how to prevent mis-use if the token gets stolen. Maybe it's advisable to implement an intermediate client/server and handle the information exchange via there - limit the visible/modifyable data to the absolute required minimum and don't expose anything else. That still doesn't solve much if the actual transferred data is 'dangerous' (e.g. password hashes), but it's a first step to prevent data leakage. Split up your tools into a client component and a server component? The (local) client just provides the interface to query/modify some data, the server checks the requests for validity / sanity and does the actual interaction with your database / LDAP. It also may apply restrictions on who is able to see what data. Users may even need to authenticate against the client with the server checking the credentials. Please do not distribute the usernames/password with each client. (And yes, someone has done this. Honeywell / Saia-Burgess got some embarassing press coverage for performing user/password authentication in a local Java-Applet for their heating plants.)	[reply]

Replies are listed 'Best First'.

Re: using ssh-agent from a perl script
by Monk::Thomas (Friar) on Jul 24, 2013 at 09:10 UTC

Hmm. If you can not trust the local machine, then you are in trouble. It really does not matter how you secure the data - at some point you are holding an unsecured token which enables access to that secured data. What happens if someone gains access to your agent?

So - for me the actual question is not on how to secure the token, but on how to prevent mis-use if the token gets stolen. Maybe it's advisable to implement an intermediate client/server and handle the information exchange via there - limit the visible/modifyable data to the absolute required minimum and don't expose anything else. That still doesn't solve much if the actual transferred data is 'dangerous' (e.g. password hashes), but it's a first step to prevent data leakage.

Split up your tools into a client component and a server component? The (local) client just provides the interface to query/modify some data, the server checks the requests for validity / sanity and does the actual interaction with your database / LDAP. It also may apply restrictions on who is able to see what data. Users may even need to authenticate against the client with the server checking the credentials. Please do not distribute the usernames/password with each client. (And yes, someone has done this. Honeywell / Saia-Burgess got some embarassing press coverage for performing user/password authentication in a local Java-Applet for their heating plants.)

[reply]