Démarrer / arrêter un pc par le réseau.

[Dark26]

Dans ma pièce "d'été" j'ai mon mon "serveur" vidéo ou arrive l'antenne TNT et forcément le tuner TNT.

Grace à VLC je récupère le flux sur le réseau.

Pour éviter d'avoir à me déplacer à chaque fois pour allumer et éteindre le pc "serveur" qui se trouve à l'autre bout de la maison , je voudrais pouvoir faire ça a distance à partir de 2 raccourcis sur mon bureau.

J'ai déja 3/4 des solutions, et ce qui me manque n'est pa sforcément celui qu'on croit

Allumage à distance du PC

Sur le SERVEUR :

- Dans le bios du serveur, activé l'option wakeon LAN. ( en passant j'ai désactive la détection du clavier) .

- Ne pas couper l'alimentation ( il faut quer ça puisse démarrer quand même).

Sur le PC CLIENT

Installation du logiciel wakeonlan, rien de plus facile sous Ubuntu :

sudo aptitude install wakeonlan

La commande magique :

wakeonlan 00:02:ae:ff:00:00

Où 00:02:ae:ff:00:00 représente l'adresse mac de la carte réseau du serveur.

et voila . Un petit lancer sur le bureau et zou.

Extinction à distance du PC

c'est la que ça se complique, car je voudrais le faire proprement.

Mn problème étant ce fameux mot de passe du root.

actuellement je me logue en SSH sur le serveur, et je fais

sudo halt

et hop.

Ma question est donc :

Commant puis-je créée un lancer pour lancer cette commande à partir du bureau, pour que cela ne me demande que le mot de passe du root? ( sans avoir a ouvrir une console.)

Je vais chercher de mon côté mais si vous avez une idée.

[tyrann27]

bon il est interdit de rigoler...

Ma façon de contourner serait la suivante :

- Jouer avec un fichier de config pour se logguer en ssh comme ça meme pas besoin d'entrer le mdp du log.

- créer un user spécifique au shutdown

- jouer avec les groupes pour qu'il ait le droit de shutdown le pc

- insérer la commande dans le profile

Je pense qu'il y aura mieux

(j'en connais un qui va encore dire que j'encule les mouches)

[Compte_supprime_74291]

Le plus simple, c'est encore d'autoriser l'un des utilisateurs sur ton serveur à exécuter "sudo /sbin/halt" sans taper de mot de passe (renseigne-toi sur le sudoers et visudo), et d'installer un serveur SSH dessus...

... tu copies alors une clé publique dans le ~/.ssh/authorized_keys de l'utilisateur dont je t'ai parlé, sur le serveur, et tu laisses la clé privée, chiffrée avec un mot de passe sur le client duquel tu veux commander le serveur...

Au passage, tu installes un askpass pour SSH (il y en a plusieurs... à toi de voir celui qui te plaît), et lorsque tu veux arrêter le serveur, tu fais quelque chose du genre :

- charger la clé dans un agent avec ssh-add (ce qui démarrera le askpass pour déchiffrer ta clé privé, avec son mot de passe) sur ton client;

- exécuter "sudo /sbin/halt" via ssh en mode commande (à partir du client, ce qui aura pour effet d'exécuter l'instruction sur le serveur, et se fera sans mot de passe, si ton utilisateur a le droit de le faire dans le sudoers de la machine);

- décharger la clé de l'agent (si tu veux devoir retaper le mot de passe à chaque fois que tu t'en sers, et pas une seule fois pour la session) [encore et toujours sur le client]...

