I'm getting a connection to my gerrit server through SSH.
ssh -p 29418 fredrik#localhost
gives me this output
**** Welcome to Gerrit Code Review ****
Hi Fredrik Pettersson, you have successfully connected over SSH.
Unfortunately, interactive shells are disabled.
To clone a hosted Git repository, use:
git clone ssh://fredrik#fredrik-VirtualBox:29418/REPOSITORY_NAME.git
Connection to localhost closed.
So it seems to me that I have a connection to gerrit. But I can't create a repo...
When executing the command
ssh -p 29418 fredrik#localhost gerrit create-project --name projects/project_name
I'm getting the error message
create project not permitted
What can be the reason for this?
You need to have "Create Project" permission on Gerrit.
See more info in the Gerrit documentation here.
Related
Error message
After having added the ssh key of a user of a GitLab server and repository that is hosted over tor, a test was performed that tried to clone a private repository (to which the testing user is added) over tor. The cloning was attempted with command:
torsocks git clone git#some_onion_domain.onion:root/test.git
Which returns error:
Cloning into 'test'... 1620581859 ERROR torsocks[50856]: Connection
refused to Tor SOCKS (in socks5_recv_connect_reply() at socks5.c:543)
ssh: connect to host some_onion_domain.onion port 22: Connection
refused fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository
exists.
GitLab SSH Cloning Verification
However, to verify the ssh access is available to the test user, the cloning was verified without tor using command:
git clone git#127.0.0.1:root/test.git
Which successfully returned:
Cloning into 'test'... remote: Enumerating objects: 3, done. remote:
Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused
0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done.
Server side hypothesis
My first guess is that it is a server-side issue that has to do with the lack of https, in following setting in the /etc/gitlab/gitlab.rb file:
external_url 'http://127.0.0.1'
However setting external_url 'https://127.0.0.1 requires an https certificate, e.g. from Let's encrypt, which seem to not be provided for onion domains.
Client-side hypothesis
My second guess would be that it is a client-side issue related to some SOCKS setting is incorrect at the test user side that runs the torsocks command, similar to an issue w.r.t. the SOCKS 5 protocol that seems to be described here.
Question
Hence I would like to ask:
How can I resolve the connect to host some_onion_domain.onion port 22: Connection refused error when users try to clone the repo over tor?
One can set the ssh port of the GitLab instance to 9001, e.g. with:
sudo docker run --detach \
--hostname gitlab.example.com \
--publish 443:443 --publish 80:80 --publish 22:9001 \
--name gitlab \
--restart always \
--volume $GITLAB_HOME/config:/etc/gitlab \
--volume $GITLAB_HOME/logs:/var/log/gitlab \
--volume $GITLAB_HOME/data:/var/opt/gitlab \
gitlab/gitlab-ee:latest
Next, add port 9001 and port 22 to the ssh configuration in /etc/ssh/sshd_config by adding:
Port 9001
Port 22
then restart the ssh service with: systemctl restart ssh.
It is essential that one adds a public ssh key to the GitLab server for each computer you want to download the repo from, even if one wants to clone a public repository. You can make a new GitLab account for each computer, or add multiple public ssh keys to a single GitLab account. These instructions explain how to do that, tl;dr
ssh-keygen -t ed25519
<enter>
<enter>
<enter>
systemctl restart ssh
xclip -sel clip < ~/.ssh/id_ed25519.pub
Ps. if xclip does not work, one can manually copy the ssh key with: cat ~/.ssh/id_ed25519.pub.
Then open a browser and go to https://gitlab.com/-/profile/keys so for your own tor GitLab server that would be: someoniondomain.onion/-/profile/keys, and copy paste that key in there.
That is it, now one can clone the repository over tor with:
torify -p 22 git clone ssh://git#someoniondomain.onion:9001/root/public.git
Note
As a side note, in the question I happened to have tested git clone git#127.0.0.1:root/test.git however, instead of using 127.0.0.1 I should have used either the output of hostname -I or the public ip address of the device that hosts the GitLab server. Furthermore, I should have verified whether the GitLab server was accessible through ssh by testing:
ssh -T git#youronionserver.onion
Which should return Congratulations... It would not have done so if I had tested that, indicating the problem was in the ssh access to the GitLab server (or the ssh connection to the device). I could have determined whether the ssh problem was with the device or the ssh server by testing if I could log into the device with: ssh deviceusername#device_ip, which would have been successfull indicating, the ssh problem with at the GitLab server.
I'm trying to create a node on a remote host(I've already created a domain).
I'm running the command:
asadmin -p <port_number> create-node-ssh --nodehost <remote_hostname> --installdir <glassfish_installed_dir_path> <node_name>
and getting the following error everytime:
remote failure: Warning: some parameters appear to be invalid.
SSH node not created. To force creation of the node with these parameters rerun the command using the --force option.
Could not connect to host <hostname> using SSH.
There was a problem while connecting to <hostname>:22
Key exchange was not finished, connection is closed.
Command create-node-ssh failed.
From the error it seems that there is some connection problem. But I can ssh to the target server and I'm using the same key_pair.
After searching for some solution (link1, link2) I found that trying to login through ssh without password could solve this.
But no luck. Now I can ssh to & from the target server without password as well. But this issue is still there.
What should I check for, in order to resolve this ?
Let me know if I'm missing out anything.
Can you try to start sshd daemon in debug mode to a different port at the remote node host:
sudo sshd -D -d -e -p 23
and try create-node-ssh command against that ssh port?:
asadmin -p <port_number> create-node-ssh --nodehost <remote_hostname> --installdir <glassfish_installed_dir_path> --sshport 23 <node_name>
I had an issue regarding glassfish ssh exchange keys because of ssh newer versions deprecating older algorithms:
Unable to negotiate with X.X.X.X port XXXXX: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
My solution was to add legacy keys to /etc/ssh/sshd_config:
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc
Even if this is not your case, sshd debug will surelly give you more information.
I've just updated my TortoiseGit from v1.7.* to v1.8.15.0 and Git from 1.* to v2.5.0.windows.1. Now trying to perform a remote operation like pull I'm getting errors:
git.exe pull -v --progress "origin"
Unable to open connection: Host does not existfatal: Could not read
from remote repository.
Please make sure you have the correct access rights and the repository
exists.
git did not exit cleanly (exit code 1) (1747 ms # 19.08.2015 18:43:33)
I changed the SSH client setting from TortoiseGitPlink to PuTTY. It didn't work as well, but the PuTTY Error provided following information:
Unuble to open connection to github.com-foo
Host does not exist
I work with aliases and my ~/.ssh/config looks like this:
#github.com-foo account
Host github.com-foo
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa_foo
#github.com-bar account
Host github.com-bar
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa_bar
That worked before the upgrade and is still working in msys.
TortoiseGit seems to ignore the config. How to make TortoiseGit respect the config again?
PuTTY and TortoiseGitPlink do not respect .ssh/config (as described in e.g. Multiple GitHub Accounts & SSH Config or https://gist.github.com/jexchan/2351996). Both tools store, like Windows tools, their configuration in registry.
For using PuTTY in your scenario, please see the TortoiseGit Manual - Tips and tricks for SSH/PuTTY.
PS: .ssh/config is the config file for OpenSSH. If you want to use OpenSSH, set the ssh client to ssh.exe in TortoiseGit network settings (there is no need to use the full path to ssh.exe as it is on the %PATH%):
I have already installed node.js(v0.10.30) and npm. I'm able to establish a SSH connection between my mac and dreamhost VPS via terminal, but i cant do it in Cloud9. Someone help me, please?
./server.js -p 8080 -l 0.0.0.0 -a :
--settings Settings file to use
--help Show command line options.
-t Start in test mode
-k Kill tmux server in test mode
-b Start the bridge server - to receive commands from the cli [default: false]
-w Workspace directory
--port Port
--debug Turn debugging on
--listen IP address of the server
--readonly Run in read only mode
--packed Whether to use the packed version.
--auth Basic Auth username:password
--collab Whether to enable collab.
--no-cache Don't use the cached version of CSS
So you can use your own VPS,just change 0.0.0.0 to your server ip.
Using a fresh Gitlab install, generated and added SSH keys to the user account, created a new project.
From a local machine, created one (1) folder, added a readme and preformed the following from the terminal:
git init
git add README
git commit -m '1_16_2013'
git remote add origin git#192.168.1.55:root/test.git
git push -v origin master
The push asks for the git#192.168.1.55's password and returns:
Connection closed by 192.168.1.55
fatal: The remote end hung up unexpectedly
Do I need to add a shh key to my local machine?
You need to have the public and private keys (id_rsa and id_rda.pub) stored on your ~/.ssh directory of your local machine.
Otherwise, any ssh to the gitlab server will ask for a password.
You also need to use the right ssh address:
git#192.168.1.55:test.git
You shouldn't have any path in front of the name of the git repo: gitolite (used by GitLab) will detect the name of the repo and will use the right repo path.
I prefer storing this information (server name, ssh user, private key...) in a ~/.ssh/config file: see "gitolite: can connect via ssh, can't clone" as an example (or "git clone git#myserver:gitolite-admin fails").