Dans le tp précédent nous avons donc modifié le paramètre PermitRootLogin, du fichier /etc/ssh/sshd_config, pour le passer à yes. Ainsi nous autorisons les connexions SSH en Root, en utilisant le mot de passe choisi lorsde l'installation de la VM Debian.
Cette technique est utile afin de réaliser des premières connexions SSH, mais elle est assez vulnérable face à un certains nombres d'attaques (attaque par dictionnaire, etc...). Elle ne profite pas de l'utilisation des clefs ssh qui permettent une connexion beaucoup plus sécurisée.
On utilise la commande suivante pour générer une clef d'authentification depuis la machine Windows :
ssh-keygen
Une série d'instructions demandent le nom du fichier de stockage et le mot de passe. A l'issue de cela une paire de clef est créée : une clef privée et une clef publique. Par défaut les fichiers sont stockés dans /home/$USER/.ssh/id_rsa.
Dans le cadre du tp, on ne met pas de mot de passe pour simplifier les opérations, mais bien évidemment dans un cas réel il faut un mot de passe pour se prémunir si la clef privée est volée, ou si quelqu'un accède à votre machine etc...
VM Debian :
Dans une machine Linux, la liste des clefs publiques autorisées à se connecter se trouvent dans le fichier /home/$USER/.ssh/authorized_keys. Ici on les mettra dans le fichier /root/.ssh/authorized_keys. Il faut donc le créer en lui attribuant les droits chmod 700 authorized_keys.
Windows :
On veut maintenant copier la clef publique de la machine Windows vers la VM Debian dans le fichier créé précédemment. De cette manière, on pourra se connecter en SSH sur la VM depuis la machine hôte. Pour ce faire deux techniques différentes.
scp:
scp /path/to/key/id_rsa.pub root@ip_address:/root/.ssh/
ssh-copy-id:
Malheuresement cette commande n'est pas disponible sur Windows, heuresement il est assez facile de la reproduire (utilisation de cmder pour avoir le shell bash) :
cat .ssh\id_rsa.pub | ssh root@ip_address "cat >> ~/.ssh/authorized_keys"
On peut désormais se connecter en SSH en utilisant la clef. Dans la VM, on modifie le fichier /etc/ssh/sshd_config pour repasser le paramètre PermitRootLogin à prohibit-passwor.
On peut faire un test de connexion, si on nous demande le mot de passe de la clef (ou pas de mot de passe si laissé blanc) alors nous avons bien effectué une connexion SSH avec la clef.
La procédure réalisée dans le point précédent nous permet d'accepter seulement les connexions par clef SSH, et cela est beaucoup plus sécurisée car empêche les attaques de type brute-force.
Ces attaques consistent à réaliser un grand nombre de tentatives de connexion, en se basant sur un dictionnaire composé des mots de passe les plus fréquents.
Avant nous nous connections juste avec le mot de passe root donc vulnérable face à ces attaques. Grâce à l'authentification par clef SSH, l'utilisateur doit avoir sa clef privée en local et sa clef publique sur la machine distante.
Chaque nouvel utilisateur devra donc ajouter sa clef publique par le biai de l'administrateur.
On peut aussi paramétrer d'autres choses comme le nombre de connexions : NumberOfPasswordPrompts, ou bien le pare-feu en effectuant une white liste par example.
source : https://blog.garamotte.net/posts/2018/01/07/fr-limit-brute-force-attacks-on-the-ssh-service.html
TIME : temps cumulé de l'utilisation du processus
Processus ayant le plus utilisé le processeur :
ps aux --sort=time kworker
root 13 0.1 0.0 0 0 ? I 14:15 0:08 [kworker/0:1-events]
Premier processus au démarrage de la machine :
Ps aux --sort=start_time
root 1 0.0 2.0 104904 10280 ? Ss 14:15 0:02 /sbin/init
Heure de démarrage :
who -b
démarrage système 2020-01-16 00:46
Temps actif :
uptime
03:22:53 up 2:36, 1 user, load average: 0,41, 0,40, 0,43
Nombre de processus :
ps aux | wc -l
69
PPID :
ps -ef
Liste ordonnée PPID (machine personnelle):
ps -efo comm,pid,ppid
COMMAND PID PPID
fish 10107 10099
\_ ps 16991 10107
Avec l'utilisation de pstree : permet d'afficher l'arbre des processus ancêtres.
apt install psmisc
Pas trouvé, piste explorée : watch d'un script qui exécute toutes les 0.1 secondes un ps aux en récupérant le PID de ce même ps. Problème le PID est récupéré quand la commande est terminée, on ne peut donc pas lancer un pstree avec ce PID.
#!/bin/bash
ps aux | awk '/ps/ {print $2; exit}' | head -n 1 > res.txt
Utilisation de top : même chose que ps mais rafraîchi l'affichage.
Touche d'aide : H
Liste processus trié par occupation de mémoire :
top -o RES
Plus gros processus : kworker, il s'agit de processus du noyau.
Changer couleur & changer colonne tri :
- Z configuration couleur : chiffre de 0 à 7 inclu pour choisir la couleur. Puis z depuis accueil de
toppour passer vers l'affichage en couleur. - f puis navigue avec les flèches et change la colonne de tri avec s. Flèche de droite pour sélectionner et bouger une colonne.
htop fourni un affichage plus complet, graphique et une navigation plus simple mais affichage plus lourd que top.
jobs: affiche les processus en coursfg: met le dernier processus qui était en background en premier planctrl + c: stop processus
fg
ctrl + c
# date-toto.sh stopped
fg
ctrl + c
# date.sh stopped
ps aux | grep date
On récupère le pid du processus puis utilise kill.
kill 345
-
date.sh : affiche à chaque seconde "date" suivi de l’heure actuelle.
-
date-toto.sh : affiche à chaque seconde "toto" suivi de l’heure actuelle d'il y a 5 heures, l’option --date permet de décrire une date avec une string.
tee permet de dupliquer les sorties, sortie standard + écriture fichier, c’est à dire qu’on peut à la fois stocker le résultat d’une commande dans un fichier (utilisation d’une pipe) et l’afficher dans la sortie standard
cat permet de lire le contenu d’un fichier et de l’afficher dans la sortie standard
ls | cat: affiche dans la sortie standard le résultat de la commandelsls -l | cat > liste: permet d’écrire dans le fichier 'liste', en écrasant les données, le résultat de la commandels -lls -l | tee liste: idem commande précédente, mais duplique la sortie : affiche dans la sortie standard et écrit dans le fichierls -l | tee liste | wc -l: idem commande précédente, mais l’affichage de la commandeteedans la sortie standard est écrasée par la pipe et ainsi on écrit dans le fichier liste le résultat de la commandels -let on affiche dans la sortie standard le résultat dewc -lappliqué au résultat dels -l
On voit donc ici l’utilité de tee, lorsque l’on utilise plusieurs pipe, on peut en cours de route écrire le résultat de la commande précédente dans un fichier tout en redirigeant ce résultat vers la sortie standard pour que la prochaine pipe puisse l’utiliser
rsyslog lancé ? :
ps aux | grep rsyslog
PID : 1252, on retrouve bien ce PID dans le fichier /var/run/rsyslogd.pid
Fichiers :
whereis rsyslog
rsyslog: /usr/lib/x86_64-linux-gnu/rsyslog /usr/lib/rsyslog /etc/rsyslog.d /etc/rsyslog.conf /usr/share/rsyslog
Messages issus des services standard : /usr/lib/x86_64-linux-gnu/rsyslog, les autres fichiers sont des fichiers de configuration.
cron : outil permettant de gérer et d’organiser l'exécution de tâches (scripts, commandes, etc...).
tail : affiche la fin du fichier passé en argument, -f permet de suivre l’évolution du fichier et d’afficher en temps réel.
Si on démarre le service cron on voit des logs apparaître:
Jan 15 17:32:29 pl-Blade systemd[1]: Stopping Regular background program processing daemon...
Jan 15 17:32:29 pl-Blade systemd[1]: Stopped Regular background program processing daemon.
Jan 15 17:32:29 pl-Blade systemd[1]: Started Regular background program processing daemon.
Jan 15 17:32:29 pl-Blade cron[20827]: (CRON) INFO (pidfile fd = 3)
Jan 15 17:32:29 pl-Blade cron[20827]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
Logrotate permet de gérer l’espace occupé par les fichiers de log, le fichier /etc/logrotate.conf permet donc de configurer ce service.
CPU : dmesg | grep -i cpu
[ 0.004000] smpboot: CPU0: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (family: 0x6, model: 0x9e, stepping: 0xa)
Carte réseaux : dmesg | grep -i intel
[ 6.195804] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 9260, REV=0x324