Munin + SFTP

Mutschas

New Member
Hallo zusammen,

ich bin nach dieser Anleitung gegangen, um mir SFTP so einzurichten, dass ich bei der Verbindung auf einen bestimmten Server nicht immer das PW eingeben muss.

Das klappt soweit super solange ich es via root-User ausführe.

Führe ich SFTP via einem Munin-Plugin aus, erhalte ich folgende Ausgabe beim testen des Plugins:

Code:
Could not create directory '/nonexistent/.ssh'.
The authenticity of host 'muh.de (5.5.5.5)' can't be established.
RSA key fingerprint is 34:xxxxxxxxxxxxxxxxxxxxx:9f:e3.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/nonexistent/.ssh/known_hosts).
user@muh.de's password:

Ich muss also beim munin-Plugin nachwievor ein Passwort eingeben.

Hat jemand eine Lösung? Vor allem wundern mich die zwei Fehlermeldungen.

Danke.
 
Falls der User nonexistent tatsächlich korrekt ist:
erzeuge doch bitte mal das Verzeichnis .ssh und dann im Verzeichnis mit touch die Datei known_hosts, falls beides noch nicht existiert.
Falls die known_hosts Datei im richtigen Verzeichnis existiert, könntest Du den Fingerprint noch manuell hinzufügen.

Falls nicht:
Wurde hier wirklich alles korrekt konfiguriert und der User heißt wirklich nonexistent? Der Pfad wäre nämlich sehr merkwürdig, da Userverzeichnisse normalerwise in /home liegen, lediglich root hat sein/ihr Verzeichnis direkt in /.
 
Last edited by a moderator:
Da ich aber nicht erraten kann, was das für ein Plugin ist und um welches OS es sich handelt, ist dies das einzige was ich dir raten kann:
Einfach die richtigen Werte verwenden im Plugin und die Rechte des Munin-Plugin-Prozesses berücksichtigen.

Das klappt soweit super solange ich es via root-User ausführe.

Führe ich SFTP via einem Munin-Plugin aus, erhalte ich folgende Ausgabe beim testen des Plugins
Ich frage mich unwillkürlich kopfkratzend wie man ein Plugin als root testen kann, wo doch der cron-Prozess für Munin gar nicht als root-Prozess läuft?
 
Last edited by a moderator:
Falls der User nonexistent tatsächlich korrekt ist:
erzeuge doch bitte mal das Verzeichnis .ssh und dann im Verzeichnis mit touch die Datei known_hosts, falls beides noch nicht existiert.
Falls die known_hosts Datei im richtigen Verzeichnis existiert, könntest Du den Fingerprint noch manuell hinzufügen.

Falls nicht:
Wurde hier wirklich alles korrekt konfiguriert und der User heißt wirklich nonexistent? Der Pfad wäre nämlich sehr merkwürdig, da Userverzeichnisse normalerwise in /home liegen, lediglich root hat sein/ihr Verzeichnis direkt in /.

Nein der User heißt nicht "nonexistent". Die Fehlermeldung lautet aber so. Also in der Fehlermeldung steht wirklich "nonexistent".

Da ich aber nicht erraten kann, was das für ein Plugin ist und um welches OS es sich handelt, ist dies das einzige was ich dir raten kann:
Einfach die richtigen Werte verwenden im Plugin und die Rechte des Munin-Plugin-Prozesses berücksichtigen.

Ich frage mich unwillkürlich kopfkratzend wie man ein Plugin als root testen kann, wo doch der cron-Prozess für Munin gar nicht als root-Prozess läuft?

Debian Wheezy
Die Werte sind richtig.
Das Plugin starte ich nicht mit dem root-User. Das hast du falsch verstanden. Ich meinte, wenn ich den SFTP-Befehl außerhalb des Plugins teste, dann funktioniert die key-Auth ganz normal und ich muss kein PW eingeben. Da bin ich aber als root eingeloggt.

Als munin klappt das sind mehr und es kommt die oben genannte Fehlermeldung.
 
Wieso frage ich nach dem Plugin? Quelle?
Ich will wissen wie die Source aussieht. Dann ich ich sehen wo du was falsch machen könntest.
So will ich nicht rumsuchen und vermuten müssen.
Deine Angaben auf meine Frage sind sowas von mager.
Wies oll ich dir da helfen können?

Wäre alles richtig von dir gemacht, so würde das Plugin auch korrekte Daten auslesen.
Ist aber doch nicht so.

Aber ok, ich versteh's ja falsch.
Viel Erfolg.
 
Unter welchem User startest Du das Plugin?
Es sieht so aus das dieser User kein Home-Verzeichnis hat? (wo auch immer)
 
