You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If localhost or 127.0.0.1 is used for the SSH/Gitolite server host setting (i.e. Git and Redmine are hosted on the same server), then during creation of a new repo, the repo gets created normally, and shows up in Git. However, the second half of this process (that is, initializing the repo with a readme.md) seems to be trying to ssh git@<external_ip> . If SSH access from the Redmine user via the external IP happens to be blocked for one reason or another, then Redmine Git Hosting can't initialize the repo.
For example, when Git and Redmine are on the same server, if the <external_ip> for <hostname> is in error in /etc/hosts, you will see this problem.
Or if different sshd_config rules are in place for external IP vs localhost SSH connections (such as different port numbers, or stricter non-compatible key exchange algorithms ), then gitolite-rugged will also be unable to complete the second SSH connection to initialize the repo.
This is related to redmine-git-hosting/gitolite-rugged#3. If I didn't have to stand up a separate sshd daemon just for gitolite-rugged's inability to use diffie-hellman-group-exchange-sha256, I would not see this differing behavior internal to the script.
However, I also saw this behavior earlier when the external ip was incorrect in our /etc/hosts, but correcting this solved the issue temporarily, because at that time, it was acceptable to have the internal service momentarily use the external IP.
Output of git_hosting.log
...
2016-07-21 12:18:04 -0700 [INFO] User 'admin' created a new repository 'llama-face'
2016-07-21 12:18:04 -0700 [INFO] Accessing gitolite-admin.git at '/tmp/redmine_git_hosting/git/gitolite-admin.git'
2016-07-21 12:18:05 -0700 [INFO] add_repository : repository 'llama-face' does not exist in Gitolite, create it ...
2016-07-21 12:18:05 -0700 [INFO] add_repository : commiting to Gitolite...
2016-07-21 12:18:05 -0700 [INFO] add_repository : let Gitolite create empty repository 'repos/llama-face.git'
2016-07-21 12:18:06 -0700 [INFO] Execute Gitolite Plugins
2016-07-21 12:18:06 -0700 [INFO] Create README file for repository 'llama-face'
2016-07-21 12:18:06 -0700 [ERROR] Error while creating README file for repository 'llama-face'
2016-07-21 12:18:06 -0700 [ERROR] Failed to start SSH session: Unable to exchange encryption keys
As you can see, this one failed because using the external IP for the connection forced gitolite-rugged to try to use diffie-hellman-group-exchange-sha256, which apparently doesn't work.
/etc/hosts:
127.0.0.1 localhost
<externalip> <hostname> #can't change this
Just a guess, but perhaps the script for the setup is using the SSH/Gitolite server host variable (set to 127.0.0.1), while the script for initializing/syncing is using SSH server domain (which is set to the <hostname> and so resolves to the <external_IP>).
The text was updated successfully, but these errors were encountered:
If
localhost
or127.0.0.1
is used for theSSH/Gitolite server host
setting (i.e. Git and Redmine are hosted on the same server), then during creation of a new repo, the repo gets created normally, and shows up in Git. However, the second half of this process (that is, initializing the repo with areadme.md
) seems to be trying tossh git@<external_ip>
. If SSH access from the Redmine user via the external IP happens to be blocked for one reason or another, then Redmine Git Hosting can't initialize the repo.For example, when Git and Redmine are on the same server, if the
<external_ip>
for<hostname>
is in error in/etc/hosts
, you will see this problem.Or if different
sshd_config
rules are in place for external IP vs localhost SSH connections (such as different port numbers, or stricter non-compatible key exchange algorithms ), then gitolite-rugged will also be unable to complete the second SSH connection to initialize the repo.This is related to redmine-git-hosting/gitolite-rugged#3. If I didn't have to stand up a separate sshd daemon just for gitolite-rugged's inability to use
diffie-hellman-group-exchange-sha256
, I would not see this differing behavior internal to the script.However, I also saw this behavior earlier when the external ip was incorrect in our /etc/hosts, but correcting this solved the issue temporarily, because at that time, it was acceptable to have the internal service momentarily use the external IP.
Output of git_hosting.log
As you can see, this one failed because using the external IP for the connection forced gitolite-rugged to try to use diffie-hellman-group-exchange-sha256, which apparently doesn't work.
/etc/hosts:
Just a guess, but perhaps the script for the setup is using the
SSH/Gitolite server host
variable (set to 127.0.0.1), while the script for initializing/syncing is usingSSH server domain
(which is set to the<hostname>
and so resolves to the<external_IP>
).The text was updated successfully, but these errors were encountered: