How to send stdin to ssh command

[David_246]

Hi,

I have an issue that some programs using ssh will produce lots of errors after a system reboot.
This because ssh is expecting an answer, it looks like :
The authenticity of host '2n3 (10.164.101.17)' can't be established.
DSA key fingerprint is 11:59:04:46:21:2d:e0:77:db:55:c2:4e:71:82:19:86.
Are you sure you want to continue connecting (yes/no)?

This is only one time. Therefor I would like to automate this as the program (run by cron every 5 minutes) cannot give feedback and just times out.

Any ideas on how to always send a "yes" along ?

echo yes | ssh

Does not work. It gives the following error :

Pseudo-terminal will not be allocated because stdin is not a terminal.
Any help will be apreciated.

Regs David

[Tom Geudens]

Hi,
What about using "expect" ?
http://hpux.tn.tudelft.nl/hppd/hpux/Tcl/expect-5.38/

Regards,
Tom

[David_246]

Hi Tom,

Indeed this could be an answer, although I was hoping for an easier method.

Regs David

[Massimo Bianchi]

Depending on the version of ssh,
try:

echo y | ssh -t server

-t Force pseudo-tty allocation. This can be used to execute
arbitary screen-based programs on a remote machine, which can be
very useful, e.g., when implementing menu services. Multiple -t
options force tty allocation, even if ssh has no local tty.


echo y | ssh -f server

-f Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, but the user wants it in the background. This
implies -n. The recommended way to start X11 programs at a remote
site is with something like ssh -f host xterm .

ssh -f -n server

-n Redirects stdin from /dev/null (actually, prevents reading from
stdin). This must be used when ssh is run in the background.

ssh -q server

-q Quiet mode. Causes all warning and diagnostic messages to be
suppressed. Only fatal errors are displayed.

Massimo

[David_246]

Hi Masimo,

I already tried all options, also the -t (found it out after the post), but all options result in exactly the same question.

Is there a way to avoid even the fingerprint question ??

Or is there a way to let ssh accept stdin ?


Regs David

[Volker Borowski]

Hmm,

shouldn't the key be stored once it is accepetd ? Do you generate new keys after a reboot ?
Check the write permission to your key-location.
Looks like the key is not stored, so this is why it askes all the time.

The second point is: I think you can not redirect this, because when piped the stream is directed to the shell itself, not the ssh-client or server-process. So in case you do

tar cvf - some_files | ssh target tar xf -

Your streaming data on the pipe will be the tar-data, which will (and must) be completely unused for any prompts ssh is issuing for either fingerprints or logon information.

Hope this helps
Volker

[Ronelle van Niekerk]

How about trying the yes command?

/usr/bin/yes | ssh

[Chris Vail]

This question can be avoided completely by establishing the key pair. Read through the attached document on how to do this.


Chris

[Chris Vail]

This question can be avoided completely by establishing the key pair. Read through the attached document on how to do this. With the key pairs set up, secure shell won't challenge as you mention.


Chris

[Ralph Grothe]

As you wrote,
this request for confirmation of the host key only appears for the very first time when a connection is made to a host whose public host key hasn't been registered yet in the client's $HOME/.ssh/know_hosts file.
It is issued deliberately to prevent from man-in-the-middle-attacks with spoofed host keys I guess.
You only have to distribute the public host key of any ssh servers you want to connect to (these can mostly be found, depending on your instellation, in files like /opt/ssh/etc/*.pub on the hosts where sshd procs listen) to the clients' known_hosts files in their $HOME/.ssh directories.
This will be done automatically when you manually confirm the question for continuing with the connection (as said only the first time).
You will only be asked again whenever the server's host key changed (i.e. doesn't match with the entry in the client's know_hosts file anymore).
Thus there must be changes of the host keys taking place between your reboots.
Maybe you should ask your fellow sysadmins if they created new host keys on their ssh servers?