Problems checking external host

[Jim McNamara]

On Sat, 2009-12-12 at 10:10 -0500, ReynierPM wrote:

> James Pratt wrote:
> > 
> > http://www.zdnetasia.com/techguide/opensource/0,39044899,62052006,00.htm
> > some
> > create
> > 
> > No problem - As root, just run:
> > 
> > su - nagios -c "ssh nagios at remotebox.com" (replace your target hostname
> > here, or use IP)
> > 
> > let it connect and accept the key, then do the same on the target box in
> > reverse, so that both sides have the key in ~/.ssh/authorized_keys
> > files.
> > 
> 
> Hi:
> It's me again trying to configure check_by_ssh but without success. See, 
>   I follow this tutorial[1] but when I've done can't login to remote 
> server from Nagios server. Let me explain a bit what I do:
> 
> 1) Login into my Nagios server as "root" not as "nagios" user
> 2) Run this commands:
>   ssh-keygen -t rsa1 (for SSH1, I think I don't need this but just run 
> for precaution)
>   ssh-keygen -t dsa
>   ssh-keygen -t rsa
> 3) Copy the generated files to the remote server
>   scp ~/.ssh/*.pub nagios at 10.128.50.11:/home/nagios/
> 4) Run this others commands:
> cat identity.pub >>~/.ssh/authorized_keys
> cat id_dsa.pub >>~/.ssh/authorized_keys
> cat id_rsa.pub >>~/.ssh/authorized_keys
> rm identity.pub id_dsa.pub id_rsa.pub
> 
> Now when I try to login from Nagios server to the remote server 
> (10.128.50.11) I always need to enter the password. I try as "root" and 
> also as "nagios" (meaning ssh root at 10.128.50.11, ssh 
> nagios at 10.128.50.11). Why?
> 
> The curiosity came to me and I check the file authorized_keys at remote 
> host and have this:
> 
> 2048 35 
> 31537320408745229838365562405624946802370792096499059223774165383570113281161048240756249546198805679184056103143919830145818642104082292170996730416929422264174662938941716685989426016074582046007764918772604041829437044357969148541210017569485061724990330392006573284601283454700329897647888326315719461278230886781115132496222294195579706117375955677922834002228681170251111807857141282704805088831501704787050993949809146632808041890108774648791697895838722205506992426654008098461046497741222563633988038536169891094257004960432390755965669333326650500537312297715834727417885056386391177047203249702515327707761 
> root at monitoring
> ssh-dss 
> AAAAB3NzaC1kc3MAAACBAPCKZyo6kPGMyGuWMhF6I/HcbY/2h0C2mIp0eMsnwi5nh1nT93VcJZL+hZd6etsDMzXSfN9EbQKlvXUKr3O05Ce8WBbesP7sYngR8ZfApZzUG+cnbia4XU9bf4KeA70UYSN9MWQWh0yvTfLJOX3X0ER0yQrNwVbiD3cwpyWMjGR7AAAAFQCQlSos9XFsf7o/sqYXE+E2NStJowAAAIEA8BmrviwMVaRT8Dg0L6h3ugViKlM+h2Ka4g1oO0mP+6wlZ1tf8+1p7bS2AZTLHsVdT8JdDt4kXr0h9A2+OHCyIZtIkwnJfgppjZri2wNsL6xBe/8YoNRAjuT28gsyYhm3Y1z7x4MTaii9KADotO/Pzc4QSj8RfNRdXKgMWBysEkMAAACATN+wyWnkYoHnskIkVofKuUckLE2VloyIrRl+ZJtV0mkC2PJ8/7nuT/qbqQGucI/60xqApjUH5BvXkUt7rm+aiGSL3s4ehRGfgsqp6BnzuzSJMCCWJQCPzXt0qTh/2l4wcxLqxtItKBxFHpPCh4ltV1jsxseCAoJiIH6GRHt5k1M= 
> root at monitoring
> ssh-rsa 
> AAAAB3NzaC1yc2EAAAABIwAAAQEAvIvPpR2k3br05Yel6LHdziEp6uLx53gsTiSPko9tCuj26dxwJUg1Pt1LrNKObApdA0QWoLVXUmZx/MFicCvqND9Mj93nCSwZ9fN8MRlea5DNDpJORE2NPjmV5IlxX9S3qLDhkp1bXrqLS556sipxXigDZlvCJ/nHa4ZCdFRek2pT7vNVNA8E/wxu38zCnCDLFmmq73r+Sf+8Ud/whBBWWAIrQgGcP1oQ1MTo+rMYJSudof4CWAS9IWV3TI1yLg9EJK0CpzHVIYReo0QZzgin8op70/mx09OQsDCxZD/Ht9D3NTFxiTByRgtU//SzCJyLZigyeJODdEDr3PiK7+f4Nw== 
> root at monitoring
> 
> As you can see all have "root at monitoring" at the end. What is the 
> problem? Does this have anything to do?
> 
> [1] 
> http://hocuspokus.net/2008/01/ssh-shared-key-setup-ssh-logins-without-passwords/comment-page-1


Nagios runs as user nagios (usually), not as root, so that is the
beginning of the problem. It is also possible that the remote host
doesn't accept key based authentication, but the normal ssh daemon will
accept keys ahead of passwords. 

On the nagios box, give yourself a shell as user nagios. depending on
your permissions, you may need to specify /bin/bash or /bin/sh for your
shell. Then you can generate the key with the ssh-keygen command. That
needs to be done as user nagios. You also don't need to create 3 keys.
That isn't the source of the problem, the limit on the number of keys is
likely in the thousands, but the "default" key on most linuxes is
~/.ssh/id_rsa. So generate that without a password at a size that works
for you. Use man ssh-keygen if anything I'm saying about this is
unclear. 

Do copy the id_rsa.pub (or id_dsa.pub, or whatever the public part is)
to the remote box, and dump it into the nagios ~/.ssh/authorized_keys
file as you did before. You can erase the previous entries you made,
unless you want root on the the nagios box to be able to ssh into the
remote box as user nagios. 

Back on the nagios monitoring box, again become user nagios with a
shell, and do:

ssh -i ~/.ssh/id_rsa nagios at 10.128.50.11

It will ask you to accept the identity of the remote host, once you've
done that, you should have shell access as user nagios on the remote
box. After you've accepted the key, the nagios daemon can now make that
connection whenever it needs to. Here is the generic check_by_ssh config
that I use, notice that the key is specifically being called to
designate the identity file. 

# 'check_ssh_disk' command definition
define command{
        command_name    check_ssh_disk
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ \
        -i /usr/local/nagios/.ssh/id_rsa \
        -C "$USER1$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$"
        }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20091212/ceaaef0d/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null