-
Notifications
You must be signed in to change notification settings - Fork 46
/
Copy pathsetting-up-server.asc
148 lines (121 loc) · 6.58 KB
/
setting-up-server.asc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
[[s_setting_up_server]]
=== Mise en place du serveur
Parcourons les étapes de la mise en place d'un accès SSH côté serveur.
Dans cet exemple, vous utiliserez la méthode des `authorized_keys` pour authentifier vos utilisateurs.
Nous supposerons également que vous utilisez une distribution Linux standard telle qu'Ubuntu.
[NOTE]
====
Une bonne partie de ce qui est décrit ici peut être automatisé en utilisant la commande `ssh-copy-id`, plutôt que de copier et installer manuellement les clés publiques.
====
Premièrement, créez un utilisateur 'git' et un répertoire `.ssh` pour cet utilisateur.
[source,console]
----
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
----
Ensuite, vous devez ajouter la clé publique d'un développeur au fichier `authorized_keys` de l'utilisateur Git.
Supposons que vous avez reçu quelques clés par courriel et les avez sauvées dans des fichiers temporaires.
Pour rappel, une clé publique ressemble à ceci :
[source,console]
----
$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
----
Il suffit de les ajouter au fichier `authorized_keys` de l'utilisateur `git` dans son répertoire `.ssh` :
[source,console]
----
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
----
Maintenant, vous pouvez créer un dépôt vide nu en lançant la commande `git init` avec l'option `--bare`, ce qui initialise un dépôt sans répertoire de travail :(((commandes git, init, bare)))
[source,console]
----
$ cd /opt/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /opt/git/project.git/
----
Alors, John, Josie ou Jessica peuvent pousser la première version de leur projet vers ce dépôt en l'ajoutant en tant que dépôt distant et en lui poussant une branche.
Notons que quelqu'un doit se connecter par shell au serveur et créer un dépôt nu pour chaque ajout de projet.
Supposons que le nom du serveur soit `gitserveur`.
Si vous l'hébergez en interne et avez réglé le DNS pour faire pointer `gitserveur` sur ce serveur, alors vous pouvez utiliser les commandes suivantes telles quelles (en supposant que `monprojet` est un projet existant et comprenant des fichiers) :
[source,console]
----
# Sur l'ordinateur de John
$ cd monproject
$ git init
$ git add .
$ git commit -m 'première validation'
$ git remote add origin git@gitserveur:/opt/git/projet.git
$ git push origin master
----
À présent, les autres utilisateurs peuvent cloner le dépôt et y pousser leurs modifications aussi simplement :
[source,console]
----
$ git clone git@gitserveur:/opt/git/projet.git
$ cd projet
$ vim LISEZMOI
$ git commit -am 'correction du fichier LISEZMOI'
$ git push origin master
----
De cette manière, vous pouvez rapidement mettre en place un serveur Git en lecture/écriture pour une poignée de développeurs.
Il faut aussi noter que pour l'instant tous ces utilisateurs peuvent aussi se connecter au serveur et obtenir un shell en tant qu'utilisateur « git ».
Si vous souhaitez restreindre ces droits, il faudra changer le shell pour quelque chose d'autre dans le fichier `passwd`.
Vous pouvez simplement restreindre l'utilisateur 'git' à des actions Git avec un shell limité appelé `git-shell` qui est fourni avec Git.
Si vous configurez ce shell comme shell de login de l'utilisateur 'git', l'utilisateur 'git' ne peut pas avoir de shell normal sur ce serveur.
Pour utiliser cette fonction, spécifiez `git-shell` en lieu et place de bash ou csh pour shell de l'utilisateur.
Pour faire cela, vous devez d'abord ajouter `git-shell` à `/etc/shells` s'il n'y est pas déjà :
[source,console]
----
$ cat /etc/shells # voir si `git-shell` est déjà déclaré. Sinon...
$ which git-shell # s'assurer que git-shell est installé sur le système
$ sudo vim /etc/shells # et ajouter le chemin complet vers git-shell
----
Maintenant, vous pouvez éditer le shell de l'utilisateur en utilisant `chsh <utilisateur> -s <shell>` :
[source,console]
----
$ sudo chsh git -s $(which git-shell)
----
À présent, l'utilisateur 'git' ne peut plus utiliser la connexion SSH que pour pousser et tirer sur des dépôts Git, il ne peut plus ouvrir un shell.
Si vous essayez, vous verrez un rejet de login :
[source,console]
----
$ ssh git@gitserveur
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserveur closed.
----
Ici, les utilisateurs peuvent encore utiliser le transfert de port de SSH pour accéder à n'importe quel hôte que le serveur git est capable d'accéder.
Si vous voulez l'empêcher, vous pouvez éditer le fichier `authorized_keys` et préfixer les options suivantes à toutes les clé que vous souhaitez restreindre :
[source,console]
----
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
----
Le résultat devrait ressembler à ceci :
[source,console]
----
$ cat ~/.ssh/authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
ICUvax2T9va5 gsg-keypair
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...
----
Maintenant, les commandes réseau Git continueront de fonctionner correctement mais les utilisateurs ne pourront plus obtenir de shell.
Comme la sortie l'indique, vous pouvez aussi configurer un répertoire dans le répertoire personnel de l'utilisateur « git » qui va personnaliser légèrement le `git-shell`.
Par exemple, vous pouvez restreindre les commandes Git que le serveur accepte ou vous pouvez personnaliser le message que les utilisateurs verront s'ils essaient de se connecter en SSH comme ci-dessus.
Lancer `git help shell` pour plus d'informations sur la personnalisation du shell.(((commandes git, help)))