When I am using paramiko 2.4.0, I continue to receive errors like this:
SSHException: not a valid OPENSSH private key file
While I can use the key to ssh to the machine, and the remote is reachable.
The key is generated by:
ssh-keygen -t rsa
Then I copy the public key to the remote machine:(the path can be private key, too, it is the same)
ssh-copy-id -i /path/to/public/key root#remote_host
Why?
It turns out that the mechanism of detecting key errors in paramiko is... too simple, sometimes naive. As indicated by #340 and #387, there are some known issues.
At last it turned out that it is not the problem of the key; the message is confusing. It is problem of username/permission/duplication.
paramiko will try to login with the user you use in the key, because it assumes that user also exists on the remote machine. But I think this logic is wrong, because basically when you use cryptography login, you don't need a username; you have the private key and the server has the public key, and that's all what it requires.
Imagine this scenario: you generate a key with Windows, and you are john here, your public key will have john#myhost in the authorized_keys file. When you connect() without username, you actually are login with john in another Linux machine, which may not have this user. If you are on a Linux, it is better, because if you generate the key with root, in another machine it has root, too, and root may have the correct permission on the public key file.
So, at last, I was able to solve the problem by:
in the remote machine, examine authorized_keys file to eliminate any duplicated lines of same user#host.
after generating the public key, change it so that user in it is a valid user on remote machine. Yes it seems strange, but it is how paramiko works. Then copy it to remote.
when calling connect(), pass in the username arg to be the same username you put in the public key.
make sure the user you used in public key has right permission on the authorized_keys file, and its parent .ssh folder. At least r permission.
Related
I have 15 instances running with same security group, however I can SSH into some of them but not the others. I received "Permission denied (publickey)" message for those instances. I also confirm that all instances are using the same public key and I try to ssh into all of them with the same private key.
What do I miss?
Thank you for helping out!
If you are getting "Permission denied (publickey)", it is not a security group issue. It is most likely one of the following:
You didn't specify the public key to use when launching some of the instances.
There was a problem with the metadata service on some of the instances which meant that cloud-init was unable to retrieve the public key.
You are using the wrong credentials; e.g. the admin account name is different on the different instances. (The default is OS dependent.)
You have multiple keys in your ~/.ssh directory and they are being tried in the wrong order. If you have fail2ban set up on the server side, each time that the client supplies a key counts as a login attempt. You can hit the limit before you tried the key that is going to work.
If you look at the respective instance's console log from their first boot, you can see which public keys were actually used. This can be used to diagnose 1 and 2.
For 3, check the OS documentation.
For 4, try using the ssh command's -i option to specify the path to the private key file.
There are other possibilities; e.g. if you launched instances from a non-pristine image / snaphot.
Reference:
Troubleshooting SSH access to a NeCTAR instance
this has been driving me mad and after hours searching here and everywhere else I am still unable to figure out why this is failing to work.
Syntax
sftp -o IdentityFile=/abc/efg/xxx/Priv_Key2.ppk -P 40007 at0223988_qa#inet-proxy-pg-1.us.adns.me.net
Initially the output was as follows:
Permissions 0755 for '/abc/efg/xxx/Priv_Key2.ppk' are too open.
So I went in, chmod 600 to lock down my private key, but now I get the following:
Enter passphrase for key /abc/efg/xxx/Priv_Key2.ppk:
The problem here is, there is no passphrase. I am logged in as the user that created this keypair and have no issue changing the permissions but sftp ignores the private key and errors out unless it is locked down as 600 but after I apply perms to 600 and rerun the sftp, it prompts me for a pw for this private key.
SCP does the same thing, asks for a passphrase if I change perms to 600.
What am I not seeing here? I am using PuttyCM, keygen was created in Putty KeyGen as SSH-2 RSA
Fixed this by reloading my private key back into the PuTTy KeyGen and choosing "Conversions" tab at the top, exporting to OpenSSH, then using that version of the key. Not sure why this worked but must have to do with our version of redhat not wanting to read that .ppk
I want to locate the private key of a certificate in the current user certificate store in Windows. Does anyone know where the private key is saved?
This article describes where private keys are stored on a filesystem: Key Storage and Retrieval
To determine exact file name, run the following command in the Command Prompt:
certutil -user -store my "<SerialNumber>"
where <SerialNumber> is the serial number of the target certificate. If certificate contains private key, there will be Unique Container Name field which contains file name.
You can see the certificates in the Microsoft Management Console (MMC). See here a guide with some steps:
https://msdn.microsoft.com/en-us/library/ms788967(v=vs.110).aspx
I'm trying to set up cloud hosting with Digital Ocean.
Please skip to the bold part with asterisks (***) for the actual problem. Everything below here, above that part is background info.
I need to generate an RSA key pair, so I navigate to my cd ~/.ssh/ directory, then:
ssh-keygen -t rsa
I already have existing id_rsa and id_rsa.pub files, so when prompted:
Enter file in which to save the key (/demo/.ssh/id_rsa):
I enter the following to create a new pair:
~/.ssh/id_cloudhosting
I'm then asked for a passphrase, which I simply press return for "no password":
Enter passphrase (empty for no passphrase):
I repeat the above for confirmation, and the final output looks as follows (just a demo image):
Now that I have two new files, id_cloudhosting and id_cloudhosting.pub I need to copy the contents of the public file to my Digital Ocean hosting 'Add SSH console'. I do that like so:
cat ~/.ssh/id_cloudhosting.pub
Which returns the contents of the file:
ssh-rsa
bUnChOFcOd3scrambledABCDEFGHIJKLMNOPQRSTUVWXYZnowIknowmy
ABCnextTIMEwontyouSINGwithmeHODOR demo#a
I paste the key into my hosting console and it saves successfully.
The next step is where the permission issues start: ****************
I need to "spin up a new server" - step four from their docs. So I enter the following:
cat ~/.ssh/id_worker.pub | ssh root#[my.hosting.ip.address] "cat >> ~/.ssh/authorized_keys"
Which should copy the public key as root to a newly created file called authorized_keys
This step never gets created because I'm immediately asked for a password to my host. I didn't ever create one! I pressed return (or enter) at that point, so I do the same when prompted, and get permission denied!
root#[host.ip.address]'s password:
Permission denied, please try again.
root#[host.ip.address]'s password:
Permission denied, please try again.
root#[host.ip.address]'s password:
Permission denied (publickey,password).
How can I rectify these permission denied issues?
EDIT: FIX BELOW
It seems as though, by using an unconventional (other than id_rsa) file, I needed to explicitly identify the file by doing the following:
ssh root#droplet.ip.address -i /path/to/private_key_file
...be sure not to use the public_key_file there. I am not connected to the server from my terminal. This is after destroying my previous droplet, creating a fresh one, with fresh key files, as #will-barnwell suggested
Assuming you have followed the linked guide up to and through Step Three, when you create a new server from their Web UI use the "Add SSH Keys" option and select the key you added to your account previously.
When actually spinning up a new server, select the keys that you would
like installed on your server from the "Create a Droplet" screen. You
can select as many keys as you like:
Once you click on the SSH key, the text saying, "Your
root password will be emailed to you" will disappear, and you will not
receive an email confirmation that your server has been created.
The command you were using was to add an ssh key to pre-existing server. Judging from the above quote I bet the password that you are being prompted for is in your email.
Why?
When you create a server on Digital Ocean ( or really most cloud hosting services ) a root password is automatically generated for you, unless you set the server up with an authorization key.
Using key authentication is definitely a good security choice, but make sure to read the instructions carefully, don't just copy/paste commands and expect it all to work out.
EDIT: OP's comments on the question have shed additional light on the matter.
New Advice: Blow your server away and set up the SSH keys as suggested, your server is probably unusable if it is not accepting your old SSH key and is prompting you for a password you don't have.
Be careful messing around with your last auth key, add a new one before removing an old one.
I'm trying to add a new user to my Ubuntu system and give them SSH access, using public/private key to log in. But I can't seem to get it to work.
Used putty gen to generate a public / private key pair. Then copied the public key into their homedir/.ssh/authorized_keys. But when I load the private key into Pageant in my windows session and try to use putty to get in, I am getting "Disconnected: No supported authentication methods available".
The funny thing is, If i put the same public key in the existing user's ./.ssh/authorized_keys file, I can log on using that user. This was set up by someone before me who I can't contact now though, so I don't know what the difference is.
If I check the etc/ssh/sshd_config file, the AuthorizedKeysFile line is commented out.
#AuthorizedKeysFile %h/.ssh/authorized_keys
BUt even if I put it back in and restart ssh service it still doesn't work (though I didn't think would solve it because why would the current user work)
Is there anything I can do?
Read the sshd daemon's error messages in your system log (auth.log or security.log or some such).
My guess would be that the directory and/or file permissions on .ssh or .ssh/authorized_keys are too permissive (insecure) in the new user's home. This should fix it if this is the problem:
chmod 700 .ssh
chmod 644 .ssh/authorized_keys