Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^4: making NET:SSH quiet

by DeadPoet (Scribe)
on Jan 12, 2011 at 18:10 UTC ( #881954=note: print w/replies, xml ) Need Help??

in reply to Re^3: making NET:SSH quiet
in thread making NET:SSH quiet

with a batch style Secure Shell script.

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...

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.


Replies are listed 'Best First'.
Re^5: making NET:SSH quiet
by salva (Abbot) on Jan 13, 2011 at 09:09 UTC
    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://881954]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (11)
As of 2018-03-21 15:12 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (268 votes). Check out past polls.