Beiträge von Berichtigung

Nein. Das Kommando darf man mit diesem Schlüssel ausführen.

Dein scp führst du auf einem anderen Host aus.

Mein Beispiel ist GENAU dafür geeignet eine Datei zu kopieren.

Man lässt sich eine Datei mit cat anzeigen, piped die Ausgabe davon mit ssh auf den Remotehoste, wo dann die Datei mittels cat, das von der Standardeingabe - also von ssh liest,

cat MeineZuSicherndeDatei | ssh user@host 'cat > /remote/pfad/gesicherteDatei'

Mit cat MeineZuSicherndeDatei lassen wir uns die Datei anzeigen.

Ist nichts weiter angegeben gibt cat den Inhalt der Datei auf den Bildschirm aus.

Diese Ausgabe leiten wir mit der Pipe | weiter zu

ssh user@host 'cat > /remote/pfad/gesicherteDatei'

Gibt man einem ssh - Befehl hinter allen seinen möglichen Optionen noch ein Kommando mit, so wird eine Verbindung aufgebaut, genau dieses Kommando ausgeführt und die Verbindung wieder beendet.

Hier geben wir ihm den durch den Eintrag in der authorized_keys erlaubten Befehl cat aus.

Diesmal hat cat keine Datei, die es lesen könnte, liest also von der Standardeingabe, die letztlich vom anderen Rechner umgeleitet wurde via ssh, und leitet diese "Remoteeingabe" in die Zieldatei um. Damit die Shell nichts an dem Befehl rumfummelt, sind einfache Hochkommata nötig.

So mit haben wir die Datei MeineZuSicherndeDatei letztlich von hostA nach hostB in die Datei gesicherteDatei kopiert.

Ein command=scp ist also völlig sinnlos. Es sei denn, du möchtest von hostA tippend auf hostB ein scp zu hostC ausführen. (Man kann solche "SSH- Ketten" bis zur gnadenlosen Totalverwirrung über zig- Hosts basteln)

Ich habe einfach auf deine sehr unspezifische Frage geantwortet und dir gezeigt, wie man ganz spezifisch die Verwendung eines SSH-Keys verwenden kann. Du hast von kopieren geschrieben.

Keine Panik!

Da is doch längst kein Platz mehr.

GRINS

Das ist eine Region in einem fernen Bundesland.

Ganz komische Leute, wohnen dort mit eigenwilliger Lautsprache und seltsamen Essritualen. (Pizza und Möhrendurcheinander)

Das "command=......" steht direkt vor dem eigentlichen Schlüssel.

Jeder Key samt seinen Optionen und Commands steht in EINER EINZIGEN langen Zeile.

Also:

command=/usr/bin/cat ssh-rsa <die lange Chiffre des Keys>.

Damit kann mit diesem Cert NUR cat ausgeführt werden. Sonst gar nix.

Du kannst noch SSH Optionen angeben und sogar den Zugriff auf ein bestimmtes Verzeichnis ein schränken.

Lies einfach man 5 ssh_config

Poste das Ergebnis von "dmidecode" als root.

Es ist nicht sinnvoll Theorien aufzustellen.

Debug it or leave it.

Die Lösungsmächtigkeit für die Entstehung unverstandener Fehler ist von ebenfalls unbekannter Größe.

Was für ein hübscher Satz! gelle?

Du kannst jede SSH Verbindung nach Gusto mit diversen Mechanismen einschränken.

In diesem Falle würde das via authorized_keys erledigen.

Man kann dort jedem Schlüssel ein command= voranstellen.

Dann sieht EINE Zeile auf dem Zielsystem in ~/.ssh/authorized_keys ungefähr so aus:

command="/usr/bin/cat",no-pty,no-agent-forwarding,no-port-for warding,no-X11-forwarding

ssh-rsa AAAAB3NzaC1y........

(Du kannst die verwendeten SSH- Optionen nach Gusto ebenfalls verwenden. Mein Beispiel wird auch für Backup verwendet - nur verwende ich natürlich borgbackup ; siehe man 5 ssh_config)

'

Der "Backupbefehl" wäre dann ein schlichtes:

cat MeineZuSicherndeDatei | ssh user@host 'cat > /Ziel/verzeichnis/auf/remote/host/DortigerName'

Welche "interne" Graphikkarte?

/usr/sbin/hwinfo --gfxcard|grep -iE '^[[:digit:]]|Vendor|Device'

?

Was da wirklich passiert ist, weiß ich nicht. (Ich verwende es nicht.)

Die Fehlermeldung sagte mir aber klar, dass irgendein Socket spinnt.

Sockets sind die althergebrachte Methode, wie in *nices Prozesse miteinander "reden". Dazu wird das Netzwerkgerät "localhost" verwendet. Intern wird dazu gemäß dem heiligen Linuxgrundsatz "Everything is a file" einfach eine Datei verwendet. Diese Unixsockets stellen also eine bidirektionale Kommunikation dar, die über eine Datei abgewickelt wird. Verwendet wird dabei der Standard Netzwerkstack, außer, dass die Sockets geringfügig schneller sind, als "echte TCP/IP" Pakete, da der Adressierungsoverhead fehlt.

Warum da nun ein Socket spinnt, und warum, weiß ich nicht.

Durch obigen Befehl wird lediglich die PIM Suite gekillt. Beim danach folgenden Aufruf wird die Initialisierung dann einfach komplett neu durchlaufen.

Hier der Code:

#!/bin/bash
#  Aufruf: killKontact [<username>]
#     killt alle Prozesse, die von der KDE PIM- Suite 
#     gestartet wurden.
#

user=${1:-$USER} # wird kein User angegeben, wird $User verwendet.
ps -u ${1:-$USER}                                                    \
  | grep -iE 'akon|mysql|korga|kmail|kontact'                        \
  | awk '{print$1}'                                                  \
  | while read pid                                                   \
    do 
      kill -SIGTERM $pid  
    done

Kopiere alles in eine Datei namens "killKontact" (oder "arschgeige") und kopiere sie als Root nach /usr/local/bin,

wo sie der LSB (==LinuxStandardBase) zu liegen hat.

Mache sie mit chmod -x ausführbar.

Und nun kannst du, so Kmail wieder einmal spinnt, dieses Programm einfach aufrufen&beten.