Hey all,

I have a server A that needs to connect to another server (B) to transfer data everyday.
[A] ==SFTP==> [B]

I am using SFTP for the data transfert between A and B.

I configured B to allow authentication only with a key, not with password.
However, anybody who acccess the filesystem of A, could steal the password.

So I thought I could password protect the private key from A.

But in such a case, I need to store the password somewhere on A, so the server A can access the private key to connect to B.

Finally, it is endless: i always have to store somewhere a secret on A.

Is there another solution that allow to have an authentication between A and B without storing plain text secret on the server A ?

Thanks

Passwordless authentication for ssh and such does not store a plain text password....

You should have a public key and a private key on the server and the public key on the remote.

That's true, but you'd still need to deal with authentication on the remote (server A) side somehow. It seems to me like PlatinumX wants to have a way to authenticate server A to server B without credentials having to reside on server A. I don't see how that could be possible. You could, however, reduce the risk by increasing your abilities to quickly detect that the credentials have been compromised (with an intrusion detection system, for example). Of course, this also implies having everything ready to revoke the credentials and respond to the security breach.

1 members found this post helpful.

Exactly.
If I choose password authentication for SSH, the password will reside in plain text on the server A.

If I choose key authentication for SSH, the private key will reside unprotected(not password protected)on the server A.

According to Win32sux, the best I can do is limiting read access on the private key, and auditing access to the privat key to detect abnormal access.

Something more ?
Thanks

Password protect your private key and use ssh-agent to fill in store the password.

You can also apply restrictions in the (public) key itself on what is allowed.

You're not going to be able to do this cleanly if Server A can not be trusted (and it sounds like that is what you are saying). What are the exact circumstances in this situation? Maybe there's a better approach to it.

I'd use a combination of:

1. auth keys
2. on A, create a separate user and set home dir to 700 (rwx------) to do the job
3. on B, use the options in sshd_config of : ForceCommand, Match, Allowusers, Address http://www.openbsd.org/cgi-bin/man.c...nfig&sektion=5 to lock everything down.

Just in case anyone doesn't realise, if you don't want to lock down the entire sshd you can specify constraints actually in the public key itself.

http://www.openbsd.org/cgi-bin/man.c...penBSD+Current

and Step 6 in:

http://e-articles.info/e/a/title/Usi...ile-Transfers/

1 members found this post helpful.

As an aside, very handy options. (Too bad I am not running any systems with such a recent OpenSSH. I may need to finally build openssh-portable on my FBSD 6 host.)

That's interesting, yes. I don't know when the extra facilities were added, I just assumed that it was all part of the SSH-2 standard. The oldest system I'm running at the moment is RH7.3 with OpenSSH3.5p1 and it seems to recognise the constraints.

Server A has not only one administrator but several to perform various tasks.
I do trust my security administrator, but not the system admin or the network admin.
But as they have root access on the server, they can access the private key or the password.

Here is my main concern.

They may be able to access the private key, but they will still be restricted by the constraints that you put on that key on the remote servers, so this may not be a problem.