ssh to server is allowed one session but not a second

[Frank de Vries]

I am not so familiar with ssh.

However I connected with ssh to a server,
and this worked (have the session still open,
I am afraid to close it now).

I wanted to open another session to run something in background and the ssh command is given me agro about some key and to contact
our administrator

Guess what, I am the administrator (red face?)

Anyway this is the message, what do I need to do ?
[oracle@orasrv4:]/home/oracle/.ssh>> ssh oracle@audibxud0010
Couldn't connect to PRNGD socket "/var/run/egd-pool": No such file or directory
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
cc:ee:cc:c3:32:23:b4:75:4f:32:e7:ac:03:bc:b3:60.
Please contact your system administrator.
Add correct host key in /home/oracle/.ssh/known_hosts to get rid of this message.
Offending key in /home/oracle/.ssh/known_hosts:1
RSA host key for audibxud0010 has changed and you have requested strict checking.
Host key verification failed.
[oracle@orasrv4:]/home/oracle/.ssh>>

The key couldn't have possibly have changed,
or it is must be some automatic thing, but
then why does a putty ssh session from a pc work ? I can't make sense of it.

Can you make me see it.
Thanks

[Steven Schweda]

I know nothing, but the "REMOTE HOST
IDENTIFICATION HAS CHANGED!" complaint may
arise if you have some fancy/redundant
multiple-IP-address/interface configuration.
(What to do about it is another question for
which I have no answer.)

> [...] "/var/run/egd-pool": No such file or directory

Google suggests that your prngd process may
have died. (Here, I may know even less than
nothing.)

[palaniappan.sp]

Hi,
Did u exhchanged the keys between two m/c??
Can u able to find out the key is exchanged or not..
Becaz i also faced the same issue but i couldn't solve the issue.Finalli i reinstall the ssh server thru yum on CentOS.

Regds,
Palani.

[whiteknight]

Hi,

This error message is generated when ssh is attempting to generate a random number to be used for encryption. There are a few mechanisms it tries:

The "Strong Random Number Generator" (/dev/random)

The OpenSSL the Pseudo Random Number Generator Daemon (prngd)

The random number generator helper (ssh-rand-helper)

In attempting to contact prngd we attempt to open /var/run/egd-pool and log the error when this fails. We will continue on and use ssh-rand-helper so all will work as expect with the exceptions of the "spurious" error message.


would recommend you
1) Install the Strong Random Number generator (available on software.hp.com)

2) Install OpenSSL to get the prngd (the Pseudo Random Number Generator Daemon

WK

[Anshumali]

AFAIK PRNG requires a restart....& he is afraid to close the session...
But still...he can get on console ;)
2nd.. May be the keys were re-generated and weren't exchanged properly.... ssh -v IP may give some inputs to proceed....

[Frank de Vries]

Gosh,
Thanks for your bunny.

ssh works fine, so if it ain't broke
don't fix it. So I am not going too
install this or that.

Just because there is a side effect that when I open a second ssh session it
gives that scary message.

What does it mean anyway ???
And no I did not exchange keys, to me
it is all transparent. I think ssh genereted
the key in .ssh subdirectory.

Anyway bit busters, It is hard to evaluate the value of your answers. For me it is a lot of bunny, that buys me noffing realy.

So c'com guys,
anymore bunny before the hammer strikes,
auction closed.

[Ralph Grothe]

The message about the not found prngd Unix socket has already been answered.
You really should install the said HP-UX patch that will supply your system with the /dev/random device for amongst other usages to mainly feed ssh clients with enough entropy to accelerate the creation of session keys.
The point about multi-homed NICs Steven mentioned, although it doesn't seem to apply here, can be solved pretty easily by either using the -b option of the ssh client, or "-o BindAddress=123.123.123.123" with the scp command, if your e.g. SG package's VIP was 123.123.123.123.
The irritating warning that you receive only wants to inform you that the host key that the remote sshd transmitted didn't hit a match in your ssh client user's ~/.ssh/known_hosts file.
In most cases this means that the remote host's ssh host key changed, maybe because the remote host's sysadmin installed a new SSH sw package without caring to recover the hopefully a priori backed up host keys.
However, it can also mean the mentioned MITM attack.
You have to decide about the trustworthiness anyway, by
either ignoring that warning at all and supplying these options (bad idea)

$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -l remote_user [-i ~/.ssh/id_rsa_remote_host] remote_host [remote_cmd]

This will however circumvent host key checking altogether and issue a meaningless "host key added..." message, which you could suppress by additionally supplying the -q option.

Better option was to check and compare both key fingerprints.
Find another way to access the remote host, or ask the remote host's sysadmin to execute this on your behalf and read the fingerprint over the phone etc.

root@remhost># ssh-keygen -l -f /etc/opt/ssh/ssh_host_key

Compare the given output with the fingerprint of that host of the key that resides in your ~/.ssh/known_hosts

With recent versions of SSH this could work as well by the ssh-keygen command.

you@client>$ ssh-keygen -l -f ~/.ssh/known_hosts

This can get nasty if the keys are hashed, as in the more recent SSH releases for added security.
Then you could parse the host key entry for your host by

you@client>$ ssh-keygen -F remote_host -f ~/.ssh/known_hosts

Unfortunately, ssh-keygen isn't willing to read from stdin as it seems.
So redirect the output of above command to a temporary file, and apply a second ssh-keygen -l command on that file.

Once you have confirmed the validity of the "offending" host key
then you can either delete the obsolete entry in known_hosts of your client and reconnect.
Because the deafult -o StrictHostKeyChecking=ask should be prevalent ssh will ask you for confirmation of the newly displayed fingerprint, whereupon the key will be silently appended to your known_hosts file, and you will never be asked again for host key approval for this particular host until things again go awry.