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.
Related
Currently I am facing a problem with git clone a repo using SSH. I had set up my SSH Key and inserted it into GitLab. However still it does not work out.
Permission denied as like below:
And another problem is the fingerprint generated above is different from the one that is generated in Gitlab as shown below:
Hope if anyone could help. Had been troubleshooting this for a few days.
I tried to delete the .ssh folder and regenerate new key and did everything the same again but turn out to be the same, Permission denied and fingerprint is never matching.
I am using OpenSSH and OS: Windows 11 for this problem. I had also tried ssh -Tvvv <username#server> , ssh <username#server>, ssh -Tv <username#server> to verify whether if I am connected but the same permission denied.
As commented, the server fingerprint (for the ~/.ssh/known_hosts) differs from the public key fingerprint.
For the latter, test it with ssh -Tv git#gitlab.com, and check your private key is used.
If your private key does not have a default name (like id_rsa), you would need a ~/.ssh/config to reference your key.
Host gl
Hostname gitlab.com
User git
IdentityFile ~/.ssh/myKey
And ssh -Tv gl for testing.
I'm trying to connect to my server where I have Magento installed.
I loaded the key on my windows cmd with ssh-add, and then connected with:
ssh -pPORT user#server
and I get:
Permission denied (publickey).
How can I fix this? I can't run chmod 600 on windows and already checked the permissions on the key file and are 'full control'
A permission denied, as commented, means SSH does connect, but does not find the right public key to validate the private one used locally.
Try ssh -Tv -pPORT user#server to see what key is used locally.
Then make sure your public key is copied to the remote server, in ~user/.ssh/id_rsa.pub (replace "user" by the actual user account name you need in your case)
This error usually means your key hasn't been added to the authorized keys list on the host machine. You can either manually add the public key to the server, or use the following command from the machine you're using to connect to the server.
ssh-copy-id -pPORT user#server
This will require you to enter the users password first time, but will then copy your public key onto the host/server to allow key based authentication next time you login.
I keep most of my personal projects on BitBucket by Atlassian. As a natural choice, I use SourceTree app (their product) as git GUI client on Windows, and I'm happy with it. For projects where ssh git is available, I prefer ssh over https. SourceTree plays very well with projects hosted on BitBucket. Although it offers both of ssh agents: OpenSSH or PuTTY, its default selection is PuTTY/Plink (perhaps because PuTTY is more Windows-familiar).
Recently my establishment requested to host some projects on its own server. At first look it's a git server using GitLab opensource. I can use SourceTree with project hosted here using https just fine, however when it comes to ssh, the only choice of SSH agent is OpenSSH. The only key pair it would use (unless specified in config) is ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa (located in %USERPROFILE%\.ssh\
I've tried to:
Load ~/.ssh/id_rsa into PuTTY Key Generator
Convert it to PuTTY format (.ppk) file
Load the .ppk into Pageant (PuTTY authentication agent).
Despite the key being loaded and kept in the memory by Pageant, the connection with the server failed all the time, e.g. git: fatal: Could not read from remote repository. The only way to make it work is to start ssh-agent and ssh-add (go with OpenSSH).
Since I have Pageant running usually in the background, I find it more convenient to use (e.g. the keyphrase to open the private key is long/complex, and I don't remember it, and it can be copy-pasted from KeePass, while in the case of OpenSSH, cmd console does not allow me to paste it, too bad).
Is there anyway to make the ssh authentication to GitLab done via PuTTY instead of OpenSSH?
Did you connect to the SSH server using PuTTY before using plink? If not a reason could be that plink is refusing to connect to the server, because the ssh hostkey isn't verified yet. Another reason could be that the SSH server requires ciphers which are not supported by PuTTY. You can only find out if you connect with PuTTY with the same version as plink.
Use TortoiseGitPlink (from TortoiseGit) to circumvent this issue, as it will popup a messagebox asking whether to accept the hostkey or not.
I have trouble getting the official Windows ADT 21.1.0 distribution to connect to a git repository. No matter what I tried(details below) it complains about host key not present in the registry and shows me no option to accept the host key. The remote server is running Gitlab and is under my control. There's no problem with connectivity or firewalls.
What I tried so far:
connecting without giving a password, with user git
connecting while giving a password, with another user
adding manually the host key in the known_hosts file that is found in the ssh home directory(Preferences->General->Network Connections->SSH2->SSH2 home).
The message is always:
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 xx:xx:xx...
Connection abandoned.
RSE works without any problems, only egit gives me problems.
You could workaround the problem by not using the ssh protocol with the git server, but instead the git or http protocol.
One reason for the above message can be using a folder called "ssh" instead of ".ssh" (note the dot). Some colleague of mine experienced that, and this can easily happen when using Windows explorer, as it will silently remove the dot, when creating a folder called ".ssh". You have to use the command line instead.
Ok, so I have Hudson (v1.393) running in an Ubuntu VM and everything's working fine.
However I'm trying to add a Mac slave to the Ubuntu master and I've run in to a few problems.
I have set up SSH keys so that from the command line, the Ubuntu VM can ssh using the key into a user called hudson on the Mac.
In the Hudson slave configuration, I have "Launch slave agents on Unix machines via SSH" selected and have entered the host IP, username of the user on the slave and the location of my private key file on the master (which has been added to the authorised keys file on the slave).
However, the master fails to connect to the slave.
Looking at the log (below), it's trying to authenticate using a password.
Is this a fall back for a failed key based SSH attempt?
Is Hudson only trying to authenticate using a password, and I need to change something else to get it to use the key file which is defined in the configuration?
Is it just not possible to launch slave agents via ssh on a mac? (I know the name of this type of slave launch method explicity states Unix, but I was thinking (read: hoping) that it would work with OS X too)
Log
[01/14/11 10:38:07] [SSH] Opening SSH connection to 10.0.1.188:22.
[01/14/11 10:38:07] [SSH] Authenticating as hudson/******.
java.io.IOException: Password authentication failed.
at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:319)
at com.trilead.ssh2.Connection.authenticateWithPassword(Connection.java:314)
at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:565)
at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:179)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:184)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.io.IOException: Authentication method password not supported by the server at this stage.
at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:289)
... 9 more
[01/14/11 10:38:07] [SSH] Connection closed.
If anyone has managed to conquer this type of set up before, or has any tips or ideas, I'd be very grateful!
Thanks
I've recently run into the same problem, trying to launch an agent on a Mac OS X 10.6 machine using SSH.
To get password authentication to work you'll need to edit /etc/sshd_config on the client node, setting PasswordAuthentication yes
In the Hudson dashboard take the node offline, make sure the configuration has a valid username and password, and launch the agent. Also make sure that the Remote FS root directory is owned by the build user you're connecting as.
For password-less ssh authentication, first check which user the Hudson master is running as. Lets assume that this is tomcat55. Generate a public/private SSH key pair (with an empty passphrase), then verify that the Hudson user can connect.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tomcat55/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tomcat55/.ssh/id_rsa.
Your public key has been saved in /home/tomcat55/.ssh/id_rsa.pub.
$ # authorize the hudson master on the hudson node
$ scp /home/tomcat55/.ssh/id_rsa.pub hudson#macnode:~/.ssh/authorized_keys
$ # test the connection
$ ssh -i /home/tomcat55/.ssh/id_rsa hudson#macnode
On the Hudson mac node, the /etc/sshd_config needs to allow for password-less access.
Protocol 2
PubkeyAuthentication yes
In the node configuration clear the password field, and set the private key field (in this example it is /home/tomcat55/.ssh/id_rsa). You should now be able to launch the agent:
[01/19/11 22:38:44] [SSH] Opening SSH connection to macnode:22.
[01/19/11 22:38:44] [SSH] Authenticating as hudson with /home/tomcat55/.ssh/id_rsa.
[01/19/11 22:38:45] [SSH] Authentication successful.
Check the /var/log/auth.log file on the Ubuntu machine. I'm betting you need to chmod 700 the .ssh directory of the hudson user.
I think the first answer (the selected one) is an awesome answer, but I did find a case where it is not the only solution.
In my case I have a Mac OS slave that was working and then I took that Mac down and brought up a new one. I thought I could just tweak the settings for the existing node's configuration to point it at the new Mac. It didn't work and I had all the same errors and problems described throughout this message thread.
Then I went in and deleted the node and recreated it with exactly the same settings and it worked. I suspect that SSH key fingerprint changed and by deleting the node and recreating it I was able to get it working. Whatever it is, the key component that caused it to fail is not a configuration option.