Skip to Content
Last modified by Alexandru Pentilescu on 2024/07/16 22:44
From version 5.1
edited by Alexandru Pentilescu
on 2024/07/16 21:18
Change comment: There is no comment for this version
To version 14.1
edited by Alexandru Pentilescu
on 2024/07/16 22:16
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -107,3 +107,120 @@
107 107  {{code language="bash"}}
108 108  systemctl restart nginx
109 109  {{/code}}
110 +
111 +Confirm that the web page is accessible at the git.transistor.one URL. In case it's not, fix it.
112 +
113 +# Customize Gitea configuration #
114 +
115 +Assuming you do need to change a couple of settings, gitea will have generated a configuration file at ./data/gitea/conf/app.ini.
116 +
117 +Make whatever changes you need to make in this file.
118 +
119 +The changes will take effect only after stopping and restarting the container, though.
120 +
121 +Notable changes that are worth mentioning is setting up an SMTP endpoint:
122 +
123 +{{code language="ini"}}
124 +[mailer]
125 +ENABLED = true
126 +PROTOCOL = smtp+starttls
127 +HOST = mail.transistor.one:587
128 +FROM = gitea@transistor.one
129 +USER =
130 +PASSWD =
131 +{{/code}}
132 +
133 +And, of course, the server hostname configuration:
134 +
135 +{{code language="ini"}}
136 +[server]
137 +APP_DATA_PATH = /data/gitea
138 +DOMAIN = transistor.one
139 +SSH_DOMAIN = transistor.one
140 +HTTP_PORT = 3000
141 +ROOT_URL = https://git.transistor.one/
142 +DISABLE_SSH = false
143 +SSH_PORT = 22
144 +SSH_LISTEN_PORT = 22
145 +{{/code}}
146 +
147 +Oh and, almost forgot, disable user registrations by setting
148 +
149 +{{code language="ini"}}
150 +[service]
151 +DISABLE_REGISTRATION = true
152 +{{/code}}
153 +
154 +If you need more configuration information, check [[this>>https://docs.gitea.com/administration/config-cheat-sheet]] out.
155 +
156 += Activating SSH passthrough =
157 +
158 +This is the most complex step out of all of them. In order to take advantage of the fact that SSH git pulls/pushes will be done via standard port 22, normal SSH traffic needs to be differentiated from git specific SSH traffic.
159 +
160 +To this end, multiple configurations will need to be done.
161 +
162 +This one's extremely important. Failing to perform this step will make SSH git pulls and pushes require to be done directly from the 2200 port like so
163 +
164 +{{code language="bash"}}
165 +git clone ssh://git@transistor.one:2200/Alex/Licenta.git
166 +{{/code}}
167 +
168 +While this isn't the end of the world, ideally, all SSH traffic should be routed to port 22, as is standard. VPS firewalls or intermediary ISPs may, themselves, block off incoming or outgoing traffic to unconventional ports, which can cause issues. As such, using the standard port 22 for SSH communication would be ideal.
169 +
170 +== Enable SSH login for the git user ==
171 +
172 +So, to enable SSH capabilities to the git user, please edit the "/etc/ssh/sshd_config" configuration and change the following line:
173 +
174 +{{code language="text"}}
175 +AllowUsers alex git
176 +{{/code}}
177 +
178 +Obviously the "alex" user doesn't need to be here. The git user does. Change this list as best suits your needs. Don't forget to restart the service after you're done:
179 +
180 +{{code language="bash"}}
181 +systemctl restart ssh
182 +{{/code}}
183 +
184 +== Generate a proper public/private keypair for all the accounts that need to use git via SSH with ==
185 +
186 +This part's pretty self explanatory.
187 +
188 +For each user, on each device, that will require SSH git access to the aforementioned git server, they will need to have their own public/private authentication keypair set under a Gitea user that's already registered on the Gitea web portal.
189 +
190 +Check to see if a public/private keypair doesn't already exist under your user's /home/<username>/.ssh/ directory. You'll recognize already existent keypairs by the presence, in this directory, of <name>.pub files. If you already have at least one such file already there, copy the contents of the <name>.pub file to the clipboard and add it to your Gitea user's settings. In case there is no such .pub file already existent, you'll have to manually generate ones for yourself.
191 +
192 +To do so, simply log into each user and run from the terminal:
193 +
194 +{{code language="bash"}}
195 +ssh-keygen
196 +{{/code}}
197 +
198 +That's pretty much it. Once you generated a keypair, again, visit the /home/<username>/.ssh/ directory and check for <name>.pub files. There should be at least one there, now.
199 +
200 +Copy its contents and add it to your Gitea's user settings through the web interface, as follows:
201 +[[image:1.png]][[image:2.png]][[image:3.png]]
202 +
203 +Once the public key is registered here, you should be able to do git push and git pull from this particular repository using SSH, without the need for further authentication. However, there's still a couple more steps left to follow:
204 +
205 +== Generate a public/private keypair for the git user as well ==
206 +
207 +This might not be immediately obvious why this is necessary, but in order for the SSH passthrough to work, the git user that we'll log into in the future will have to forward all SSH requests to inside the docker container. In order to do so, the container's own SSH server will need to recognize the requests as authenticated from the git user on the host machine.
208 +
209 +To this end, we will have to generate a keypair for the git user as well:
210 +
211 +{{code language="bash"}}
212 +sudo -u git ssh-keygen -t rsa -b 4096 -C "Gitea Host Key"
213 +{{/code}}
214 +
215 +Once this part is done register the newly generated public key to the SSH server inside the docker container, by appending it to the /home/git/.ssh/authorized_keys files inside the host.
216 +
217 +To do so, please do:
218 +
219 +{{code language="bash"}}
220 +sudo -u git cat /home/git/.ssh/id_rsa.pub | sudo -u git tee -a /home/git/.ssh/authorized_keys
221 +sudo -u git chmod 600 /home/git/.ssh/authorized_keys
222 +{{/code}}
223 +
224 +You might wonder why we're changing a file on the host filesystem and not inside the docker, where the relevant SSH service is running. The reason for this is, remember, this particular directory is already mapped in our docker-compose.yml file, so it exists in both the host machine and in the docker container, simultaneously. All changes that take place to it on the host will reflect inside the container.
225 +
226 +
1.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.AlexandruPentilescu
Size
... ... @@ -1,0 +1,1 @@
1 +285.4 KB
Content
2.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.AlexandruPentilescu
Size
... ... @@ -1,0 +1,1 @@
1 +589.7 KB
Content
3.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.AlexandruPentilescu
Size
... ... @@ -1,0 +1,1 @@
1 +635.2 KB
Content