I am trying to find a way to run commands remotely on the filer using ssh from a nfs administrative host. Since Oracle data is on the filer , My basic intention is to bring oracle in warm backup mode , create a snapshot and bring it back to normal mode .I want to automate this process and run it as cron job. The problem is I don't want to use rsh and netapp tells me there is no way to run ssh on the filer without specifying password.

I haven't had the opportunity yet to play around with SecureAdmin on the filer, but I would think of a couple of possible workarounds: a) use expect to script the password entry. Problems: - the password has to be stored in plaintext on the client b) use a key with an empty passphrase. Problems: - there's no access control on who can use a key, so if some obtains a copy of the user key they can use it from anywhere.

Maybe one of those will help, although IMHO they're not optimal.

As a data point, I was unhappy with those solutions in a similar situation where I wanted to effectively replace rsh with ssh and allow connections from root on a known IP address/host key combination. ssh 1.2 (the original UNIX version) didn't support this for root; allowing the use of `.rhosts' worked for all users except root.

So, I modified the ssh 1.2 source to support 'IgnoreRootRhosts', which defaults to `yes', and it worked a la `IgnoreRhosts' except for root only. That way, we could do: IgnoreRhosts yes IgnoreRootRhosts no and have /etc/shosts.equiv and ~root/.rhosts be honoured, but ordinary (pesky :) user .shosts not work. This is similar to the `-l' option of the rshd in 4.4BSD (and therefore NetBSD/FreeBSD/OpenBSD).

This gives the benefit of controlling the access to the target machine from the target machine (.shosts), and I'm fairly certain that there has to be a known_hosts entry on the target for the source as well. At least you get encrypted sessions, and to abuse the facility a pesky hacker has to do it from the source machine you've granted access too, rather than stealing information on a given source machine and abusing it from any other machine.

You could log a feature change request through your sales rep for similar functionality, and hopefully NetApp can devote some engineering time to it.

Luke.