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
Related
I'm trying to use the R AzureDSVM package to create a Linux DSVM through R. I am reading the guide https://raw.githubusercontent.com/Azure/AzureDSVM/master/vignettes/10Deploy.Rmd (Azure DSVM guide)
First the guide requests you create an Azure Active Directory application which will provide a "tenant ID", "client ID" and "user key", the guidelines described in http://htmlpreview.github.io/?https://github.com/Microsoft/AzureSMR/blob/master/inst/doc/Authentication.html (Azure SMR Auth guide)
As I understand it, this creates an app registered in Azure Active Directory, creates an "authentication key" for the app, which is the user key, and associates the app with a Resource Group. I've done this sucessfully.
The Azure DSVM guide then creates a VM with public key authentication in a similar way to what follows:
library(AzureSMR)
library(AzureDSVM)
TID <- "123abc" # Tenant ID
CID <- "456def" # Client ID
KEY <- "789ghi" # User key
context <- createAzureContext(tenantID=TID, clientID=CID, authKey=KEY)
resourceGroup<-"myResouceGroup"
location<-"myAzureLocation"
vmUsername<-"myVmUsername"
size<-"Standard_D1_v2"
mrsVmPassword<-"myVmPassword"
hostname<-"myVmHostname"
ldsvm <- deployDSVM(context,
resource.group = resourceGroup,
location = location,
hostname = hostname,
username = vmUsername,
size = size,
os = "Ubuntu",
pubkey = PUBKEY)
The guide vaguely describes creating a public key (PUBKEY) from the users private key, which is sent to the VM to allow it to provide SSH authentication:
To get started we need to load our Azure credentials as well as the
user’s ssh public key. Public keys on Linux are typically created on
the users desktop/laptop machine and will be found within
~/.ssh/id_rsa.pub. It will be convenient to create a credentials file
to contain this information. The contents of the credentials file will
be something like the foloowing and we assume the user creates such a
file in the current working directory, naming the file _credentials.R.
Replace with the user’s username.
TID <- "72f9....db47" # Tenant ID
CID <- "9c52....074a" # Client ID
KEY <- "9Efb....4nwV....ASa8=" # User key
PUBKEY <- readLines("~/.ssh/id_rsa.pub") # For Linux DSVM
My question:
Is this public key PUBKEY generated from the authentication/user key created by setting up the Azure Active Directory application in the Azure SMR Auth guide (the KEY variable in the above script)? If so, how? I've tried using the R sodium library pubkey(charToRaw(KEY)) to do this but I get "Invalid key, must be exactly 32 bytes".
If PUBKEY isn't generated from KEY, from what is it generated? And how does the package know how to authenticate with the private key to this public key?
The AAD key is used for authenticating to AAD. The public/private keypair is separate and is used for authenticating to the VM. If you do not have a public key (in the file ~/.ssh/id_rsa.pub), you can create one using ssh-keygen on Linux.
SSH connections use the private key (in ~/.ssh/id_rsa) by default.
A couple of things in addition to Paul Shealy's (correct) answer:
ssh-keygen is also installed on recent versions of Windows 10 Pro, along with ssh, scp and curl. Otherwise, you probably have the Putty ssh client installed, in which case you can use puttygen to save a public/private key pair.
AzureDSVM is rather old and depends on AzureSMR, which is no longer actively maintained. If you want to deploy a DSVM, I'd recommend using the AzureVM package, which is on CRAN and GitHub. This in turn builds on the AzureRMR package which provides a general framework for managing Azure resources.
library(AzureVM)
az <- AzureRMR::az_rm$new(tenant="youraadtenant", app="yourapp_id", password="password")
sub <- az$get_subscription("subscription_id")
rg <- sub$get_resource_group("rgname")
vm <- rg$create_vm(os="Ubuntu",
username="yourname",
passkey=readLines("~/.ssh/id_rsa.pub"),
userauth_type="key")
Have a look at the AzureRMR and AzureVM vignettes for more information.
Disclaimer: I'm the author of AzureRMR and AzureVM.
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.
I have created the CSR for my Signing Certificate. During CSR creation, the CSR file saved on my system. But i couldn't find where is the Private key file. I am following the below URL instruction to create CSR file. Anyone help me with these how to check and find Private key file.
https://in.godaddy.com/help/windows-generate-csr-for-code-or-driver-signing-certificate-7282
Thanks for your help.
In Windows the private key is generated when you use the snap-in to generate the CSR. The private key is stored (encrypted) at:
%APPDATA%\Microsoft\Crypto\RSA\Your SID
or
%APPDATA%\Microsoft\Crypto\Keys
If there are multiple files in that folder, look for one with a date and time close to when you generated your CSR.
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