Changes for page How to set up a gitea docker instance

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -199,3 +199,45 @@
199	199
200	200	Copy its contents and add it to your Gitea's user settings through the web interface, as follows:
201	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	+Please do note that registering the git user's public key has to be done using the above commands **AND NOT THROUGH THE WEB INTERFACE, LIKE IN THE PREVIOUS STEP** (I already lost 2 days investigating why this thing didn't work because I didn't pay attention to this step)
	227	+
	228	+== Write an SSH Shim script ==
	229	+
	230	+Here, we'll need to generate a script at "/usr/local/bin/gitea" owned by root:root and with chmod 755 with the following contents:
	231	+
	232	+{{code language="bash"}}
	233	+#!/bin/sh
	234	+ssh -p 2200 -o StrictHostKeyChecking=no git@127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@"
	235	+{{/code}}
	236	+
	237	+This script might seem confusing, at first glance, especially since there's another, entirely different "/usr/local/bin/gitea" script that exists in the docker container.
	238	+
	239	+The script above will simply forward all incoming SSH connections that originally came to the host server and sends them to the docker container (specifically to localhost port 2200 which, according to the yaml file above, is mapped to port 22 inside the container). There, the container will run the command that was originally sent to the host machine inside of itself and return the result to the original outside client.
	240	+
	241	+You may be thinking "But how does the host SSH server know when to run this script to forward requests inside the container and when not to forward requests?". Basically, this is done via the /home/git/.ssh/authorized_keys file.
	242	+
	243	+When we added all those public keys at step [[Guides/How%20to%20set%20up%20a%20gitea%20docker%20instance/#HGenerateaproperpublic2FprivatekeypairforalltheaccountsthatneedtousegitviaSSHwith]]