After domain migration, I am unable to load my public keys at all. I tried deleting them, recreating them but always getting same error as below
PS D:\Personal\OpenSSH-Win32> .\ssh-keygen.exe
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\raja/.ssh/id_rsa):
C:\Users\raja/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\raja/.ssh/id_rsa.
fopen C:\\Users\\raja/.ssh/id_rsa.pub failed: Permission denied
PS D:\Personal\OpenSSH-Win32>
I have tried fixing permissions
chmod 600 ~/.ssh/id_rsa.*
chmod: cannot access '/c/Users/raja/.ssh/id_rsa.*': No such file or directory
But seems failed. Please help.
Since you are in windows, try to specify a valid path to store the file (it is, using backslash instead of slash):
Change from
C:\Users\raja/.ssh/id_rsa
to
C:\Users\raja\.ssh\id_rsa
Related
I am trying to downloads pods for my Xcode project (there are many) and it is wanting me to enter my passphrase for almost every pod. How can I just enter my password once?
When you generated id_rsa pair you have used a password. Now it can't be used without password. It is located in ~/.ssh folder.
You can delete this key and recreate it.
But you lose all access to services where you use it.
Here is documentation how to create new pair (pub and priv keys)
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
Also you can try to change password with ssh-keygen -p
https://serverfault.com/questions/50775/how-do-i-change-my-private-key-passphrase
When you use blank password, it will not prompt to you each time.
I am trying to generate a ssh key pair to retrieve for my professor to load onto a server.
I have a Macbook Air (2015) and I followed instructions given online at siteground.com for Mac OS generation.
This is the code:
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/.ssh/id_rsa.
Your public key has been saved in /Users/.ssh/id_rsa.pub.
The key fingerprint is:
vaRiOusLeTteRs
The key's randomart image is:
----Itookthisout
Now the issue is that when I try to access it this is what happens: I get a permission denied. How can I retrieve the .pub key to send it over?
(base) MacBook-Air-2:~ /Users/.ssh/id_rsa.pub
-bash: /Users/.ssh/id_rsa.pub: Permission denied
Thanks!
Question was solved by qasimalbaqali, I will use this one as the accepted question since he only left comments. Thanks again!
When I try to list my gpg keys I'm getting an error:
gpg --list-keys
gpg: NOTE: trustdb not writable
gpg: checking the trustdb
gpg: trustdb rec 56: write failed (n=-1): Bad file descriptor
gpg: trustdb: sync failed: Bad file descriptor
I tried doing a recursive chown on my user directory. But that didn't seem to solve the problem.
The volume is not read only:
[web1:~] bluethundr% touch test
[web1:~] bluethundr% echo hi > test
[web1:~] bluethundr% cat test
hi
So I'm wondering why the trustdb is not writable.
How can I solve this?
That seems to have been reported in bug 771976
I found this when running the command apt-key list on a machine where
the root filesystem is normally mounted read-only.
This results in running gpg with "--trustdb-name", "/etc/apt//trustdb.gpg", "--list-keys".
gpg in turn attempts to create "/etc/apt//trustdb.gpg.lock" in order to lock the trustdb, which fails.
Seeing how --list-keys is an operation which shouldn't require writing
to anything, having it fail in this situation is bad.
Even though the volume is not read-only, check (with an strace) where gpg --list-key is attempting to create its trustdb.gpg.lock file.
strace gpg --list-key | grep trustdb.gpg.lock
The OP bluethundr adds in the comments:
I changed to the .gnupg directory and did a list.
I saw that the files in there were owned by root! So I did a sudo chown -R myuser:myuser *.
Then I ran gpg --list-keys again and it worked!
The problem was that the files in .gnupg were owned by root for some reason.
I granted the permissions on the trustdb.gpg file present in the installation directory in C Drive, to the user I had logged on with. It worked thereafter.
I use the following command and i got the code from http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html
ssh -i my-key-pair.pem ec2-user#ec2-198-51-100-1.compute-1.amazonaws.com
I'm not sure if it's because I lost the .pem file and recreated it or what is going on here, but no matter if I use the user ubuntu, root, or ec2-user the terminal asks me for a password.
Your local private key must be shrouded as it should be. It can be disabled with key management tools if you really want, but not advised.
Double-check the file permissions on your key file. Do:
chmod 400 my-key-pair.pem
and try again.
It is also likely that the key file is just the wrong one.
You have to terminate the instance and copy it with a new ssh key. If a key is lost then access to the server is also lost.
I am attempting to connect to an Amazon EC2 Server via Mac Terminal. I have a PPK file that does not have a password attached to it, but when I try to connect I get a popup box that says "Enter the password for the SSH Private Key."
So we tried creating a PPK that has a password - but it does not accept the password, it still rejects the connection.
I have a Windows user who is able to connect using the same PPK on Putty.
Has anyone experienced this issue?
The mac is looking for a .pem key. The ppk is generated specifically for putty. If you don't have the original ppk key.
Download puttygen.exe from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Then go to conversions -> export OpenSSH key. Save the output as a .pem file and try using that with the mac.
If this doesn't work can you post the command you're running from mac. Its possible you've got some extra parameter or something.
Maybe your problem is with permissions for your key. I know in linux its required to change the permissions.
Taken from the website http://om4.com.au/ssh-rsa-key-pairs-passphrases-leopard/
Clear the contents of your ~/.ssh directory and set the directory permissions to 700 (directories need to be "executable")
$ rm ~/.ssh/*
$ chmod 700 ~/.ssh
Generate your rsa key pair (there are variations for this, but this is the version I used):
$ ssh-keygen -t rsa
Set the permissions for all files in ~/.ssh to 600
$ chmod 600 ~/.ssh
Copy your id_rsa.pub key to your server’s .ssh/authorized_keys file
Add your passphrase to your keychain using this command:
$ ssh-add -K
(you will see Enter passphrase for [your system]/.ssh/id_rsa: )
The error Enter your password for the SSH key x can result from using a key of the wrong format (such as a ppk key) in ssh or sftp. This is because it is interpreted as an encrypted ssh key and so prompts for the passphrase, when actually there is no passphrase.
In OS X I was able to simulate this error by simply typing the following into the command line:
sftp -o IdentityFile=randomtextfile mysftpserver.com
The solution is to convert the file using puttygen as suggested by bwight.
In addition to the other answers, the issue might come from the fact you haven't specified which user you want to connect as.
For example ssh -i francky.pem 208.52.170.43 will ask you for your password on Mac, whereas ssh -i francky.pem root#208.52.170.43 shouldn't. Note that on Linux you don't specify the user.
I was running into the exact same problem in MAC, I found a quite simple way of getting rid of it.
Instead of using ssh -i IP address, use the following>
ssh user#IP
Hope you already found the answer after this long time :)
In my case, the problem was the file's break type. Try this:
1.- Open the .pem file with TextWrangler
2.- At Bottom of app, verify if the Break Type is "Windows(CRLF)".
This issue had me pulling my hair out for 20 min or so. Realized that I was able to connect successfully from another terminal window. In my case I just had to close out the current terminal window and use another or new window. Very strange, but may help you out.