Solange nicht klar ist, welche Rechte das Plugin wirklich hat, ist alles sinnlos.
Aber das Plugin und dessen Konfiguration bleibt sein Geheimnis.

Wenn das Plugin unter Debian mit dem User munin startet, hat es als home /var/lib/munin. Lässt sich in passwd doch sehen.
 
Meine Vermutung ist, dass der TE nicht so ganz verstanden hat, wie SSH-Key-Auth funktioniert. Insbesondere den Part, wo die einzelnen Keys/Files liegen, die dafür notwendig sind. Außerdem testet er entweder mit dem falschen User oder er hat seine Munin-Installation vergurkt. Oder beides. Zu seiner Entlastung bezüglich dieser Vermutung hat er bisher nichts beigetragen.
 
muh.de (5.5.5.5)

Führe deinen SSH-Versuch mal bitte mit -v aus und poste den Output.

Okay. Siehe hier:

Code:
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to muh.de [5.5.5.5] port 22.
debug1: Connection established.
debug1: SELinux support disabled
Could not create directory '/nonexistent/.ssh'.
debug1: identity file /nonexistent/.ssh/id_rsa type -1
debug1: identity file /nonexistent/.ssh/id_rsa-cert type -1
debug1: identity file /nonexistent/.ssh/id_dsa type -1
debug1: identity file /nonexistent/.ssh/id_dsa-cert type -1
debug1: identity file /nonexistent/.ssh/id_ecdsa type -1
debug1: identity file /nonexistent/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version mod_sftp/0.9.9
debug1: no match: mod_sftp/0.9.9
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 3d:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:e3
The authenticity of host 'muh.de (5.5.5.5)' can't be established.
RSA key fingerprint is 3d:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:e3.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/nonexistent/.ssh/known_hosts).
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /nonexistent/.ssh/id_rsa
debug1: Trying private key: /nonexistent/.ssh/id_dsa
debug1: Trying private key: /nonexistent/.ssh/id_ecdsa
debug1: Next authentication method: password
user@muh.de's password:
debug1: Authentication succeeded (password).
Authenticated to muh.de ([5.5.5.5]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_ALL = C
debug1: Sending env LANG = C
debug1: Sending subsystem: sftp
Connected to muh.de.

Unter welchem User startest Du das Plugin?
Es sieht so aus das dieser User kein Home-Verzeichnis hat? (wo auch immer)
User munin. Ordner /home/munin nicht vorhanden (bis jetzt war das auch nicht nötig).
 
Wie kommst du eigentlich drauf, dass das Ganze funktionieren müsste?
Der User mit dem du da testest hat nicht nur keinen SSH-Key, den er benutzen kann, er hat nicht mal ein existierendes Home-Verzeichnis.
 
Kannst Du uns bitte mal verraten was Du genau vorhast, bevor wir uns weiter im Kreis drehen.
Bei mir läuft munin auf dem Server und ich greife über die Weboberfläche daruf zu. (doman.de/munin)
Ich brauche da Keine ssh/sftp Verbindung.

Ich kann deinem Vorhaben nicht ganz folgen.

Feststeht aber dein Benutzer mit dem Du auf sftp zugreifen willst hat kein Home-Verzeichnis und kann daher keine .ssh Verzeichnis anlegen.
 
Na geht doch.

Code:
ssh root@serverip -p (port) df

port fals du den Port verlegt hat.
df Konsolen Befehl der die die Belegung ausgibt
 
Das geht nicht.

Code:
exec request failed on channel 0

Ich hab "nur" die Möglichkeit via lftp oder sftp den Speicher auszulesen.
lftp hatte ich eine Zeit lang im Einsatz. Aber leider kommt es mit sehr vielen Dateien nicht klar, weswegen ich zu sftp wechseln möchte.
 
Ich möchte via SFTP ermitteln, wieviel Speicher auf dem anderen Server noch zur Verfügung steht.
Wieso via SFTP? Dafür gibt es Munin-Node. Damit kann eine zentrale Munin-Installation von anderen Systemen die Statistiken einsammeln.
 
@Elias5000 Auf einem vom Anbeiter bereit gestellten Backup-Server gibts oft keine Munin-Node ;)
Deswegen wohl sein SSH-Zugang unf das Getrickse mit df.

Aber solange Mutschas sein Plugin geheim hält, ist kaum zu helfen, an welcher Stelle er das Plugin nicht richtig benutzt.
Aber er will ja nicht.
 
Im Plugin steht nur ein Einzeiler:

Code:
echo "df -h" | sftp muh@muh.de | grep GB | cut -d " " -f7

Und ja, ich kann die Speicherermittlung auf dem Backupserver nur via einem FTP-Programm durchführen.
 
Back
Top