You defeat the purpose of automation. A simple upgrade to SSH on UNIX and all your automation is no longer automated until known_host entries are cleared.

Use the option, don't use the option, it is the implementer's choice and an understanding of their environment. To your point, which I agree with if you are implying "sparingly", this option should not be used to just be used, it should have a purpose--such as the case for automation. If you do not care about failed connections or are going to write some type of exception process, then yes you do not need it. But to just silently fail, such as with the '-q', why did it fail? Was it a true connection issue? Was it a bad command? Was it just the known_host file? Who knows!

Moreover, before attempting a connection I would check for host availability, which I talked about. So, what would I know using this process?

* Server is available.

* SecureShell is available.

* If the command fails then it is probably on the target side.

Okay, now one is probably going to say well what about firewalls and port blockage? Well, as part of the preliminary checks, which includes ping, I would also check if the port is available one manner, and not the only way, is to use IO::Socket::INET. For example:

# code snip...
  my $remote = new IO::Socket::INET
                             PeerAddr => $o->{'host'},
                             PeerPort => $o->{'port'},
                             Proto    => q{tcp},
                             Timeout  => 8;

  if ( ! $remote ) { return RET_FAILURE; }

# code snip...
[download]

It all just depends on what one needs and wants to accomplish. If one is going to account for issues with some type of exception process, then you got it. If the script is going to be left unattended, then you probably need it.

You defeat the purpose of automation

So, you are advocating for ignoring any security issue just to make your work easier, right?

That may be acceptable if you use ssh just to check that your machines are up and run some dummy commands, or if you are in a very controlled environment. But in general, telling ssh to ignore the known_hosts file is a very bad idea. Automation is not an excuse.

A simple upgrade to SSH on UNIX and all your automation is no longer automated until known_host entries are cleared

No SSH software that I know changes the server keys on upgrades. That only should happen the first time you install it.

Anyway, handling host keys properly may be a lot of work, right, that's life, security is not something you get for free and those uppercased warnings you get from SSH does really mean something:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 att
+ack)!
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
15:a9:45:01:49:6c:64:10:3a:78:02:3d:52:39:2d:bf.
[download]