My ssh-keygen -l -f fails for dsa keys with error "not a public key file" but works fine for rsa key. The content is correct . What might be the reason. Anyway to figure it out?
It would be helpful if you showed the entire command line that you typed.
The reason is probably given in the error message. The filename you specified after the -f argument does not contain a public key (it contains a private key). Often public keys end with a .pub filetype.
Related
I getting error "ERROR: Failed to run ssh-add"
I am trying to ssh into remote machine so
SSH credential are set
Pipeline script is calling ssh-agent
On executing the job I get error below
I have tried this reported bug https://issues.jenkins-ci.org/browse/JENKINS-50181 but it is not working and bug has been already resolved in latest version 1.17 which i have now.
Can anyone suggest how to fix this issue.
This is just a wild guess since this could have different reasons.
But I just had this error, and my problem was that when I created the credential in Jenkins I forgot to add a linebreak at the end of the input.
...
...<all the usual content>...
...
-----END OPENSSH PRIVATE KEY-----<linebreak needed here>
I got this error when I put the SSH public key into the Jenkins credential instead of properly putting the private key.
Note that the private key is the long one that looks like this:
-----BEGIN RSA PRIVATE KEY-----
... lots of unreadable random characters for many lines ...
-----END RSA PRIVATE KEY-----
I got this error when I didn't put they private key's passphrase into Jenkins.
I thought the key didn't have a passphrase because I wasn't having to enter it when using the key manually. It turns out my local keyring was automatically taking care of this.
I ran into this problem after copying the credentials.xml file from an old installation to a new one. The key appears to be stored in a hashed format in the credentials.xml file and may be the hash is unique based on the version of jenkins. I just had to find the private key on my system and then paste it in the UI along with the additional line break as suggested by #peedee
I had the same issue when I tried to use OpenSSH key format in Jenkins credentials - remote session always fails with ERROR: Failed to run ssh-add.
The solution was to provide a PEM key generated with -m PEM flag. So the private key format should be: "-----BEGIN RSA PRIVATE KEY-----" instead of "-----BEGIN OPENSSH PRIVATE KEY-----" etc.
I was trying to login to a docker lab host using Putty but not able to login. The error is :-
'no authentication method available server sent public key'.
If I pass both username#server name i get error.
If I only pass the server name i get to the login screen but then when i enter my username the error pops up
I tried searching the web but couldn't find.
Please can anyone help me.
You can refer to the article "PWD + SSH = ❤" (with "PWD" = "Play With Docker").
The full command should be:
ssh -p 1022 <instance_ip_with_dashes>-<short_session_id>#pwdhost
But that requires on the client side to have in $HOME/.ssh
id_rsa: the private key
id_rsa.pub: the public key registered in <instance_ip_with_dashes>-<short_session_id> home.
Since copying a private key is not a good practice, you can do the opposite (in a Git bash session, not using putty):
ssh-keygen -t rsa -P "" -f ~/.ssh/id_rsa
Copy the public generated key to ~<instance_ip_with_dashes>-<short_session_id>/.ssh/authorized_keys
Then your SSH session will be possible.
Note: All that is managed for you if you are using the docker-machine pwd driver, as shown in the article above:
As you can see, in that case, a docker-machine ssh is enough.
http://github.com/play-with-docker/play-with-docker/issues/285
Actually I had to create or generate keys on the client. In order to start the communication between the client and the server.But I was copying the private key of the server silly me.
Key generation can be done in 2 ways
1. If you are using git run ssh-keygen
2. If you want to login using putty the first generate keys using puttygen and then attached the private key .ppk while ssh.
I am a first time AWS user, and have been following this tutorial
to set up with Ubuntu. I've generated my keys, saved to my computer, and now I'm at a screen that looks like this:
and the next steps is "put in your key"... I have been searching for hours on the internet, and I can not figure out where to find my key. Am I just pasting in the ssh file I have already saved on my folder, or is there a unique string within that file that I am needing to grab? If so - how do I find that? If not, what am I looking for here? Any help would be appreciated!! Sorry if this is a very elementary question. Thanks!!
Hopefully #error2007s helped but just in case -- you would need to put in your public key that is usually stored in a file called id_rsa.pub in your .ssh folder in your home directory. It starts with ssh-rsa, has a long list of letters and numbers and then ends with the email address you used when creating the key. You can list out the contents of that file by typing this in your terminal:
cat ~/.ssh/id_rsa.pub
That is what you need to add to the file on your server when you typed ~/.ssh/authorized_keys. Let me know if you have any other questions!
To be Direct to your question, on your blank nano editor for authorized_keys, you must put content of id_rsa.pub located under /home/deploy/.ssh/id_rsa.pub. you can simply cat /home/deploy/.ssh/id_rsa.pub, copy entire content and paste on the authorized_keys.
general steps to generate keys are below:
1) ls -ltr /home/deploy/.ssh - you would see like id_rsa, id_rsa.pub and authorized_keys. If you don't have authorized_keys, then do cp id_rsa.pub authorized_keys, it will copy id_rsa.pub content to authorized_keys. Please be sure that .ssh folder has 700 permission and files inside it has 600. Chmod 700 ~/ssh and Chmod 600 ~/ssh/*.
2) Create a key file in your local computer like (nano mydeploykey.pem) and make sure you copy the entire content of id_rsa and paste it on mydeploy.pem. Please ensure -----BEGIN RSA PRIVATE KEY----- contents and -----END RSA PRIVATE KEY----- is present. Note that there are five (5) dashes ----- and make sure you have those in your keys. If you missed copying one dash, it will not work.
Alternatively, you can use winscp or filezilla to copy id_rsa to your local computer and rename it as mydeploykey.pem. this key (mydeploykey.pem) should have 600 permission as well, if its too open, it will complain.
if you are using terminal to login, please use the following command.
ssh -i /path/to/mydeploykey.pem ubuntu#awspublicipaddress. Let me know if this does not work.
I've checked several threads regarding CLI access:
Jenkins CLI Authentication
Using the jenkins CLI (on fedora 23)
Jenkins CLI connection refused
And unfortunately it's not my case.
I'm trying to run the following command:
java.exe -jar jenkins-cli.jar -i C:\Users\myuser\.ssh\id_rsa -s http://MasterJenkins:port/ list-jobs All
And I'm getting the following execption:
Exception in thread "main" java.io.EOFException
at java.io.DataInputStream.readBoolean(DataInputStream.java:244)
at hudson.cli.Connection.readBoolean(Connection.java:93)
at hudson.cli.CLI.authenticate(CLI.java:565)
at hudson.cli.CLI._main(CLI.java:476)
at hudson.cli.CLI.main(CLI.java:387)
Going to : http://MasterJenkins:port/me/configure I made sure that the "SSH Public Keys" section is the same key I have in my public key. I was a month abroad, before leaving it worked, now it doesn't and my team member swears nothing changed in the system.
Any ideas?
I had a similar issue last week with my own ssh private/public key.
I fixed it by
Generating a new public/private key combination using ssh-keygen
bash-4.1$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/users/xxxxx/.ssh/id_rsa): JenkinsCLI
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in JenkinsCLI.
Your public key has been saved in JenkinsCLI.pub.
The key fingerprint is:
f6:4c:be:fc:cb:cd:d3:ee:8c:80:26:a2:57:df:67:14 xxxxx#eeeee
The key's randomart image is:
+--[ RSA 2048]----+
Private file
Copy and paste the content of JenkinsCLI in your .private file
Public file
log into Jenkins>Click your Login id dropdown>Configure>SSH Public Keys
copy and paste the content of JenkinsCLI.pub file into SSH Public Keys text area
You should be able to authenticate.
I am following this guide: https://thesweetsetup.com/how-to-use-digital-ocean-for-web-development-on-an-ipad/ To setup an environment on an iPad using Blink/Mosh.
I generated a droplet in the DO UI and added the public key I created using ssh-keygen in blink (also tried ssh-keygen -m pem). When I do ssh root#<IP-ADDRESS. I get the usual dialog:
Ed25519 key fingerprint is SHA256:<key>.
The server is unknown.
Do you trust the host key? (yes/no): yes
This new key will be written on disk for further usage.
Do you agree? (yes/no): yes
After this I just get back to blink. If I try to SSH again nothing happens. If I try to say ssh -i id_rsa root#<IP-ADDRESS> also nothing happens.
What am I doing wrong? I found this: https://github.com/blinksh/blink/issues/725 But do not understand what to do to fix.
I had this same problem. The blink terminal didn't give me any output or anything. The problem is that you have to give the full path of the id_rsa file (from the perspective of your default blink directory). So instead of ssh -i id_rsa root#<IP-ADDRESS>, do ssh -i .ssh/id_rsa root#<IP-ADDRESS>.
Btw one difference in our ssh key creation is that you created your key with the command ssh-keygen -m pem while I used ssh-keygen -t rsa -b 4096. I don't think that should be a problem though.
I had this same issue on some DO droplets I had. I had already set up the droplets with another key and added a new one for my blink app through the DO interface with no luck.
Realized that I had to still add the new public key to the authorized keys file in your users .ssh directory. ( ~/.ssh/authorized_keys ) and this solved my problem.
I did this through the device I was already using successfully, and copied to new key to that device to paste in.