Databases, Systems & Networks

Most hardcore command line users and unix geeks love vi, but I prefer nano. If you want to change your default crontab editor to nano, here’s how to do this:

For a one time edit, launch the terminal and type:

EDITOR=nano crontab -e

If you want to set nano as your default editor in general, you use this command:

export EDITOR=nano

Now when you go to edit crontab, nano will be the default editor than vi. You can test this by typing:

crontab -e

Looking beyond Mac OS X, this should work in Linux as well.

source: http://www.debianworld.org/securite.knockd

Knockd est un petit daemon qui autorise ou non une connexion à votre serveur. Pour cela il écoute les ports de votre machine et attend une séquence bien précise de connexions sur les ports que vous avez définis. Si la séquence définie est exécuté dans le bon ordre, le daemon va ouvrir le port et permettre une connexion pour un temps déterminé sur le port ssh par exemple. La séquence peut utiliser des connexions TCP ou UDP ou les deux.

Ainsi, d’un point de vue extérieur le serveur n’a aucun port d’ouverts exception faite pour les clients qui ont la séquence « magique ».

Lire la suite…

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