Hi,
ich nutze einen Mac mini, den ich gerne abends manuell herunterfahren möchte.
Dies kann ich per Bildschirmfreigabe tun oder per SSH.
Folgendes mache ich bisher hierzu
Gibt es eine Möglichkeit, das PW mit zu übergeben, sodass ich ein Script hierfür einfach anklicken kann? Alternativ ein kleines Programm, das dies tut, im Optimalfall mit dem PW im Schlüsselbund.

Das SSH 192.168.0.x inkl. PW Eingabe bekomme ich mit JellyfiSSH hin.
Den zweiten Befehl bekomme ich aber nicht so unter Remote Command eingegeben, dass er auch automatisch ausgeführt wird. Es wird nur ein Terminal-Fenster geöffnet, das im Kontext des aktuellen Macs ist.

Hi! Guck mal hier, hat einer 2009 auf StackOverflow geschrieben:


Auch so könnte es gehen:


Hoffe das klappt heute auch noch so. Möchte aber anmerken, dass dann dein Passwort im Klartext im dem Script steht.

Ich komme von Linux und kenn mich mit MacOS noch nicht so gut aus. Aber unter Linux konnte man einzelne Befehle für die man normal zB sudo verwendet, schon auch eintragen, damit sie ohne Passwortabfrage möglich sind. Eben auch herunterfahren für "einfache Benutzer" usw...

Für Teil 1 bzw. das es bequem ist, kannst du zB in der Kurzbefehle App einen Kurzbefehl mit "Script über SSH ausführen" erstellen und eben den Befehl "shutdown -h now" dort eintragen. Wichtig ist aber, dass der Befehl eben kein Passwort mehr benötigt. (oder osascript -e 'tell app "System Events" to shut down')

Für den Mac gibt es die feine App "BetterTouchTool" , mit dem man prima Trackpads, Touch Bar, Magic Mouse etc. konfigurieren kann. Für iOS existiert eine Begleit-App, die mit der selben Lizenz funktioniert. Wenn Du das eh schon im Einsatz haben solltest: Mit dem iPhone im selben WLAN-Netzwerk wie der Mac kannst Du dir die Menüs aller geöffneten Apps auf allen vorhandenen Macs anzeigen lassen. Das funktioniert auch mit dem Finder: Dort einfach auf Ruhezustand oder Ausschalten tapsen... Natürlich müssen die Geräte erst mit dem iPhone gekoppelt werden, das spart die Eingabe von Passwort etc.
Alleine für diese Funktion wird es sich aber kaum lohnen, eine Lizenz zu kaufen.

Mit Bunch (bunchapp.co) können Scripte erstellt werden, um Programme zu starten, Dateien zu laden usw.
Hier ist beschrieben, wie für die Scripte Passwörter übergeben werden können:

Mit ssh von welchem Gerät aus?

Normalerweise würde ich vorschlagen, das ganze Passwortproblem zu umgehen, indem Du ein entsprechendes Schlüsselpaar installierst (man ssh-keygen). Auf einem iOS-Gerät kannst Du das natürlich nicht, auf macOS oder einem kleinen Linux-Heimautomationsserver aber schon.

Zwar richtig, aber nicht relevant.