Mais utiliser le mot de passe du root (root, dont j'éviterais de me servir aussi directement, surtout sous SSH) ou d'un autre utilisateur du serveur, sur le client, en mode clickodrome, ce n'est pas très pratique... pour le coup, il est plus simple de te contenter du mot de passe d'une clé privée.

[fabien29200]

Ou carrément sans mot de passe si tu mets la clé publique de ton utilisateur dans le authorized_keys du .ssh du root !

reste à faire : ssh root@leServeur halt

[Compte_supprime_74291]

C'est la clé privée, généralement, qui est protégée par un mot de passe... qu'on déclare la clé publique sur le compte de root ou pas ne change pas grand chose à ça...

... par contre, il n'est pas raisonnable d'utiliser une clé privée sans mot de passe (car n'importe qui récupérant le fichier peut alors se connecter aux machines où la clé publique est installée)...

... et il est déraisonnable à l'extrême de se connecter en root, surtout par SSH... sudo permet justement de déléguer juste les droits dont on a besoin (et de choisir si l'on veut exiger un mot de passe quand même ou pas... ce qui annihile l'intérêt de passer par root juste pour ne pas avoir un mot de passe à taper, vu qu'on peut faire la même chose avec sudo en infiniment plus propre): pourquoi donner un accès complet au compte root?

Donner un mot de passe, juste pour décoder la clé, afin d'accéder à un compte limité qui n'a que le droit de faire /bin/halt avec les droits root, ça me paraît quand même infiniment plus propre...

[tuXXX]

Il y a plusieurs solutions, par exemple utiliser une clé spéciale qui servira uniquement à éteindre le PC :

Sur le client :

 $ ssh-keygen -t dsa -f key_shutdown
Generating public/private dsa key pair.

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in key_shutdown.
Your public key has been saved in key_shutdown.pub.
The key fingerprint is:
30:11:34:4e:24:49:9f:47:82:a1:cb:15:7f:a6:78:d8 user@client
$ scp key_shutdown.pub user@server:~

Sur le serveur ensuite :

 $ echo -n 'command="halt" ' >> ~/.ssh/authorized_keys
$ cat key_shutdown.pub >> ~/.ssh/authorized_keys

(cela va ajouter la clé publique avec « command="halt" » juste devant)

Ensuite, il suffit d'utiliser cette clé depuis le client (il y a même moyen d'utiliser un alias ) :

 $ ssh -i key_shutdown user@server

et hop ça marche!

On peut même limiter dans le fichier les adresses des clients autorisés, ou d'autres choses (par exemple "no-pty" peut aussi être intéressant)

[Compte_supprime_74291]

Ca marche... si l'utilisateur du serveur a le droit d'exécuter /sbin/halt... ce pourquoi je conseillais de modifier le sudoers juste pour cet utilisateur...

Sinon, apparemment, Dark26 veut avoir un mot de passe à taper... vu qu'en gui, taper celui de l'utilisateur distant pour exécuter le halt n'est pas ce qu'il y a de plus facile (j'imagine une solution improbable et tortueuse avec laquelle on se connecte via ssh sur le serveur, via lequel on exporte un gksu avec juste la partie serveur de X.org ... ça doit être faisable, mais paie la solution de goret), on peut se contenter de taper celui de la clé privée...

... et pour ça, on peut passer par ssh-add, pour bénéficier d'un askpass (ce qui n'empêche pas de la décharger dès qu'on s'en est servi, pour éviter qu'elle ne soit dispo ad vitam sessionam à partir du moment où elle a été chargée une fois)...

Après, si au fond, il ne veut pas de mot de passe, et même dans le cas contraire, encadrercastrer les possibilités de l'utilisateur sur le serveur SSH distant, c'est toujours une bonne idée

[tuXXX]

Effectivement, après soit il faut mettre /sbin/halt en suid, soit utiliser sudo, le tout soit que l'utilisateur concerné puisse arrêter l'ordinateur. (par exemple si on veut faire ça un peu sécurisé, un utilisateur avec /bin/false en shell, avec juste le droit en sudo sur halt sans mot de passe)

Puisque cela ne pose du coup pas de problème côté serveur, il suffit donc effectivement d'avoir quelque chose de graphique pour demander le mot de passe de la clé ssh.

[Dark26]

je me suis battu avec le wake on lan .... on dirait un problème de bios qui n'arrive pas à garder l'adresse MAC .

je viens de faire une trentaine d'aller retour à travers la maison... ras le bol

[theocrite]

N'oublie pas que les adresses mac ne sont pas facilement récupérable entre chaque op.

En clair dès que tu as un switch, il est fort possible que tu n'ai plus accès à la mac.

[Marco07]

pour éviter de faire simple

moi j ai une technique encore plus bête qui nécessite un repertoire partagé(tech prof tournesol ) pour redémarrer par ex(ou pour éteindre ou autre), un script qui tourne en boucle qui vérifie le répertoire partagé, si je copie le fichier par ex key.reboot dans le repertoire partagé et si ce fichier contient mettons "azerty" hop le fichier s'efface & le pc reboot...

après tu fais tout ce que tu veux, ça évite de passer par ssh etc & sudo...

& pour ton icone, un simple raccourcis vers un script qui crée par ex key.reboot dans ton répertoire partagé

et oui j'ai consulté un psy, il a fini par se pendre