Databases, Systems & Networks

Sometimes that we need to connect via SSH into another computer, we find out that this computer that we intend to SSH into (which we are going to call "destiny") may be utilizing NAT and therefore it doesn 't count with a public IP address that we could use to connect to it, or it may be behind a firewall that won' t allow access from the outside.

If "destiny" can successfully establish a SSH connection to another computer that is accessible, we can utilize this second computer to establish a reverse SSH tunnel to our "destiny" computer, we are going to call this second computer "origin" (even if it is not actually the computer that we are going to use to manage "target" remotely, but only a bridge).

A reverse SSH tunnel works by connecting "destiny" to "origin" and then utilizing this connection to SSH into "destiny" from any computer that is connected to "origin". This reverse SSH tunnel should work in most Linux systems without any problem.

So, lets assume that we have this two computers:

"Origin" IP: aaa.bbb.ccc.ddd

"Destiny" IP: unknown or unavailable

First of all, we establish the SSH connection from "destiny" to "origin", enabling the reverse SSH functionality with the parameter – a:

SSH r 61999:localhost:22 [email protected]

The first number (61999) indicates which port are we going to use in "origin" to log into "destiny", localhost is the domain name that we will be using for this as well, and the last number (22) indicates which port is "destiny" listening to for SSH.

Once this connection is live, and being logged in "origin" (it doesn't matter if we are logged in locally or remotely), we can establish the connection to "destiny":

SSH p 61999 destiny_user@localhost

Effectively, we can use a computer with permanent SSH access as a bridge between computers that are not otherwise accessible via SSH. Any computer that is connected to "origin" can log into other computers with reverse SSH tunneling enabled.

Bon, a priori vous connaissez la commande "ssh-copy-id" pour copier sa clé publique sur un serveur distant afin de s’identifier par clé et plus par mot de passe.

Le principe est d’avoir une paire de clés privée/publique, le plus souvent dans "~/.ssh/id_rsa(.pub)" et de la copier à l’intérieur du fichier "~/.ssh/authorized_keys" sur la machine distante.

$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host

Mais si la machine distante n’accepte pas les connexions sur le port 22 ou bien qu’il y a une redirection de ports sur le routeur, il faut lui indiquer ce port, par exemple :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub -p 2222 user@host

Mais ça ne marche pas car ssh-copy-id ne comprend que 2 paramètres et si on met "-p 2222" en second, ça n’est pas un motif de type "[user@]host", et si on le met après, en troisième, il est ignoré.

Et bien il suffit d’entourer les infos de connexion ssh par des guillemets pour qu’ils soient vus comme un seul paramètre :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub "-p 2222 user@host"

Source: Jérémy Lecour

Voici un petit outil qui pourrait se révéler bien pratique dans votre vie de SysAdmin GNU/Linuxien

Il s’agit de MOTDStat qui via MOTD va vous permettre d’afficher le statut du serveur sur lequel vous vous connectez.

Cela va vous permettre de savoir en un coup d’œil si il y a un problème quelconque sur le serveur.

MOTDStat va générer dynamiquement le fichier /etc/motd avec les informations sur le systèmes et l’utilisation des ressources.

Les informations sont mises à jour via une tâche périodique en crontab. Le message d’origine est stocké dans /etc/motd.orig

Vous pouvez également configurer une adresse de notification, au cas où vous n’auriez pas un service de supervision qui l’aurait déjà fait, selon des limites prédéfinies :

• Charge CPU
• Espace disque
• Si des process spécifiques ne tourne pas
• Si des services réseaux sont indisponibles
• Si NTP n’est pas synchronisé avec sa référence
• Trop de mail en queue

Afin de permettre l’affichage de MOTDStat lorsque vous vous connectez en ssh il faut mettre à jour la configuration du serveur ssh (/etc/ssh/sshd_config) et positionner à « yes » le paramètre PrintMotd, puis redémarrer le service sshd.

PrintMotd yes

Le rapport MoTDStat est organisé en 3 colonnes :

• 1ère colonne : Informations sur les partitions
• 2ème colonne : information sur l’utilisation de la mémoire et du swap
• 3ème colonne : les process et services supervisés

Il est possible de configurer via le fichier /etc/motdstat/netservice d’indiquer un nom de service, ce qui rendra l’affichage plus parlant, par exemple :

tcp         127.0.0.1:80        httpd

Pour définir la liste des process à surveiller, il suffit de les préciser dans /etc/motdstat/process

Bref, un petit outils qui peut être sympa lorsque l’on a plusieurs dizaines, centaines, milliers de serveurs

Liens utiles :

Site Officiel de MOTDStat

Page de MOTDStat sur FreeCode

Source: tuto-linux.com

Sur Linux, ne vous est-il jamais arrivé de vouloir chercher une chaîne de caractères dans un dossier complet, autrement dit une multitude de fichiers ?

Et bien croyez-moi, si un jour vous devez chercher une adresse email, une adresse IP, un bout de code, ou autre, dans plusieurs milliers de fichiers, cette commande vous épargnera un gros travail manuel.

Placez vous dans le répertoire dans lequel vous souhaitez rechercher une chaîne de caractères. Et tapez la commande suivante :

find . -name "*" -exec grep -Hn "trouvemoi" {} \;

En remplaçant trouvemoi par ce que vous cherchez.

Par exemple, si vous cherchez une adresse IP dans tous vos fichiers logs à la fois, vous ferez (ne tapez que ce qui se trouve après le #) :

monlinux / # cd /var/log
monlinux log # find . -name "*" -exec grep -Hn "192.168.0.1" {} \;

Une autre technique consiste à utiliser « rgrep » qui va effectuer un « grep » récursif à partir du dossier dans lequel on se trouve et dans toute l’arborescence descendante.

La remontée d’alerte par SMS (“Short Message Service”) est un plus non négligeable dans le monitoring de systèmes d’informations critiques.

Les services gratuits permettant d’utiliser les SMS depuis le système restent rare.

Depuis plusieurs années déjà, “Google Agenda” propose à ses clients des rappels de rendez-vous par SMS.
Rapidement, ce service Google fût détourné pour être utilisé comme source de remontée d’alertes (exemple : “SmsAlert : Envoyer des SMS gratuitement depuis ses serveurs” sur le site Macsim’s Mind qui utilisait le script PHP d’ Alexander Skakunov pour remonter des alertes par SMS).

Bien que très efficaces, la plupart de ces détournement sont implémentés en PHP qui n’est pas installé sur tous les serveurs.

L’idée de cet article et d’utiliser la même technique mais implémentée en BASH.

Principe de fonctionnement

Le principe est de créer un événement dans un agenda Google Calendar débutant dans 5 minutes et X secondes et d’avertir l’administrateur par SMS 5 minutes avant le début de l’événement. Le SMS sera donc envoyé après X secondes.

L’objectif du script “googalert” (disponible sur sourceforge) est de n’utiliser que des commandes classiques du shell, de pouvoir choisir l’agenda dans lesquels seront stockés les alertes et d’être parfaitement conforme à l’API Google(http://www.udel.edu/CIS/software/dist/google/calendar/java.client/gdata/doc/calendar.htmlvoir Add an event).

Lire la suite…