Es gibt durchaus SSH-Clients für iOS, die die Verwendung privater Schöüssel zur Authentifizierung erlauben (z.B. Prompt, den ich einsetze: . Das löst das erste Problem: Authentifzierung beim Mac. Die Einzelheiten sind vom Client abhängig, aber im allgemeinen wird man das Schlüsselpaar auf dem Mac erzeugen und dann den privaten Schlüssel aufs iOS-Gerät transferieren müssen oder umgekehrt das Schlüsselpaar auf dem iOS-Gerät erzeugen und dann den öffentlichen Schlüssel in ~/.ssh/authorized_keys auf dem Mac eintragen müssen. YMMV.

Achtung: Private Schlüssel ohne Passphrase sind ein erhebliches Risiko und sollten nur dann verwendet werden, wenn es gar nicht anders geht. Und dann am besten auf einem eingeschränkten Benutzerkonto (keinesfalls ein Administrator!), und am besten auch noch mit möglichst engen Einschränkungen in ~/.ssh/authorized_keys. Ansonsten ist jeder, der in den Besitz der Schlüsseldatei gelangt, automatisch auf dem Zielsystem und am besten auch gleich noch Administrator. Ihr seid gewarnt.

Die Lösung des zweiten Problems wurde ja schon skizziert. Zusammengefaßt:

1. Eine Datei folgenden Inhalts in /private/etc/sudoers.d anlegen (z.B. mit dem Namen "shutdown", der Name ist aber eigentlich egal) (das geht nur mit Root-Rechten, und anstelle von "username" ist natürlich der eigene Username zu verwenden):
username

2. Kontrolle, ob das geklappt hat:

Dann sollte sich (ich habe das jetzt nicht getestet) das Kommando zum Shutdown folgendermaßen auslösen lassen:

Danke für eure Hinweise. Mit einem SSH Schlüssel habe ich das gleiche Problem, wenn ich ein Passwort dafür setze. Ich meine, es müsste eigentlich mit JellyfiSSH gehen. Allerdings weiß ich nicht, wie ich es hinbekomme, dass der Shutdown auf dem Zielrechner passiert und nicht auf dem eigenen.

Was im Terminal funktioniert:
SSH 192.168.0.x (PW eingeben)
sudo shutdown -h now (PW eingeben)

Wenn ich in JellyfiSSH als Remote Command "echo 'passwort' | sudo -S shutdown -h now" eingebe, wird das hinten an den SSH Befehl angehängt und ausgeführt. Allerdings im Kontext des aktuellen Macs und nicht des Zielsystems. Eine IP kann ich ja für Shutdown offensichtlich nicht angeben. Ein Passwort wird so von mir nicht abgefragt, da es für den SSH Befehl aus JellyfiSSH übergeben wird und für den sudo über die Standardausgabe.

Ich dachte, es gibt einen Weg, bei dem ich ein Script schreibe, das sich per SSH auf dem Zielrechner einloggt und dort den Shutdown ausführt. Ich vermute, ich gebe die Zeilen einfach weiterhin im Terminal ein. Funktioniert ja.

Ja dann setz halt keines. Genau dafür ist ein kryptografischer Schlüssel doch da, dass man kein Passwort mehr braucht.

Klar, wenn jemand Deinen privaten Schlüssel klaut, ist das blöd. Aber wenn er Dein Passwort klaut, ist es das genauso.

Kryptografischer Schlüssel mit Passwort ist doppelgemoppelt und entspräche in etwa einer 2-Faktor-Identifizierung. Die hast Du bei einem Mac sonst doch auch nicht. Was für ultrageheimes Zeugs liegt denn auf dem zu steuernden Mac, dass Dir ein Schlüssel nicht reicht?
Ja, weil JellyfiSSH das Passwort aus dem Schlüsselbund Anmeldung ausliest, der stets geöffnet ist, und Du (bzw. JellyfiSSH) zudem die Zugriffsrechte so eingestellt hat, dass JellyfiSSH das Passwort immer abfragen darf (sonst müsstest Du auch bei JellyfiSSH jedes Mal das Passwort eingeben).

Damit bist Du kein bisschen sicherer dran als mit einem kryptografischen Schlüssel ohne Passwort (der Schlüsselbund Anmeldung mit offenen Zugriffsrechten ist effektiv exakt dasselbe wie ein kryptografischer Schlüssel ohne Passwort). Du machst Dir was vor, falls Du den Schlüsselbund für sicherer hältst.
Gibt es ja. Es gibt sogar x Wege. Du brauchst halt nur den Schlüssel, um den Anmeldeprozess zu automatisieren. Irgendwie verstehe ich Dein Problem nicht. Du scheinst Dir selbst im Weg zu stehen.


PS: Ich verstehe auch nicht, warum Du auf diesem JellyfiSSH so rumreitest. Das ist doch nichts weiter als eine (schlechte) GUI für ssh.

Hi Weia,
ja, ein PW müsste ich für den SSH Schlüssel tatsächlich nicht setzen. Wäre eine Alternative. Und auf dem entfernten Mac ist auch tatsächlich nichts Wichtiges.

Auf JellyfiSSH reite ich nicht herum. Ist halt ein GUI für SSH, das mir das Leben einfacher macht. Alt, aber funktioniert. Ich hatte es mir halt so einfach vorgestellt, ein Kommando optional eingeben zu können.

Alternative ginge sicherlich ein Shell Script. Allerdings wird das Shutdown nach dem SSH Login bei mir nicht auf dem Zielrechner ausgeführt. Irgendwas mache ich also falsch.

Wie schon geschrieben, kein schlimmes Problem, da ich ja nur zwei Zeilen im Terminal eingeben muss, die auch noch in der Historie stehen. Dennoch wäre ein Script, für das ich ein Icon ins Dock lege hilfreich.

Ich habe oben Bunch empfohlen. Mit Bunch ließe sich ein Bunch-Script in der Menuleiste unterbringen, das Script sähe dann wie folgt aus. Ich habe das mit dem Kommando "sudo ls" ausprobiert, da ich dann die Übermittlung eines Passwort testen kann. " iTerm2" ggf. durch "Terminal" ersetzen, "PW" durch die Passwörter.


Im ersten Link oben ist das komplizierter, weil das Schlüsselbund genutzt wird. Hier ist alles im Klartext.

Also dann …! Das ist wirklich so viel komfortabler.

Auf Deinem SteuerMac gibt Du in dem Nutzeraccount, in dem Du RemoteMac steuern willst, folgendes ein:
Den vorgeschlagenen Dateinamen zum Speichern akzeptierst Du.

Dann findest Du in Deinem Heimordner in dem Ordner .ssh/ 2 Dateien, id_rsa (das ist der private Schlüssel, den Du nicht aus der Hand geben darfst) und id_rsa.pub (das ist der öffentliche Schlüssel).

Auf RemoteMac gehst Du im Heimordner des Nutzers, bei dem Du dich zum Steuern anmelden willst, ebenfalls in den Ordner .ssh/ (bzw. legst ihn an, wenn er noch nicht existiert) und kopierst den Inhalt des öffentlichen Schlüssels in die Datei authorized_keys in eine neue Zeile (evtl. existierende Einträge nicht löschen bzw. umgekehrt die Datei anlegen, falls es sie noch gar nicht gibt).

Also z.B., wenn Du auf SteuerMac zwei Terminalfenster offen hast, ein lokales und eins über ssh auf RemoteMac, dann machst Du Folgendes:

SteuerMac:
Der Schlüssel wird dann als Text im Terminalfenster angezeigt; den kopierst Du vollständig ganz normal mit C.

Remote Mac:
wobei Du, statt VVVVV zu tippen, V machst und also den Text des öffentlichen Schlüssels einfügst.

Ab dann kannst Du dich von SteuerMac ohne Passwortabfrage auf RemoteMac via ssh einloggen.
Ja eben nicht! Es macht Dir das Leben unendlich schwieriger, weil es nicht erlaubt, was Du möchtest. GUIs können nie alles, was Kommandozeilen können.
Ist es ja auch, wenn Du das Passwortproblem gelöst hast.

Dieser Einzeiler schaltet dann den entfernten Rechner aus:
Dieses simple Beispiel verwendet AppleScript, weil Du dann nicht root sein musst, um das Skript auszuführen. Das bringt allerdings drei Einschränkungen mit sich:

• Auf dem entfernten Mac musst Du in demselben Nutzerkonto angemeldet sein, das Du für ssh verwendest (in dem Beispiel also termi)
• Auf dem entfernten Mac darf kein weiterer Nutzer angemeldet sein (weil der Mac dann das Ausschalten mit einer Warnung und Nachfrage unterbricht)
• Auf dem entfernten Mac dürfen keine nicht korrekt programmierten Programme laufen, die den Ausschaltvorgang mit einer Nachfrage unterbrechen, statt stillschweigend zu sichern und zu beenden

Sind diese Bedingungen erfüllt, ist obiger Einzeiler das Einfachste. Sonst musst Du dich eben doch mit sudo shutdown herumschlagen.

Du kannst den Befehl in einem Einzeiler-Skript sichern:
Das sicherst Du dann in ~/Library/Scripts unter dem Namen, den der Befehl haben soll, also z.B. ~/Library/Scripts/"RemoteMac ausschalten" und machst es ausführbar:
Ja, Du versteifst dich auf JellyfiSSH.

Was spricht jetzt dagegen wie oben beschrieben mit der Kurzbefehle App einen Kurzbefehl mit "Script über SSH ausführen" zu erstellen, wenn du an Zielrechner kein Kennwort mehr benötigst? Bequemer geht ja im Grunde nicht mehr...

Schau Dir mal Mac-App Apple Remote Desktop an. Die speichert das Passwort im Schlüsselbund. U.A. Ruhezustand, Neustart oder Shutdown kann man auch als Menüleisten-Objekt nutzen.
Am Ziel-Mac müssen nur grundsätzlich ein paar Sharing-Optionen gesetzt sein, damit das funktionieren kann.

Eventuell eine alte MacOS-Version.
Damit sich andere mehr unter der von Dir genannten Aktion vorstellen können, hier der Screenshot dazu:

Bedenkenträger hier:

ich würde keine Lösungen bauen, die deine Sicherheit strukturell verschlechtert. SSH keys ohne passwort sind IMHO keine gute Idee.

Was ich an deiner Stelle machen würde:

* apache mit mod_cgi installieren
* ein cgi script hinterlegen das reboot macht (da kann man ja auch ein passwort abfragen)
* dem user der das script ausführt über sudoers ein passwort-loses sudo recht auf /sbin/reboot geben

hier ist keine security verschlechtert und das größte risiko ist, dass jemand den endpunkt findet (oder das passwort bekommt) und dann deine Kiste rebooten kann.

Absolut Deiner Meinung. Daß Paßwörter eine suboptimale Lösung sind ist kein Argument, eine andere suboptimale Lösung mit SSH aufzubauen.
Kann man so allgemein nicht stehen lassen. Wenn man das geeignet einschränkt, geht es ohne nennenswerte Sicherheitseinbußen.

In der authorized_keys kannst Du die Möglichkeiten dessen, was ein spezifischer private key tun darf, massiv einschränken. Sollte man bei einem paßwortlosen Key natürlich auch.

Wenn man ganz auf Nummer Sicher gehen will, kann und sollte man dann einen spezifische Account dafür anlegen, der per sudo das darf, was er dürfen soll (z.B. shutdown) und sonst keine Rechte hat. Und auf den und auf den allein der paßwortlose Key die entsprechenden Zugriffsrechte hat und keine sonst.
Das geht auch, ist aber erheblich aufwendiger als ein entsprechend beschränkter SSH-Key und auch nicht sicherer. Allein Apache ist ein Moloch an Software, der bei etwas weniger sorgfältiger Konfiguration mehr Löcher aufreißt als man will.

Und außerdem brauchst Du schon wieder ein Paßwort, das war doch gerade die Augabenstellung.
"Security by obsucrity", ganz schlechte Idee.
Und ein Paßwort obendrein. Da ist ein paßwortloser SSH-Key noch besser.

Vom Telefon aus, per Shortcut? Keine Ahnung wie es beim Mac ist, aber meinen Raspberry reboote ich mit einem Tap am Telefon. Über genannten Kurzbefehl "Script über SSH ausführen".

Ich streite nicht im Internet, aber ich sehe das nicht so. Egal.

Wenn Du mir jetzt noch erklären könntest, wieso sich die Sicherheit da „strukturell verschlechtert“?

Ich gehe davon aus, dass in einem privaten lokalen Heimnetzwerk ein bestimmter Nutzer auf allen Macs dasselbe Anmeldepasswort hat; alles andere ist wirklich nur für Sicherheits-Paranoiker. Um an den privaten Schlüssel auf dem SteuerMac zu kommen, musst Du dich dort einloggen können. Wenn Du das kannst, kannst Du es auch gleich auf dem RemoteMac. Also wo ist da ein Problem?

Ich verweise nochmals darauf, dass auf dem Mac die allermeisten privaten Schlüssel in dem Schlüsselbund Anmeldung liegen und so eingestellt sind, dass sie die entsprechenden Apps ohne Nachfrage immer lesen können; auch Apples Remote Desktop handhabt das im Regelfall so. Das ist im Endeffekt exakt dasselbe wie ein privater Schlüssel ohne Passwort. Andernfalls müsste man z.B. beim Versenden von signierten Emails jedes einzelne Mal das Passwort eingeben. Das tun wirklich nur Sicherheitsmasochisten.

Ich verweise zudem darauf, dass Termi selbst sagt, dass auf dem RemoteMac nichts sonderlich Schützenswertes liegt. Also lass mal die Kirche im Dorf.
Ich verstehe das auch generell nicht. Es ist doch klar, dass ein privater Schlüssel in niemands Hände gelangen darf; wenn man darauf aufpasst, ist das anders als passwortgestützte Lösungen sicher. Ein Passwort für einen Schlüssel finde ich so ähnlich wie Türen mit drei verschiedenen Vorhängeschlössern dran.

Man kann sein Leben auch damit zubringen, sich abzusichern. Ich selbst betreibe seit 25 Jahren mehrere Server im Internet, bei allen erfolgt der ssh-Zugang über Schlüsselpaare ohne zusätzlichen Passwortschutz. Das reicht völlig, ich hatte nie Probleme.
Und das soll sicherer sein? 😂 Und einfacher? (Termi ging es um eine einfache Lösung.)
Nochmal: man braucht keine root-Rechte, wenn man AppleScript verwendet.

Dann halt eine alte iOS-Version … 🙄

Hätte ich so gemacht, wenn es nicht €80 kosten würde. Das ist es mir definitiv nicht wert.

Das Problem ist dass du annimmst dass deine private key datei nie in falsche Hände kommt.

Stimmt, davon gehe ich aus. Ich nehme auch an, dass ich Wohnungs und Autoschlüssel nicht verliere (viel wahrscheinlicher!), mir der Himmel nicht auf den Kopf fällt, meine Wohnung nicht explodiert und und und. Ich sehe nicht, wo da ein Problem liegt.

Passieren kann alles, sein Leben nach extrem unwahrscheinlichen Ereignissen auszurichten, halte ich aber für wenig sinnvoll.

Außerdem: Falls mein privater Schlüssel in falsche Hände gerät, wer sagt, dass mein Passwort das dann nicht ebenso tut?

Mit Ja, aber wenn der private Schlüssel in falsche Hände fällt kannst Du das ganze Konzept asymmetrischer Kryptographie ad absurdum führen.

Ich bin ja niemand, der an einer kritischen Schaltstelle öffentlicher Infrastruktur sitzt; da fände ich ein erhöhtes Maß an Absicherung nachvollziehbar.

Dass beide Befehle ein PW benötigen. Das SSH bekomme ich ja noch hin, da das PW aus dem Schlüsselbund genommen werden kann. Beim sudo für den Shutdown muss ich schon über ein echo 'passwort' | sudo -S arbeiten, damit es klappt. Mein Problem ist eher, dass bei meinen Versuchen der Shutdown nicht für den Zielrechner ausgeführt wurde, sondern für den steuernden.

... und was ist das Ergebnis mit Bunch?

@Weia
Danke für die Tipps. An AppleScript hatte ich nicht gedacht. Habe jetzt mal den SSH Key ohne PW erzeugt und auf den zu steuernden Mac nach authorized_keys kopiert. Ohne Texteditor mit
scp /Users/termi/.ssh/name.pub termi@192.168.1.x:/Users/termi/.ssh/authorized_keys

Mit ssh termi@192.168.1.x osascript -e \'tell application \"Finder\" to shut down\' kann ich den Zielrechner herunterfahren, aber ich werde trotzdem noch nach einem PW gefragt.

Habe extra auf dem Zielrechner die authorized_keys gelöscht und nochmal den Key rüberkopiert. Es wird trotzdem nach einem PW gefragt. Der Ziel-Mac mini Server läuft unter macOS 10.13.6.

Woher "weiß" der SSH Aufruf auf dem Steuer-Mac, dass SSH mit dem Schlüssel statt Passwort erfolgen soll?
Meldet der ZielMac die in autorized_keys enthaltenen Key IDs und der SteuerMac schaut nach, ob er dafür einen hat? Meine einzige Idee ist, dass nicht erkannt wird, dass ein SSH Key vorhanden ist.

@all In diesem Fall ist keine extreme Sicherheit notwendig, da auf dem ZielMac nur OBS läuft, das eine Videobild in Echtzeit mischt. Den will ich abends einfach herunterfahren. Somit ist die PW lose SSH Key Option hierfür passend.

Da es bis dahin offenbar keine Datei authorized_keys auf RemoteMac gab, könnte das ein Zugriffsrechte-Problem sein; das hatte ich nicht bedacht. Wenn die Zugriffsrechte nicht stimmen, ignoriert ssh authorized_keys.

Die Zugriffsrechte kannst Du dir mit ls -la anzeigen lassen. name.pub sollte als öffentlicher Schlüssel logischerweise von allen lesbar sein (-rw-r--r--). authorized_keys hingegen darf nur vom Kontoinhaber gelesen werden können, also -rw-------. Das kannst Du ggf. mit chmod 600 authorized_keys einstellen.

Und dann prüf doch erstmal, ob Du dich mit ssh auf dem anderen Rechner erfolgreich anmelden kannst, also ssh termi@RemoteMac (das termi@ kannst Du auch weglassen, wenn es um denselben Nutzer auf beiden Macs geht). Du müsstest ohne Passwortabfrage sofort verbunden sein.

Erst wenn das klappt, kommt der 2. Schritt mit dem Shutdown-Befehl.Wenn das Einloggen via ssh ohne Passwort funktioniert (1. Schritt), sollte das auch bei diesem Befehl der Fall sein.
Ungefähr so. ssh auf dem ZielMac sieht nach, ob es für nutzer@steuermac einen öffentlichen Schlüssel gibt (nutzer@steuermac steht ja am Ende des öffentlichen Schlüssels). Nur wenn das der Fall ist, sendet er den (und nur den) zu ssh auf dem SteuerMac.
Wie gesagt, ich vermute, es sind die Zugriffsrechte. Wenn nicht, sehen wir weiter.

Zugriffsrechte für authorized_keys sind -rw-r--r--. Sieht für mich gut aus.
Bei ssh auf den entfernten Mac kommt eine PW Abfrage. Den Benutzernamen, der auf beiden Mac identisch ist, kann ich dabei tatsächlich weglassen.

Mit etwas Probieren habe ich jetzt herausgefunden, dass ich den SSH Private Key angeben muss.
Ich habe alle Keys in eigenen Dateien. Vermutlich müssten diese in id_rsa stehen, damit SSH diese automatisch findet. Mein Denkfehler. Dachte, es wird alles in .ssh berücksichtigt.

Mit ssh -i ~/.ssh/keyname.prv 192.168.1.x komme ich ohne PW Nachfrage auf den entfernten Mac.

Entsprechend kann ich ihn mit ssh -i ~/.ssh/keyname.prv 192.168.1.x osascript -e \'tell application \"Finder\" to shut down\' herunterfahren. Das Script habe ich mit Extension .command gespeichert und kann es so per Doppelklick starten. Danach habe ich im Terminal noch eingestellt, dass das Fenster nach Ausführung automatisch geschlossen wird.

Problem gelöst. Danke!

Sollte wie gesagt eigentlich -rw------- sein, aber wenn’s geht …
Yep, daher:Naja, in .ssh/ stehen auch die authorized_keys, ggf. eine Datei namens known_hosts usw. ssh muss daher schon wissen, in welcher Datei die privaten Schlüssel stehen. Default ist halt id_rsa, da schaut ssh von selbst nach. Sonst eben per -i explizit angeben.
Fein.