TP 1 : La ligne de commandes
fhh@lsv.fr
TP 01 : La ligne de commandes
Terminologie
- Interpréteur de commandes (CommandLine interpreter) :
-
logiciel qui prend des instructions en entrée et qui les exécute (interface en ligne de commandes entre nous et la machine) : EXS :
- bash :
- installé partout, quel que soit le système UNIX
- quasiment un langage de programmation (tout est une chaîne de caractères).
- zsh : très à la mode
- powershell (microsoft)
- csh : très proche du C
- sh : le plus ancien, fonctionnalités manquent (les premiers shell étaient des sh)
- python (car langage interprété)
- dash : bash en version épurée
- bash :
Intérêt : permet de chaîner les commandes (MAIS : pas performant, mieux vaut utiliser un vrai langage de programmation) rapidement
- Terminal / Console :
-
Ce qui lance l’interpréteur de commandes (interface en ligne de commandes) : fenêtre pour communiquer avec l’interpréteur de commandes.
Mode console : ctrl alt F1
Ex:
- XTerm : assez vieux, mais possède une option “SecureKeyboard” (qui protège des “KeyLogger”)
- Console : développé par KDE
Du moment qu’on sait se servir du shell, le terminal importe peu.
- Commande :
-
(Chaîne de caractères qui représente) une instruction passée à l’interpréteur de commandes.
- Shell :
-
C’est un interpréteur de commande avec un vrai langage (bash en est un, PAS python).
- Prompt :
-
Chaîne de caractère qui nous localise, qui précède la commande que l’on saisit : ex :
kaddar@09
(par abus de langage, on le confond avec l’invite de commande). - Invite de commande :
-
Ce qu’il y a après le prompt : où on tape la commande.
- Home/homedirectory :
-
Répertoire personnel de l’utilisateur :
/home/utilisateur
Ex: dans notre home
, rm -rf *
: y supprime tout.
- Root :
-
Utilisateur possédant toutes les permissions sur le système.
- Utilisateur :
-
Entité déclarée sur la machine (qui y possède un compte), appartenant à un/des groupes.
- Compte :
-
Ce qui nous permet de passer des commandes à la machine pour qu’elle les exécute.
- Login :
-
Nom de l’utilisateur pour la machine, utilisé quand on accède au système.
- Racine :
-
Base des répertoires dans la hiérarchie :
/
(on la retrouve sur tous les systèmes UNIX). - Complétion :
-
Aide à la saisie d’une commande dans un invite de commandes (presser “Tab”).
- Wildcard :
-
Caractère “joker” qui remplace n’importe quel autre. Ex:
ls a*
,ls /u*
Attention :
ls
est récursif par défaut : par défaut, affiche le contenu du répertoire.Ex :
ls M*
(si je suis dans monhome
et qu’il y a un seul dossierMusic
) liste le contenu des dossiers qui ‘match’ la description.Si on veut chercher le nom des dossier (annuler le mode récursif par défaut) :
ls -d M*
mkdir -p Test1/Test2
: création hiérarchique
ps1
: le Prompt
ps2
: le prompt de second niveau (> ...
)
echo '$LOGNAME'
⟶ $LOGNAME
echo "$LOGNAME"
⟶ kaddar
ps aux
: affiche tous les process en cours d’exécution
cat
:
Ctrl-D
: fin de fichierCtrl-C
: fin de process
cat file1 >> file1
: ne marche pas car le fichier est déjà ouvert au début de la commande.
/dev/null
: “trou noir”/poubelle : fait disparaître tout ce qui y rentre.
>
: redirige la sortie standard vers un fichier
>>
: idem, mais en mode “ajout”
|
: redirige la sortie standard vers une deuxième commande
Ex:
cat file1 >> file1
: ne marche pas (file1
déjà ouvert en lecture) MAIS :cat file1 | cat >> file1
fonctionne.file1
: refermé à la fin de la première commande (“bufferisé”)
$!
: variable contenant le dernier argument passé à une commande
esc # enter
: commenter la commande courante
.configure
: configuration du programme
make
: compilation
make -j (n+1)
sur n coeurs : plus efficace (partage de la tâche)make install
: déposer le programme
Environnement : système distribué (serveur de fichiers central divisé en plusieurs espaces réservés (home directories))
find ~/.mozilla -iname "*lock" -exec rm {} \;
⟶ mieux qu’avec un |
(find ~/.mozilla -iname "*lock" | rm
), car protège des caractères spéciaux : tout reste dans la même commande.
Negative lookahead
grep -P '^.*((?!truc_non_voulu).)*$'
Multiplexeur de terminal
On peut récupérer un terminal en cours d’un endroit à l’autre (ex: screen
, qui est ancien).
En Bash/Shell : on essaye de minimiser le nb de commandes en parallèle :
ps aux > fich1
cat fich1 | grep root
Dernière commande : PAS BIEN : grep root fich1
MIEUX :
function {
cat <<EndOfHelp
Ligne1
Ligne2
Ligne3
EndOfHelp
}
Sous Linux/UNIX : tout est fichier. ⟶ extrêmement puissant : les périphériques ne sont rien d’autre que des fichiers.
Ex :
Pour faire une image ISO d’un fichier :
- Sous Windows : on utilise un logiciel
- Sous Unix :
- Mac : on utilise
dd
: commande - OU :
cat /def/CDROM > monfichier.iso
- Mac : on utilise
Un répertoire = un fichier contenant la liste des fichiers qu’il contient.
NB : Mac = Un BSD
Pas d’extension de fichier sous Unix (complètement inutile).
Attention :
Ex :
rm -rf ~
:
- si on écrit cette commande dans
programme.txt
⟶ ouvert avec le Bloc Note
VS :
Un système Unix (utilise les ‘MIMEtype’): fait file
sur le fichier programme
, identifie l’extension, puis le lit de manière appropriée
Création d’un fichier rapide en C :
cat > Hello.c
# include <stdio.h>
int main(void) {}
gcc Hello.c
CHMOD
USER | GROUP | OTHER |
chmod 3 7 1 5 mydir
⟶ en octal
7 7 1 5
111 111 001 101
⟶ 1er octet (3, ici) : options de la deuxième ligne
u | g | o | |
---|---|---|---|
7 | 1 | 5 | |
111 | 001 | 101 | |
d |
rwx |
--x |
r-x |
7=111 | |||
s |
s |
t |
Dernière ligne :
s
(déprécié, car faille de sécurité) : les fichiers s’exécutent avec les droits de l’utilisateur qui les a créés (/!\ : root ⟶ peut être dangereux)s
: tout fichier créé dans le répertoiremydir
appartient au groupe demydir
t
: les fichiers créés ne peuvent être supprimés que par celui qui les a créés- ex: dans
/tmp
: le bitt
est activé : si je crée un fichier, je suis le seul à pouvoir le supprimer.
- ex: dans
SSH
- SSH :
-
Protocole sécurisé, parce qu’aucune donnée en circule en clair sur le réseau.
Comment se passe une connexion en SSH ?
- Le client et le serveur se mettent d’accord sur un protocole de chiffrage symétrique qu’ils vont utiliser par la suite (code de César, etc…)
- Système de clé asymétrique : divisé deux partie
- une clé publique : serrure
- une clé privée : clé (seul le propriétaire la connaît)
- Le serveur a la clé publique, et privée : la clé privée reste sur le serveur, la clé publique est donnée (elle permet de chiffrer des messages, que seul le serveur peut déchiffrer avec sa clé privée).
- Le client génère aléatoirement un mdp de 256 bits, et la chiffre avec la clé publique du serveur, puis l’envoie au serveur (qui est le seul à pouvoir la déchiffrer).
- Le client et le serveur sont les seuls à disposer du mdp : utilisent maintenant un système symétrique (créent un tunnel avec comme clé de chiffrage : le mdp).
⟹
a) Couple de clés assymétriques pour établir la connexion b) Couple de clés symétriques pour pouvoir communiquer ensemble (plus rapide que assymétrique).
NB : au moment où le client reçoit la clé publique du serveur, il reçoit une empreinte, qu’il stocke dans le fichier
known_host
Pq ? Un hacker peut donner sa propre clé publique au client, et intercepter les messages entre le client et le serveur, en passant par le hacker.
MAIS : Si le client a l’empreinte de la première clé reçue (celle du hacker), la prochaine fois qu’il se connecte avec le serveur, il peut se rendre compte d’un changement de clé (le serveur a TOUJOURS la même paire (clé publique, clé privée)).
NB :
-
Comme le hacker change sa clé publique tout le temps, on devrait, à chaque première connexion, se déconnecter et se reconnecter pour vérifier que l’empreinte n’a pas changé (si c’est le cas, on est hacké).
-
Un empreinte identifie une paire (clé publique, clé privée).
M2 :
Une fois le tunnel avec “mdp” créé :
ssh toto@ssh.dptinfo.ens-cachan.fr
: on se connecte, le protocole d’échange public est établi, le client calcule le fingerprint de la clé publique ⟶ si c’est la première fois, demande au client “Voulez-vous enregistrer cette empreinte dans votre fichier known_host
?”
Si oui : on envoie le notre password perso au serveur.
ssh-keygen
: crée notre propre couple de clés (publique, privée) unique.
Sur le serveur :
authorized_keys
: contient tout un tas de clés publiques : on passe, la première fois, notre clé publique (serrure) au serveur (avec login et password), qui peut nous reconnaître désormais avec notre clé privée (clé).
⟹ plus besoin de réutiliser notre password perso ! Notre clé publique nous identifie, auprès du serveur.
ssh-agent
: stocke en mémoire nos clés privées (trousseau), pour nous identifier sur les serveurs sans ressaisir à chaque fois login/password pour chaque serveur.
-
sshuttle
: VPN en SSH ⟶ on peut faire du SSH depuis n’import où avec les outils standards On lance un VPN pour se connecter à un serveur de l’ENS, par ex. -
sshfs
(file system) : permet de monter son répertoire distant en local.
Faire sshfs
de notre home
sur notre machine : on l’a en local !
git
: hyper intégré avec ssh.
Redirection de port VS pivot :
- Avec la redirection de port : on peut rediriger le port 80 de l’ENS Cachan vers le port 3128 (par ex) à l’ENS Lyon, pour accéder au réseau local de Cachan.
Fonctionnement d’un proxy
Se met entre le client et le serveur ⟶ stocke les fichiers .js
pour les mettre en cache entre les clients.
⟹ plus la même adresse ip publique (mais ne marche pas avec protocoles sécurisés : ne laissent pas passer)
Leave a comment