You can try setting the option StrictHostkeyChecking to "NO". I think that
should do what you need. However, that does open the possibility of a
security hole by spoofing host keys, particularly for a man-in-the-middle
type of attack.

At 07:03 AM 1/16/2007, Vorländer, Martin wrote:
>Environment is:
>TCPware V5.6-2 with SSH_V562P100 (and various other ECOs)
>OpenVMS V7.3-2 (patched, too)
>I'm trying to execute a command remotely via SSH on multiple
>hosts. I've distributed the TCPware's public key to all systems.
>Trying it, I get
>$ SSH /OPTION=(BATCHMODE=Y) /VERBOSE "user@host" "command"
>debug: (13:36:18)Ssh2/SSH2.C;2:1941: User config file not found, using
> (Looked for 'SYS$SYSROOT:[SYSMGR.SSH2]ssh2_config.')
>debug: Connecting to x.x.x.x, port 22... (SOCKS not used)
>debug: (13:36:18)Ssh2Transport/TRCOMMON.C;4:3880: My version:
> SSH-1.99-3.2.9 F-SECURE SSH 5.0.1 - Process Software TCPware
>debug: client supports 5 auth methods:
>debug: (13:36:18)Ssh2Common/SSHCOMMON.C;1:585: local ip = x.x.x.x, local
>port = 1217
>debug: (13:36:18)Ssh2Common/SSHCOMMON.C;1:587: remote ip = x.x.x.x,remote
>port = 22
>debug: (13:36:18)SshConnection/SSHCONN.C;1:1951: Wrapping...
>debug: Remote version: SSH-2.0-OpenSSH_3.4p1
>debug: OpenSSH: Major: 3 Minor: 4 Revision: 0
>debug: (13:36:18)Ssh2Transport/TRCOMMON.C;4:1008:
> All versions of OpenSSH handle kex guesses incorrectly.
>debug: (13:36:18)Ssh2Transport/TRCOMMON.C;4:1022:
> Remote version doesn't support SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
>debug: (13:36:18)Ssh2Transport/TRCOMMON.C;4:1109:
>debug: (13:36:18)Ssh2Transport/TRCOMMON.C;4:1464: lang s to c: `', lang c
>to s: `'
>debug: (13:36:18)Ssh2Transport/TRCOMMON.C;4:1529: c_to_s:
> cipher aes128-cbc, mac hmac-sha1, compression none
>debug: (13:36:18)Ssh2Transport/TRCOMMON.C;4:1532: s_to_c:
> cipher aes128-cbc, mac hmac-sha1, compression none
>debug: (13:36:18)SshKeyFile/SSHKEYFILE.C;2:390:
> file does not exist.
>warning: You have no controlling tty. Cannot read confirmation.
>debug: (13:36:18)Ssh2Common/SSHCOMMON.C;1:169: DISCONNECT received: Key
>exchange failed.
>warning: Authentication failed.
>Disconnected; key exchange or algorithm negotiation failed (Key exchange
>debug: (13:36:18)Ssh2Common/SSHCOMMON.C;1:711: Destroying SshCommon object.
>debug: (13:36:18)SshConnection/SSHCONN.C;1:2003: Destroying SshConn object.
>BUT: once I execute the command without the batchmode option,
>and answer "yes" to the question "Host key not found from database. /
>Are you sure you want to continue connecting?" (i.e. the remote host key
>gets stored in SYS$LOGIN:[SSH2.HOSTKEYS]), it works - and after that, the
>above also starts to work.
>Is it really necessary to gather all the remote host keys on the SSH client
>machine before batchmode scripts start to work?
>That would be very inconveniant, as new remote systems come along,
>host keys get changed, etc.
>Is there a workaround?
>Thanks in advance for any comments.
> Martin
> O Lord, won't you buy me | Martin Vorlaender | OpenVMS rules!
> an HP OS | work:
> its name starts with "Open" |
> and ends in "VMS" ... | home:

| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| | |