SSH promts for passphrase

[George Chechakunnil]

hello Admins

I am trying to do ssh from one server to other but it promps for the passphrase everytime.

After i enter passphase it connects fine

Any ideas?

[George Chechakunnil]

This is the message i get

Enter passphrase for key '/.ssh/id_dsa':

what needs to be done to make it permanent

[AwadheshPandey]

see this
http://newfdawg.com/SHP-SSHpart2.htm

[Jean-Yves Picard]

hello,

try
ssh-add
or
ssh-add .ssh/id_rsa
(assuming you are in your home dir).

please note that you'll have to manualy add passphrase after every reboot.

Jean-Yves Picard

[Ralph Grothe]

What Jean-Yves suggested assumes that you already have started an ssh-agent.
This is really the preferred way
because you still leave your RSA keys passphrase protected, and yet only have to enter the phrase once until you end the shell where the agent is taking control of phrase exchange.
In case you haven't running an agent
(can be easily checked by looking for SSH* environment), for a Bourne compatible shell run

$ eval $(ssh-agent -s)

It should respond with showing its PID
e.g.

Agent pid 27938

but also it should have exported these variables to your shell's environment

$ env|grep SSH
SSH_AUTH_SOCK=/tmp/ssh-ivkBa27897/agent.27897
SSH_AGENT_PID=27938

Then you can check which RSA keys it has loaded

$ ssh-add -l
The agent has no identities.

Then ad lib ssh-add as many keys as you please

$ ssh-add .ssh/id_rsa
Identity added: .ssh/id_rsa (.ssh/id_rsa)

If your key is passphrase protected
this would be the time the agent asks once
and never again for the phrase.
As you can see, I have implemnted poor security with my key since I wasn't asked.

If you now repeat the ssh-add -l
the agent should show the fingerprint of the added key.

From now on, any ssh to any host where this key has been distributed should work without
being asked for pass phrases any more.

You can safely finish the agent by
ssh-agent -k
which ideally should be put in a trap on EXIT.

However, if you don't care so much about security (for instance scripts would require full batchmode, but those should be "protected" by command keys) you can at any time revoke the passphrase of a key by

$ ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

Simply specify -N "" at above command.

But please, be aware of the consequences in doing so, and first think of all the hosts you have this key distributed to!
Is their environment really safe enough for passphrase-less keys?

[Aashique]

Hi,
Copy your pass pharase to your remote machine.
so at first generate
"ssh-keygen -t rsa" at both machine.
then in your local machine do the following:

cat /home/aashique/.ssh/id_rsa.pub|ssh username@remote-ip 'cat >> /home/username/.ssh/authorized_keys2'


Thanks & Regards

A. Aashique

[Juan M Leon]

George
I will assume that you have one server that is ssh trusted to the other server.
I will simple ssh-keygen and recreate the file and when prompted fr passphrase only press enter.
then you can push the new ssh key to your other servers.

that is my opinion.

hope it helps.

Thank you

[Doug O'Leary]

Hey;

To side step for half a sec: There are three factors for authentication:

1. Something you know
2. Something you have
3. Something you are

The more factors you use, the more secure your environment. Passwords are single factor authentication because you know the password. Secure ID tokens are 2-factor authentication - you have the token and know the pin to it. Biometrics is the third factor.

Secure shell using public key authentication is considered two-factor because you have the private key and know the passphrase to it.

The proper way to connfigure ssh/pka is the way Ralph Grothe mentions - using a ssh agent to effectively cache the private key.

DO NOT use null-passphrased keys as Juan Leon suggests for normal interactive keys. You are effectively removing one of the factors of the authentication - you might as well be using passwords. In some cases, it's even worse than straight passwords. If someone gains access to your private key, they have access to everything you've configured that key to use.

That's not to say that null passphrased keys don't have a use. They should be used under the following conditions:

1. Should only be used for non-interactive scripts
2. Should be locked down to the commands it needs only.
3 Should never be used as the default key.

Using null-passphrased keys as your default key or for interactive sessions is an incredibly BAD idea.

HTH;

Doug

[Juan M Leon]

Doug,

I agree with you comment to not to use empty passphrase.
However I think if you have a secure server the purpose of ssh serves to encrypt your connection therefore the tcp packet is not readable as it is on ftp or telnet. (maybe i am wrong)

My reason for not to use passphrase are:
- There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, you will have to generate a new key and copy the corresponding public key to other machines.
- On automated process for ssh or scp you will need to create a wrapper to enter the passphrase.

Althoug I have to admit that Ralph Grothe suggestion seems very interesting. I definately will explore on this. I am learning somethign new today.