Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have my ~/.ssh/config full of entries like this:

host foo
   user bar
   identityfile ~/.ssh/private.pem

that allows me to do this:

ssh foo

to login. SSH then checks to see if I'm allowed to access foo using my key in ~/.ssh/private.pem and lets me in very easily.

However, on some systems I have two-factor authentication i.e. a password too. Can I specify a password in my config file? Is it actually possible or can you not do it?

Thanks very much :).

share|improve this question
up vote 1 down vote accepted

My short answer: not that I've been able to determine w/ OpenSSH.

My long answer:

This is such a great question and rarely thought about in my opinion not to mention a difficult and sometimes touchy subject. Both answers so far are good. Certainly you can "hard code" your password in an Expect script. Additionally, the answer regarding unlocking your private key is valid as well. Nikolaidis gets it closest in my opinion as far as answering the question.

The bottom line is that there is no method to specify or submit on the command line your password in a non-interactive manner during ssh authentication using a built-in mechanism (that I have found).

This may be an RFC thing or it may be an implementation thing - I'm not sure. My guess being it's an implementation restriction since I doubt any RFC would specify "how" a password must be handled in the process - but hey I could be wrong. A private key is on some level just a very, very long password and those are often stored unencrypted and there is no implementation restrictions pertaining to that.

But beware.

Now I realize that there is more to asymmetric cryptography (public/private keys) than just logging in to a remote system and that there is more to what it means to authenticate oneself than this discussion. What I'm referring to is the difference in user perception and use between the two methods of authenticating oneself (more to Daffy's answer).

So here's the deal (my take):

If you are performing 2-factor auth then there's generally a reason behind it: someone really wants to make sure that A: a human being is performing the authentication and B: that the human being really is the human being he/she says they are. There's probably a good reason for it.

This may be due to compliance due to existing law (Sarbanes-Oxley) in which case if someone determines you're bypassing authentication in a way that creates undue exposure or against company policy - like during an audit - you could find yourself in a touchy situation and/or with a pink slip.

My point being make sure you understand what you're doing and document what you're doing as well as document the appropriate sign-off by your higher-ups. But at that point why bypass things and rather just figure out if it's the appropriate auth for the situation.

There are plenty of instances where it's understood and expected that a remote system needs to talk to another remote system on behalf of a "user" - like transferring files, monitoring systems, performing backups, etc. In those situations it's fine to setup 1-factor auth using public/private keys and just as importantly, some of those non-interactive auth mechanisms touch sensitive files (backups).

The key (no pun intended) is to make sure the right authentication mechanism is in place for the right situation. People need to get work done and that needs to be balanced with robust security. Which is why there are authentication mechanisms being invented / have been invented since the days of passwords - Kerberos, Smart Cards, eyeball scanners, what-have-you. There are upsides to each as well as downsides. None are perfect (perfect being a subjective concept).

Hope that helps.

share|improve this answer

hhhm, I am not sure about config, but you can always use a wrapper using expect. Something like expect -c 'spawn ssh ; expect password ; send "passphrase\n" ; interact'

This way, you authenticate both by certificate and password !

share|improve this answer
Oddly, a 3rd party administrator of a client's host disabled public key authentication. Password is long and gobbly-gooky. Super annoying! Love your solution. Simple. Just be sure to chmod 700 it! I tried using the more secure certificate based authentication. Admins can be dumb sometimes. – Bretticus Nov 4 '14 at 21:51

You cannot add it to the config file (also a bad idea to enter passwords in clear text even if you could). as hinted at you could use 'expect', however I am not sure you have the problem you think you have. The last individual I ran across trying to solve this problem did not realize how this authentication worked.

You may be 100% correct (Private Key + Password for server), but you might be putting the password in simply to unlock your private key on your local machine. When you generate the key it prompts you for a password. most people think this is to authenticate to the remote server, it is not. It is asking you for a password you pick to lockup the key you are about to create. Try recreating the key leaving the password blank. This should eliminate the password you are being prompted for.


share|improve this answer
Actually, he mentioned two-factor authentication (which means that he must authenticate with two discrete methods) ... so probably it's not the password to unlock the private key, but rather to authenticate to the server – Nikolaidis Fotis Mar 5 '12 at 14:36
Just a suggestion. it was a ridiculously over paid security consultant that had it wrong last time. – DaffyDuc Mar 7 '12 at 7:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.