System: MacOS, standard Jenkins installation.
I can clone repository from my user. But Jenkins - can't neither from Git, not from GitHub (my key is added to Git and GitHub). I receive: "stderr: Host key verification failed."
I've copied my key into /Users/Shared/Jenkins/.ssh - but still no luck :( Maybe I've copied it to incorrect place?
Generate ssh key from Jenkins is not an option for me.
What am I doing wrong? Thanks in advance!
This is usually related to permissions, as Jenkins' process runs as user 'jenkins'.
See here: How to run jenkins as a different user -
especially the answers of Sagar and Peter Tran .
Cheers
Like the error says, the problem (at least first) is with host key verification. The first time you connect to an ssh server, ssh client will prompt you to check and accept the host key. (Of course no-one does that, so I don't know why it bothers...)
You could
sudo -u jenkins -i
and then
ssh git#github.com
and then reply to the prompt. Alternatively you can disable host key checking. Look up StrictHostKeyChecking in man ssh_config.
Related
Recently I had to get my hard drive replaced on my work machine and thus had to reconfigure everything. As a result I had to reinstall git bash. Before I was able to ssh fine into wpengine and now I cannot.
I am able to connect via the regular windows terminal fine but when I try with git bash I am getting the "Permission denied (publickey)." error for the same exact command.
I have tried all the suggested options from wpengine and in the different questions related to this on other SE questions and nothing is working.
I am using a Windows machine on windows 10.
Here are the following things I have tried:
Regenerating the key and adding it to my user public keys again and
then waiting 24 hours.
Adding the config details to the ssh_config file in C:\Program
Files\Git\etc\ssh
Adding a config file to my /User/username/.ssh/ folder.
I have tried using the following link and adding the wpengine rsa file: https://gist.github.com/jherax/979d052ad5759845028e6742d4e2343b as well.
Any and all help would be appreciated.
My guess is there is some kind of permissions issue going on the local machine?
Why would the request from git bash terminal to wpengine look different from windows command terminal?
I did solve my issue. If it helps you please use it!
When I used the command to the ssh host with : ssh -v user#environment.wpengine.ssh.net info
I got back this among the debug errors:
debug1: Offering public key: /c/Users/USERNAME/.ssh/KEY_FILENAME RSA XXXXXXXXXXXXXXXXXXXXX explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: No more authentication methods to try.
user#environment.ssh.wpengine.net: Permission denied (publickey).
After finding this page:
https://transang.me/ssh-handshake-is-rejected-with-no-mutual-signature-algorithm-error/
I was able to solve the issue by adding the line:
PubkeyAcceptedAlgorithms +ssh-rsa to my ssh config file.
Honestly I am not even 10% certain on WHY this worked, however, it solved my problem.
How To Connect with SSH In WPEngine
If you are having trouble connecting to SSH in WPEngine Following are the commands which I used:
ssh-keygen -t rsa -b 4096 -f c:/users//.ssh/wpengine_rsa
Add Fingerprint in WPEngine My Profile – SSH
Add Config file
Host *.ssh.wpengine.net
IdentityFile ~/.ssh/wpengine_rsa
IdentitiesOnly yes
Connect with your wordpress website (windows command prompt)
ssh environment#environment.ssh.wpengine.net
I've created GIT repo at my account of shared hosting via cPanel. Then I've installed Git to my local PC with Windows, right-clicked local repo folder and selected the command "Git Bash Here". Next I've run in CMD the command like
git clone ssh://user123#example.com/home/user123/public_html/repo
First I've received
The authenticity of host 'example.com (...)' can't be established.
ED25519 key fingerprint is SHA256:...
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?
I've typed "yes" and received the error
Warning: Permanently added 'example.com' (ED25519) to the list of known hosts.
user123#example.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Next I've copy-pasted the file id_rsa from the folder .ssh at my hosting to my local folder C:/Users/MyUserName/.ssh
Now if I run the command of cloning I receive
Enter passphrase for key '/c/Users/MyUserName/.ssh/id_rsa':
Why? What is the passphrase and where can I get it?
The pass-phrase is the password(s) you used when you created the ssh keys. You must use those password(s) to unlock access to the ssh keys.
Note that the warnings (about whether the host is known or not) are just that: warnings. The first time you connect to some other system, your ssh software checks the identity message that comes from that host. But there's nothing to check against, so you get the warnings. After that, the identity is saved, so the second, third, etc., times that you connect to the host, your ssh makes sure it identifies itself the same way. (This is a fancied-up variant of having the host tell you its password, which you then check to make sure you're still talking to the same guy.)
Of course, the host doesn't know whether the guy claiming to be you is really you, so the host demands that you provide your password. Your "password" in this case is your ssh key ... and your ssh key is protected with another password (or rather, "pass phrase": you can use multiple words). So you give your machine your "get me the password" pass-phrase, after which your machine gets the password to give to their host.
So I just upgraded my Mac mini (Late 2012) to macOS 10.12 (Sierra) and everything seems fine, but I’m running into one odd problem deploying code with Capistrano. I get the following error:
Permission denied (publickey).
Never had this problem before in Mac OS X 10.11 (El Capitan) or any version prior to it. Why is this suddenly happening now? Full output of the failed Capistrano deployment below:
jakes_mac:SomeCode jake$ cap staging deploy
INFO [hkdgad21] Running /usr/bin/env mkdir -p /tmp/somecode/ as jake#example.com
DEBUG [hkdgad21] Command: /usr/bin/env mkdir -p /tmp/somecode/
jake#example.com's password:
INFO [hkdgad21] Finished in 5.166 seconds with exit status 0 (successful).
DEBUG Uploading /tmp/somecode/git-ssh.sh 0.0%
INFO Uploading /tmp/somecode/git-ssh.sh 100.0%
INFO [xyz20312] Running /usr/bin/env chmod +x /tmp/somecode/git-ssh.sh as jake#example.com
DEBUG [xyz20312] Command: /usr/bin/env chmod +x /tmp/somecode/git-ssh.sh
INFO [xyz20312] Finished in 0.240 seconds with exit status 0 (successful).
INFO [abcdef01] Running /usr/bin/env git ls-remote --heads git#github.com:SomeUser/SomeCode.git as jake#example.com
DEBUG [abcdef01] Command: ( GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/somecode/git-ssh.sh /usr/bin/env git ls-remote --heads git#github.com:SomeUser/SomeCode.git )
DEBUG [abcdef01] Permission denied (publickey).
DEBUG [abcdef01] fatal: Could not read from remote repository.
DEBUG [abcdef01]
DEBUG [abcdef01] Please make sure you have the correct access rights
DEBUG [abcdef01] and the repository exists.
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as jake#example.com: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
SSHKit::Command::Failed: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Tasks: TOP => git:check
(See full trace by running task with --trace)
The deploy has failed with an error: Exception while executing as jake#example.com: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Seems like it’s an issue with SSH keys not being automatically added as it used to be in Mac OS X 10.11 (El Capitan). Is this expected behavior from macOS Sierra or something connected to OpenSSH?
Method 1: Add all known keys to the SSH agent.
So one solution I found is to run ssh-add with the -A option—which adds all known identities to the SSH agent using any passphrases stored in your keychain—like this:
ssh-add -A
Now this works but it won’t persist across reboots. So if you want to never worry about this again, just open up your user’s ~/.bash_profile file like this:
nano ~/.bash_profile
And add this line to the bottom:
ssh-add -A 2>/dev/null;
Now when you open a new Terminal window, all should be good!
Method 2: Add only SSH keys that are in the keychain to the agent.
So while the ssh-add -A option should work for most basic cases, I ran into an issue recently where I had 6-7 Vagrant boxes (which uses SSH keys/identities for access) setup on a machine on top of the more common id_rsa.pub in place.
Long story short, I ended up being locked out of a remote server due to too many failed tries based on SSH keys/identities since the server access was based on a password and SSH keys/identities are SSH keys/identities. So the SSH agent tried all of my SSH keys, failed and I couldn’t even get to the password prompt.
The problem is that ssh-add -A will just arbitrarily add every single SSH key/identity you have to the agent even if it’s not necessary to do so; such as in the case of Vagrant boxes.
My solution after much testing was as follows.
First, if you have more SSH keys/identities added to your agent than you need—as shown with ssh-add -l then purge them all from the agent like so:
ssh-add -D
With that done, then start the SSH agent as a background process like so:
eval "$(ssh-agent -s)"
Now, it gets weird and I am not too sure why. In some cases you can specifically add the ~/.ssh/id_rsa.pub key/identity to the agent like so:
ssh-add ~/.ssh/id_rsa.pub
Type in your passphrase, hit Return and you should be good to go.
But in other cases simply running this is enough to get the key/identity added:
ssh-add -K
If that’s all worked, type in ssh-add -l and you should see one lone SSH key/identity listed.
All good? Now open up your .bash_profile:
nano ~/.bash_profile
And add this line to the bottom; comment or remove the -A version if you have that in place:
ssh-add -K
That will allow the SSH key/identity to be reloaded to the SSH agent on each startup/reboot.
UPDATE 1: Based on davidalger’s answer I discovered a nicer, global solution that can work for all user’s on a system. Just open up the global SSH config located here via sudo:
sudo nano /etc/ssh/ssh_config
And add this line to the bottom of the file:
AddKeysToAgent yes
Did that—after removing the .bash_profile fix and all is good as well.
UPDATE 2: Apple has now added a UseKeychain option to the open SSH config options and considers ssh-add -A a solution as well.
As of macOS Sierra 10.12.2, Apple (I assume) has added a UseKeychain config option for SSH configs. Checking the man page (via man ssh_config) shows the following info:
UseKeychain
On macOS, specifies whether the system should search for
passphrases in the user's keychain when attempting to use a par-
ticular key. When the passphrase is provided by the user, this
option also specifies whether the passphrase should be stored
into the keychain once it has been verified to be correct. The
argument must be ``yes'' or ``no''. The default is ``no''.
Which boils down to Apple seeing the solution as either adding ssh-add -A to your .bash_profile as explained in this Open Radar ticket or adding UseKeychain as one of the options in a per user ~/.ssh/config.
Is this expected behavior from macOS Sierra or something connected to OpenSSH?
This is due to a new feature in OpenSSH 7.2 causing a change in behavior on the part of the SSH client. From the release notes:
ssh(1): Add an AddKeysToAgent client option which can be set to
'yes', 'no', 'ask', or 'confirm', and defaults to 'no'. When
enabled, a private key that is used during authentication will be
added to ssh-agent if it is running (with confirmation enabled if
set to 'confirm').
There were other interesting (security related) features introduced as well, although the release was considered mainly a bug fix release. This particular feature resulted in a default behavior change on OS X since it's default value is 'no' and OS X (I don't know about other clients) previously added keys to the agent as they were used.
So if you add the following to your ~/.ssh/config file (or the global ssh_config that should be located in /etc/ssh/ssh_config), keys will again be added to your agent as they are used.
AddKeysToAgent yes
This one-liner makes it pretty easy:
echo "AddKeysToAgent yes" >> ~/.ssh/config
After doing this, I was able to achieve the expected behavior:
$ ssh-add -l
The agent has no identities.
$ ssh -T git#bitbucket.org
logged in as davidalger.
You can use git or hg to connect to Bitbucket. Shell access is disabled.
$ ssh-add -l
2048 SHA256:<snip> (RSA)
This help me to resolve the issue on MacOS Serra:
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa_file
I've been using Tortoise to checkout/commit to the svn repository. It is set up to use Tortoiseplink as SSH client (D:\TortoiseSVN\bin\TortoisePlink.exe -l foo -pw bar). I have now moved to a Mac (using Cornerstone) but I can't get the same sort of setup. Whatever I do, I can't get Cornerstone to connect to the repo.
Do I need to set up an ssh tunnel? And how do I do that on a Mac?
Update: screenshot of the settings needed
What you have looks correct - the only thing I can think of is that your SSH connection is not working for some reason. Have you tried just doing an SSH to the server hosting the repository? To do this, open Terminal and type:
$ ssh hostgator_username#gator123.hostgator.com
If you are prompted for a password and you can log into the machine then that is a good start - if not that suggests that something is fishy with your network setup.
So on my friends local Windows machine we are trying to setup GIT.
Basically, we've been following this guide which has been great. The problem we are facing is as follows:
All works until we get to Using Gitosis
When we use the command
git clone
git#INSERT_IP_HERE:gitosis-admin.git
We keep getting
Initialized empty Git repository in
/home/Thomas/gitosis-admin/.git
Connection closed by IP_HERE fatal:
The remote end hung up unexpectedly
When we try simply
ssh git#IP_HERE
We get "Connection closed by IP_HERE"
If we login as
runas /user:git C:/cygwin/cygwin.bat
And run > ssh git#IP_HERE
We at least get asked for a password then
Last Login: Connection to IP_HERE
closed.
Would anyone be able to help ?
The error does indeed indicate that authentication is failing.
Firstly, open gitosis.conf on the server and check that you are a member of the group containing gitosis-admin repository. It should show something like.
[gitosis]
[group gitosis-admin]
writable = gitosis-admin
members = user1 user2
The member name must match with a public key in /keydir before access can be made.
Secondly, you do not say how you are connecting from the Windows machines. If you are using Git under Cygwin, make sure you are correctly loading the private key. If you are using MsysGit with Putty, be sure to load the private key before connecting as well.
There is a small gotcha if PuttyGen is used to generate key pairs, and that is the default format is different from OpenSSH which you are probably using. Copy and paste from the top window, or alternatively edit the multiline public key file to read like this.
ssh-rsa AAAABB...KEYBODY...ONLkQ== user1
Lastly, make sure port 22 is open in any firewalls if that is indeed the port you are using.
A more comprehensive description of how to set up a Git server with Gitosis on Windows, can be found at here
I recommend the use of MsysGit from windows, as it gives better integration into the Windows environment. TortoiseGit and GitExtensions both use MsysGit as the backend, and provide nice Gui's and explorer shell extensions. GitExtensions full installer will provide the windows user with everything they need.
Did you get past runnig the gitosis-init < /tmp/id_rsa.pub command?
That error indicates to me that the public key isn't set up properly. The command above initializes gitosis with the first key.