sshd: Connection closed [preauth]

Sunday, August 18. 2013

 Log-Spam, seitenweise die gleiche Meldung. 

sshd[(process)]: Connection closed by (IP) [preauth]

Rumgesucht, in wireshark sah ich immer den Dialog zwischen SSH-Server und Client, Schlüsselaustausch und dann wieder Abbruch.
Google fand nichts Beunruhigendes, jemand sah das gleiche Bild und der Anlass war bei ihm monit

Ok, und hier war es icinga mit seinem Test auf ssh...

icinga / nagios via IPv6

Wednesday, February 15. 2012

 Wie schon erwähnt kann der zu nagios gehörende nrpe kein IPv6 und der icinga-nrpe wollte bei mir einfach nicht laufen. Die zu überwachenden Rechner liegen aus Sicht von IPv4 recht disparat, manche im lokalen Lan, manche in einem entfernten Lan, dass per DSL angebunden ist, teils mit statischen IP bei einem Hoster. Alle haben aber IPv6 und so habe ich den Weg über check_by_ssh gewählt.

- ringsum apt-get install nagios-plugins-standard
- ringsum einen fuer die nagios-Abfragen dedizierten und ansonsten rechtlosen user (icingaremote:icingaremote) anlegen
- auf dem icinga-server fuer den user, unter dem der  server laeuft, ein private/public Schlüsselpaar erzeugen
   ssh-keygen -t rsa
- ringsum mkdir  /home/nagiosremote/.ssh und dort in authorized_keys den public key des erzeugten Schluesselpaars vom icinga-server ablegen
- zur Kontrolle vom icinga-server aus ssh auf die entfernten Rechner  ssh icingaremote@domain.tld

Wenn das soweit geht, auf dem icinga-server in /etc/icinga/objects eine clientx.cfg je remote client anlegen, in hostgroups.cfg Gruppen fuer Rechner mit identischen abfragen anlegen, in services_icinga.cfg service definieren,

 

define service {
        hostgroup_name                  remote-clients
        service_description             users logged in
        check_command                   remote-loggedin
        use                             generic-service
        notification_interval           0 ; set > 0 if you want to be renotified
}

in commands.cfg die konkreten commands definieren:
define command{
        command_name    remote-loggedin
        command_line    /usr/lib/nagios/plugins/check_by_ssh -H $HOSTADDRESS$  -6 -l icingaremote -i /var/lib/icinga/.ssh/id_rsa -C '/usr/lib/nagios/plugins/check_users -w 20 -c 50'
        }
 

Einzig der Test auf mysql auf dem localhost wollte partout IPv4...
 

 

IPv6 - manches geht, manches nicht

Wednesday, February 8. 2012

Bei webmin war ich der festen Ansicht, dass IPv6 nicht geht und nie gehen wird. Ich hatte mal so eine Bemerkung auf der Projektseite gelesen, und da es in perl ist (perl considered harmful)... Stimmt aber gar nicht (mehr): 

aktuelle Versionen von webmin lassen sich mit einem mausklick Ipv6-enablen, alles, was sie dazu brauchen, ist, ein package:

 apt-get install  libio-socket-inet6-perl

Anschliessend nach Webmin/Webmin Configuration/Ports and Adresses/  und dort Accept IPv6 connections? mit Yes, fertig!
 
Der richtig dicke Vorteil von IPv6 ist ja, dass nun endlich die IPs nicht mehr knapp sind und man ganz ohne portumleitung und derlei Grauslichkeiten Clients und Server wieder end to end zusammenbekommt, auch wenn zwischen ihnen ein oder mehrere dsl mit dynamischen IP(v4) sind. Beispiel VPN oder Monitoring.
Erm, ja, ausser man hat auf openVpn gesetzt. Oder man versucht, zu nagios/icinga auf zu überwachenden Maschinen einen nrpe-server zu installieren. Der nrpe-Server horcht aber nur auf IPv4 und aus ist. Jetzt prokel ich in einem inoffiziellen Fork
E
in freundlicher Blogger verweist mich auf den icinga - nrpe, den hatte ich zuvor wohl übersehen. Einen Erfolg kann ich aber auch damit bislang nicht vermelden, mehrere Anläufe, buchstabengetreu oder mitdenkend den Angaben des Link zu folgen kompilierten fehlerfrei, blieben dann aber doch im ersten Test stecken:
/usr/local/icinga/libexec/check_nrpe -H 127.0.0.1 -n
CHECK_NRPE: Error receiving data from daemon.
hmm. Sachdienliche Hinweise richten sie bitte an die Kommentarfunktion weiter unten...
 
Mysql ist auch nicht ganz auf IPv6 eingerichtet, jedenfalls 5.1.49 aus debian/squeeze. 
netstat -tulpn|grep mysql
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      19179/mysqld
und auf ::1 lauscht er eben nicht. Eine erhellende Diskussion zum Thema fand ich, und darin einen Link zu mysql 5.5 für squeeze, erprobt habe ich dies aber nicht.
 
 iftop gibt eine gute Übersicht über den Verkehr im Netzwerk, aber in debian squeeze nur für IPv4. Squeeze kommt mit iftop 0.17-16, IPv6 support gibt es erst ab 0.17-17 - leider ist auch in squeeze-backports nichts dabei.

 

(Page 1 of 1, totaling 3 entries)