Deux petites astuces et un fou furieux

Tout a commencé par une petite astuce qui a pas mal tourné en 2013-2014, envoyer un mail lors d’une connexion. Je vous mets trois liens : it-connect, memo-linux, blogmotion.

Pour ma part j’apprécie ce genre de petite astuce. C’est simple à mettre en place, ça peut rendre service et c’est un peu du fait maison, un pirate ne pensera pas forcément à ça. Personnellement j’utilise cette ligne dans mon /root/.bashrc sur mon server@home afin d’avoir un mail avec l’heure et l’adresse IP dès que quelqu’un se connecte en root.

On reçoit alors un mail sur cascador@seulaumon.de avec le corps suivant lorsqu’on se connecte en root sur notre server@home.

Quelques temps après je me suis rendu compte d’une « lenteur » lors de la connexion en root avant l’affichage du prompt, pas grand-chose mais comme VLC. J’ai vite compris que ça venait de cette ligne et j’ai confirmé mon hypothèse en l’effaçant.

Et puis là je me suis posé une question existentielle profonde : Comment mesurer le temps nécessaire pour se connecter en SSH ? Car je me connecte en root via SSH (oh my god !), j’utilise l’option Match pour sécuriser l’accès (en plus du changement de port, fail2ban, iptables, etc.). J’ai mis un peu de temps à trouver car il a fallu que je cogite, la question n’a rien donné sur le net. Voici la ligne magique.

L’ingrédient le plus important de cette recette c’est de s’authentifier par clés mais sans mot de passe. En effet si vous avez un mot de passe à taper alors la commande time enregistrera bien évidemment le temps que vous allez mettre pour taper votre mot de passe.
time : La commande time va nous permettre de mesurer le temps nécessaire pour se connecter en SSH
ssh : On utilise bien entendu la commande ssh pour se connecter sur notre server@home
-p 8022 : Vous n’utilisez sûrement pas le port 22 par défaut donc on utilise l’option -p afin de préciser le port sur lequel on doit se connecter. Ici le port d’écoute du service SSH de notre server@home est le port 8022
root@192.168.1.50 : On se connecte en root sur notre server@home ayant l’adresse IP 192.168.1.50
exit : La « petite » difficulté, afin de pouvoir mesurer via time le temps nécessaire pour se connecter en SSH, on se déconnecte sitôt connecté d’où la commande exit

On a donc là notre première astuce qui permet de mesurer le temps nécessaire pour se connecter en SSH. Voici maintenant les résultats.

On a une différence de 2 secondes pour chaque connexion en root. On a un vrai problème, quelque chose de pénible. Je me suis tout de suite mis sur nohup, &, disown et ça n’a rien donné.

J’en étais déjà à 4 bonnes heures de réflexion et là j’ai trouvé la solution par hasard en testant des choses trouvées sur le net.

Toute la solution se situe dans &> /dev/null (qui est une abréviation de >/dev/null 2>&1 et je vous invite à consulter ce lien). C’est quelque chose de très connu, que je comprends parfaitement et que j’utilise très régulièrement. On redirige STDERR et STDOUT vers null.

Je n’ai pas honte de le dire je ne comprends pas, je ne comprends pas du tout. J’invite les bonnes âmes à m’expliquer. STDERR et STDOUT ne renvoient rien, j’ai fait un test en redirigeant tout ça dans un fichier. Le fichier est créé mais il est vide. Je précise qu’évidemment je reçois bien le mail et que le temps est inférieur à 0m0.500s.

Ce qui pourrait être intéressant c’est que je trace ce qui se passe exactement au niveau processus mais arrivé là on doit déjà me prendre pour un fou furieux, je ne vais peut-être pas continuer…

Déjà 14 avis pertinents dans Deux petites astuces et un fou furieux

  • tintouli
    Salut,
    Juste une hypothèse, mais, même s’il n’y a rien à envoyer sur les sorties standard et erreur, le simple fait d’en avoir la possibilité provoque des appels supplémentaires qui sont squeezés avec le &> /dev/null

    (mais bon , quand même, 2 secondes …)

    SInon, tu as essayé sans l’appel à ‘date’ et à ‘who’ (juste avec l’envoi du mail) ?

  • C138
    « Ce qui pourrait être intéressant c’est que je trace ce qui se passe exactement au niveau processus »
    Et oui… just do it. La commande strace est ton amie (avec les options de mesure de temps)
    Et, si ça marche, tu devrais avoir toutes les informations pour conclure.
  • C138
    ah oui, au fait, j’utilise la même astuce depuis un certain temps… mais dans /root/.profile
    Une idée de la différence de comportement potentielle ? (.profile vs bash.rc)
    ?
  • Bruno
    Au passage, n’oublie pas que .bashrc n’est pas nécessairement exécuté. Tu peux par exemple tester avec :

    ssh root@monserveur.fr bash --norc

  • Bruno
    Il faut que tu regardes les différences entre shell interactif/non-intercatif login/non-login
    ex :http://www.linuxfromscratch.org/blfs/view/6.3/postlfs/profile.html

    Attention comme je l’ai indiqué avant ces fichiers ne sont pas nécessairement interprétés. Un utilisateur connaissant le mot de passe ou ayant déjà sa clé sur le serveur peut parfaitement se connecter (ou acquérir les droits root via sudo ou su) sans que le mail ne soit envoyé.

  • attention ce mail n’est pas véritablement une astuce pour suivre les connexions ssh mais plus exactement les connexions au shell.
    sshfs root@leserveur:/ /mnt/serveur
    sftp://root@leserveur
    2 solutions pour entrer sur le serveur via ssh qui ne chargent pas un shell
  • Bruno
    Concernant les différents types de shell, c’est juste pour comprendre dans quelles circonstances les fichiers bashrc et profile sont, ou ne sont pas interprétés.

    Mes commandes fonctionnent. Évidement tu ne vois pas le prompt habituel puisque le bashrc n’est pas interprété, donc $PS1 est vide entre autres. Mais tu peux tout à fait taper des commandes. Par contre dans le premier cas, avec l’option –norc, tu ne devrais pas recevoir le mail. Si tu es sous Debian/Ubuntu tu peux aussi faire :
    ssh -p 8022 root@192.168.1.50 sh

Les commentaires sont fermés.