I have added an ecdsa-sha2-nistp256 SSH public key to my user account on a self-hosted GitLab instance. The same public key is used without issue on other services like GitHub.
When I try to clone any repo over SSH (git clone git#gitlab.local:user/project.git), including my own repos I am absolutely an owner of, I can see that the server accepts the public key:
debug1: Offering public key: ecdsa-sha2-nistp256 ECDSA SHA256:LL8b...Onco agent
debug1: Server accepts key: ecdsa-sha2-nistp256 ECDSA SHA256:LL8b...Onco agent
But the connection is immediately terminated and the clone aborted.
I've confirmed that ECDSA keys are enabled on the server, and that I'm connecting to the right server. Removing the public key from my profile results in a different error, so I know that (a) the server's authorized_keys setup is working, and (b) there isn't another user without repo privileges that I'm getting logged in as.
The issue seemed to be that /etc/pam.d/sshd had been modified in a way that prevented authentication.
We added the following to the top of the file:
# local user 'git' needs to be allowed
account sufficient pam_localuser.so
If the GitLab logs don't show any additional clue, I would start the ssh daemon on the server in debug mode: sshd -d
That will trigger a one-time interactive session, where you can see if your client SSH query:
arrives to the server
triggers any error message.
Related
I have a staging server and a production server, and I run identical Bitbucket Pipelines, where I send some commands over SSH. Unfortunately, my pipeline for the production always fails with:
Host key verification failed.
I've tried everything, folder permissions, recreating the keys, nothing works.
Finally with adding -v to my ssh call, I think I'm a step closer, but still lost.
On my staging server, I see something like this:
debug1: Host '$STAGING_SERVER' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
and the rest of the build follows flawlessly.
On my production server, however, I see the following:
debug1: Host '$PRODUCTION_SERVER' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:5
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: permanently_drop_suid: 0
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Host key verification failed.
So it would look like the key is found on my production server, but for some reason on the production server read_passphrase is being called. I've just created a new id_rsa and id_rsa.pub key, with no password, so why the heck is my production server trying to call read_passphrase? My ssh_config and sshd_config on both servers are identical - checked via diff.
Another way of looking at it is that ssh_rsa_verify is called immediately on the staging server, while on the production server read_passphrase is called.
Any help here would be greatly appreciated, this is driving me crazy!
Hallelujah! Solved! 🥳
Hours wasted for the simplest reason...
I noticed in the full output of the ssh -v on production that Bitbucket was printing out something like this:
debug1: Connecting to $PRODUCTION_SERVER [12.345.567.890] port 22.
where as the staging output was:
debug1: Connecting to $STAGING_SERVER [$STAGING_SERVER] port 22.
Meaning the static IP was the exact value of that repository variable. (Bitbucket parses secret logs out, which is why they appear this way).
I realized I had set the repository variable PRODUCTION_SERVER incorrectly to the alias for the IP address, (i.e. myserver.com) when it should be the IP address exactly. Changing that value in my repository variables to the IP address fixed the issue! Apparently, using the alias name isn't a perfect enough match for SSH to be satisfied.
I had the same issue. I solved this problem by
go to -> Repository settings
go to -> SSH keys ( on the left navigation)
at the known hosts section
input your Bastion host public IP address
then click Fetch button
rerun your pipeline
Please check this for reference
I've recently set up a new GitLab docker container, and though everything else has been working great I can't authenticate to it via ssh.
I followed the instructions here to the letter, with no succes.
Whatever key type I generate, and regardless of the client (Linux, Windows git-bash), The server instantly rejects the publickey and does not prompt for a password.
Debug shows the following:
debug1: Offering public key: /c/Users/[user]/.ssh/id_ed25519 ED25519 SHA256:[SHA-256]
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
Maybe it's something obvious, but I can't quite figure it out and no troubleshooting step managed to help.
As a side note, the ssh port is non standard, though I am accesing via the new port. I've also double checked ssh is enabled on both the server and the clients.
Any help would be greatly appreciated.
Thanks!
Check first if this is similar to gitlab-org/gitlab-foss issue 18371 "docker omnibus gitlab denying ssh public key"
In my case the problem was mismatch between ssh socket that docker container was exposing and my server's one.
It helped to expose it on different port like 10022 and reconfiguring gitlab like this:
gitlab_rails['gitlab_shell_ssh_port'] = 10022
Ideally, you would need to stop, restart the ssh daemon (server side, container side as seen in this thread) with
usr/sbin/sshd -d
That would allow you to check:
if the SSH request is received at all
if it is blocked for any reason
I am trying to SSH into the server as part of the deployment job in CircleCI
ssh -oStrictHostKeyChecking=no $DEV_DROPLET_USER#$DEV_DROPLET_IP
I have my SSH private key for the user on this server loaded into CircleCI but everytime I run the job, I get this output
Warning: Permanently added '$host' (ECDSA) to the list of known hosts.
<$user>#<$host>'s password:
How can I stop it prompting me for the password?
I have added the SSH key for this user to the SSH Agent on the server (these instructions)
For a passwordless ssh connection, you must:
put the private ssh key into a file in the directory $HOME/.ssh/ on the client computer connecting to the server (example : $HOME/.ssh/MyServer)
copy the public ssh key into the file $HOME/.ssh/authorized_keys on the server
have writing permission on the file $HOME/.ssh/known_hosts on the client computer
The sshd service is normally already configured to accept key based authentication.
From the client computer, you can now do a passwordless connection ssh -i $HOME/.ssh/MyServer $DEV_DROPLET_USER#$DEV_DROPLET_IP
Of course, on the client computer your $DEV_DROPLET_USER must have appropriate permissions for accessing the ssh related files.
You don’t need to do anything with the ssh agent, on the client or on the server.
Late reply, but I hope it helps somebody else in the future.
Assuming you followed these instructions in the CircleCI docs, then the private key will automatically be copied to the machine being used by CircleCI when the add_ssh_keys step is run.
Make sure one the server you are trying to SSH into, the public key generated (in ~/.ssh/id_rsa.pub or something similar) is copied to the ~/.ssh/authorized_hosts file on the same server. This crucial step is what allows anybody with the private key (CircleCI) to be allowed into the server.
I'm having a problem; git returns this alert:
The authenticity of host 'bitbucket.org (104.192.143.2)' can't be established.
RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1
Are you sure you want to continue connecting (yes/no)?
When I choose yes, it returns this:
Warning: Permanently added 'bitbucket.org,104.192.143.2' (RSA) to the list of known hosts.
ssh_packet_read: Connection closed
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
What is the problem?
Where must I add the RSA number? Please, I'm desperate. :(
The authenticity of host 'bitbucket.org (104.192.143.2)' can't be established. RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1 Are you sure you want to continue connecting (yes/no)?
This is normal and it's safe to say yes. ssh is being overly paranoid by asking you to confirm it. You can turn it off by setting StrictHostKeyChecking to no in your ssh config.
Remembering the public key of each server you connect to is a security feature of ssh to protect you from a man-in-the-middle attack. It goes something like this:
The first time you ssh to a host its public key (that's all that SHA256:zzXQ... stuff) is remembered, usually in ~/.ssh/known_hosts.
Every time thereafter ssh will check that the same host is still using the same key. This authenticates that bitbucket.org is still the same server you were talking to the first time.
If the keys don't match it could mean one of two things. First is that the server admin reinstalled their ssh server and forgot to keep the same key. This is common for small sites, but unlikely for something like bitbucket.org.
The second possibility is that the ssh server has been hijacked. It doesn't matter how. One common way is for a rogue DNS server to return their own malicious IP address instead of the real address for bitbucket.org. Common enough on public wifi connections.
As for why it won't connect after confirming, it's right there in the error message.
$ git clone git#bitbucket.org:RobeJablonski/sda-robert.git
Cloning into 'sda-robert'...
conq: repository access denied.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
The repository exists, that can be verified, so you don't have access rights (neither do I). Bitbucket determines who you are using your ssh key. This means you're not logging in with the right key. It has to be the same key as is associated with your account on BitBucket.
You can find your BitBucket ssh keys in your Bitbucket settings under https://bitbucket.org/account/user//ssh-keys/. Then you have to check if ssh is using that key. You can check what it's using using ssh -v git#bitbucket.org. It will spew out a lot of stuff but you're looking for the last instance of debug1: Offering RSA public key: /Users/blah/.ssh/blah.
Once you find that, check if /Users/blah/.ssh/blah.pub matches what BitBucket thinks your ssh key is. If they don't match, then you'll have to find the matching key and configure ssh to use that key for bitbucket.org.
If you've lost the key, you should change your ssh key on bitbucket.org.
Make sure you have followed below steps in your application server:
Have you created public key:
cd ~/.ssh/
To generate keygeneration:
ssh-keygen
Copy public key value (NOT PRIVATE KEY)
cat ~/.ssh/id_rsa.pub
Install git :
sudo apt install git
ATLASSIAN SETUP :
SETTINGS -> Access keys -> Add key
https://bitbucket.org/compassitesinc/your-repository/admin/access-keys/
Make sure your email address added to the User group (with admin permission)
SETTINGS -> User and group access
Add your email address with admin access
Inside your application root directory clone your repository.
cd /var/www/html/
git clone git#bitbucket.org:organization_name/repo_application.git repo_application
You need to create an SSH key on the machine you wish to connect to GitHub or Bitbucket, then add that key to your online account. You can do this by following this:
https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html
here is the situation: i have one machine which lives at my house (lets call it house_machine) and i have another machine at my office (call this one office_machine). im using ssh with dsa key authentication and without password authentication to access home_machine from office_machine. i have set up an ssh server on home_machine and added the public key generated on office_machine to the authorized_keys file on home_machine. this works fine - i can ssh in to home_machine from office_machine just using the key and no password.
now the question: i would like to be able to access home_machine when i visit other offices simply by using the public key belonging to office_machine. ie i would like to put the public key (id_dsa.pub) on a usb drive and just copy it to the .ssh directory at another office. from what i have read on this site, others seem to have been able to do this type of thing, however it isnt working. when i try simply placing id_dsa.pub on a new machine and doing ssh -v user#home_machine the debug message ends with:
debug1: Offering public key: .ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
my temporary solution has been to set "PasswordAuthentication yes" in sshd_config on home_machine, and just use a password to get to home_machine. however this voids the point of using key-authorisation.
thanks in advance!
You need to copy more than just the public key - you need the private key.
In ssh, you place the public on the server side but the client side needs to have the private key.
You want to copy over the id_dsa file (not id_dsa.pub) to your USB key (make sure it's protected with a passphrase, in case it gets lost!).
You can then use that key to login to home_machine from any machine that has access to the key:
ssh -i /path/to/id_dsa user#home_machine
(it looks like you might already have a different private key on office_machine, judging by what you pasted - You might look into using ssh-agent)
Also, check /var/log/secure to see why your sshd might be rejecting key authentication (it's often an issue of permissions on the .ssh directory and its ancestors).