I would like to generate a public SSH key from an OpenSSL generated Ed25519 private key.
I tried:
ssh-keygen -t ed25519 -f ed25519_key -y > ed25519_ssh.pub
And got the error:
Load key "ed25519_key": invalid format
SSH and SSL are two things.
SSH means "Secure Shell" and is used for remotely connecting to another machine to issue commands, most likely via a CLI (Command Line Interface).
SSL means "Secure Sockets Layer", an older version of actual TLS, used to secure data transmission on a network.
To create SSL keys you can use openssl:
openssl genpkey -algorithm ed25519 -outform PEM -out ed25519_ssl.prv
openssl pkey -in ed25519_ssl.prv -pubout -out ed25519_ssl.pub
I am developing an application that uses ssh keys (JSch), and it won't accept some ssh keys. I want to make guidelines to users so they know which keys they can use and which one they can't. Hence the question: how can I determine the format of an ssh private key file, going beyond the RSA/etc and the number of bits?
For instance, at the end of this question is a 3072 bit RSA key that was generated using ssh-keygen with no parameters on android/termux. it works in ssh but both JSch and JuiceSSH refuse to even open it. openssl rsa -text -noout -in file says:
unable to load Private Key
1991864336:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY
I can fix this by running ssh-keygen -p -m PEM -f file, and this might be a workaround for some users, but it would help to know in advance which formats work and which don't.
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAxeXW062gz3y29H9nni0pz+IDetDpMWxOsyLXAIJuyRrXNqmcsLTz
f2qMP4ua3ENkqjoa+wwv95Ft+X4eb920FoKCL4vzpSWgFH8MfCL8Szs1y0/vgzVEipBMCh
FwIXqtnFaTvVS69vgZKARspIEod9z/Qvh0fsz5xCHlGwL2xy5eiUL2gjLXcfQxJQft5oo8
POBFSjCxWUwuE7MrqiaFbSUk3ULVyBVwTAJdC363oYWD5DV2WlYvxsEFQREbn4yRVjvzfe
1hKeKA/JnzZVYrCLOt5hOBTppY0rSSsiGCvhX+hKNStgG2JMSheBfjytENZ3hx050vfL6Z
5zOib97Gb+5qygbtcVosYsfXK34zOiMdDOBojItw0s0aZ3nSF+D1l+XqBaeHIBeX3+JoyN
kYjH/JPC1/hykrbi0ueOmaYI2xmBrqT8Z7aUX3EyKSOWNOMAWTiPDB2SFpjoQHuznq7nFg
/8zBbAU6/J3u/28sivhKDHXZLcZ7aw8glm3fr5DzAAAFiDYAnjo2AJ46AAAAB3NzaC1yc2
EAAAGBAMXl1tOtoM98tvR/Z54tKc/iA3rQ6TFsTrMi1wCCbska1zapnLC0839qjD+LmtxD
ZKo6GvsML/eRbfl+Hm/dtBaCgi+L86UloBR/DHwi/Es7NctP74M1RIqQTAoRcCF6rZxWk7
1Uuvb4GSgEbKSBKHfc/0L4dH7M+cQh5RsC9scuXolC9oIy13H0MSUH7eaKPDzgRUowsVlM
LhOzK6omhW0lJN1C1cgVcEwCXQt+t6GFg+Q1dlpWL8bBBUERG5+MkVY7833tYSnigPyZ82
VWKwizreYTgU6aWNK0krIhgr4V/oSjUrYBtiTEoXgX48rRDWd4cdOdL3y+meczom/exm/u
asoG7XFaLGLH1yt+MzojHQzgaIyLcNLNGmd50hfg9Zfl6gWnhyAXl9/iaMjZGIx/yTwtf4
cpK24tLnjpmmCNsZga6k/Ge2lF9xMikjljTjAFk4jwwdkhaY6EB7s56u5xYP/MwWwFOvyd
7v9vLIr4Sgx12S3Ge2sPIJZt36+Q8wAAAAMBAAEAAAGAdd2LUq3R3mJAMWUEWOA7S/Yn7m
koymfgg67XcRU+WIak8YiZq2FKuXPDLkG+rTtyZDSRRz6d/wxd/L/R7vyTuuhmE11+crjz
G+IDlJfdvgz44Cuu0m3Scdi5gTGboEUJy9iAy74AUQG5Me1Yq63FZYZ5ffCuqar5g4hQhQ
MB6eXDJmt8mFUhnlw7PPv5BFsGv5cvjZ1ss2u88by/3+prg3Mg/qtE2pNyO8MYmbUSN6Bm
ym/RGsLEV9M0hulik2dLSFfChfywm0//fBfD3L2Gusvr+sh9xq3W3e6qYilmy/QhSNy1XV
brDFGAzqmTISoeblZscmAsA1bKvt3rsU0Lfkxom3NnyXvSGJ7LXy+tzInu873+p2gyCylB
c4KpepodLGI8xLH6RFiyV4g0sFWgFROE9eLSR1mNa8tA54jD6NzEoy6ThlLnwH00DKccb1
6zNK0aNaJyXVEOUd5D0OR3/XkH9DhSl1W0GMHP9Y4JVgxWp1YMFqqYOyQqt9zNGO1JAAAA
wQCb63qWGLJp4RKdCyqkE1gdp4ohcgeofkRZvTPHZ6cepXDYSrefoxbOiFg6AmvWmyJxW+
pqjDaDj1OBvk729JdqBDKI/VyGxp992hIVssllD/MTvJR4omepfj91HsWRmlMSkpeGBAre
2gxI6oRVT/J/6oegUATeQOGOMunZIv6Q1JKcda9/zjPL4Pg9xDzp+VyfoMZpLNKp1F2tzT
VC6SueiDR0INVhWLOtWUSMZCWrvhMQmwz5jreuzkNallEdb/YAAADBAOiPLZbhMvUGCwwu
qodmzHGAQ7TrG1ifF8s/6weENsr2SPAJ7t+nbjmjtwlq+Sb+ye49cRh2jElqFQ3ckJVWfA
3WFkv7T576o2/Duye023i2coPmaZ0V44Qf3jVnV2Dl3663E7bQt4xYCNU4Odaq4EdhBsyy
ey/jIRR13UVfWf3q9zRvOWEk5kaE92bN0L8AEX2CfV6cTSrV8oHxLSG1RAr4706jXXV/34
N4QYwfCap1GW2rcPUu7oX+RMOk8mMgnQAAAMEA2dhG3XHIHbScvSs9m/C5WjIJ+uBKNeP5
YODIoy9cy9oK9AUFWr+RlSRv1rlx2/y2krsojKI0Y/GEW/0aNt85vD400MMDAgKx4Nl99C
uVXXysH9Y0BjSKZ/bqnYN/FL6apWrTxS7s3ZJTkuHgjf1ymo3ySLUyYX4wkJtTx71BJFg5
6FlKmYZKu6JSIoIzDKR6Uaqb8s0HOgj9a9bf7kXBk2CWfYz1BU777NqQdZAJdJtSH52fXg
Rlk/d8DHNpBVrPAAAAEXUwX2ExNzFAbG9jYWxob3N0AQ==
-----END OPENSSH PRIVATE KEY-----
I have a Proxmox hypervisor with 6 LXCs (servers) I have SFTP with chrooted user enabled on 4 of 6 LXCs with a custom port per LXC. Now I want the key authentication in FileZilla exactly like Amazon Web Services EC2 instances (a key.pem compatible with FileZilla and a authorized_keys file on my server in /home/user/.ssh/)
How to generate a key to .pem format who contents ? :
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
I know it's a noob question but I think it's first time I don't find what I want on Google or here on Stack Overflow
Thanks,
(Sorry for my English I'm a French baguette)
How to generate a key to .pem format who contents ? :
Using ssh-keygen -t rsa -f rsa.pem. Without any arguments, you will get the default location and configuration.
Other possibility is to use OpenSSL, that should do the same:
openssl genrsa -out private.pem 2048
For the purpose of ssh using public key authentication,
DSA-2048 keypair has been generated using openssl and both are stored locally in PEM format.
Now, for configuring in the server side (authorized_keys), public key has to be in the RFC-4716 format.
Usually as a practice, for getting this key, ssh-keygen is typically used with options as,
ssh-keygen -y -f private_key.pem
which returns the corresponding public key(RFC-4716) that has to be configured in the server side.
Without ssh-keygen, Is there a possibility in openssl itself to generate the RFC-4716 specific public key from the openssl generated public (or) private key?
I’m using the below snipped for setting the certificate and key for client authentication.
curl_easy_setopt(curl,CURLOPT_SSLCERT,"clientCert.pem");
curl_easy_setopt(curl,CURLOPT_SSLCERTPASSWD,"changeit");
curl_easy_setopt(curl,CURLOPT_SSLCERTTYPE,"PEM");
curl_easy_setopt(curl,CURLOPT_SSLKEY,"privateKey.pem");
curl_easy_setopt(curl,CURLOPT_SSLKEYPASSWD,"changeit");
curl_easy_setopt(curl,CURLOPT_SSLKEYTYPE,"PEM");
The certificate doesn’t have a password, I don’t know why on earth the option SSLCERTPASSWD exists, I just provided a dummy value.
When I run the program on Linux I get an error code of 58 and an error message
unable to set private key file: 'privateKey.pem' type PEM
On Windows however I get
unable to use client certificate (no key found or wrong pass phrase?)
It seems to suggest the certificate and the key don’t match but I don’t know how. I have extracted both the cert and the key from a p12 file using openssl commands.
The command I used to extract the key is
openssl.exe pkcs12 -in client.p12 -nocerts -out privateKey.pem
and the command used to extract the cert is
openssl.exe pkcs12 -in client.p12 -nokeys -out clientCert.pem
The p12 file has been successfully used in a browser to access the client authentication url.
Please help before I shoot myself.
Edit:
Here is proof that the private key and the certificate correspond to each other:
[debugbld#nagara ~/curlm]$ openssl x509 -noout -modulus -in clientCert.pem | openssl md5
d7207cf82b771251471672dd54c59927
[debugbld#nagara ~/curlm]$ openssl rsa -noout -modulus -in privateKey.pem | openssl md5
Enter pass phrase for privateKey.pem:
d7207cf82b771251471672dd54c59927
So why can’t it work?
Using the command line curl, I've got the same error using a .pem file that was also obtained with openssl from a p12 file, The p12 was also able to working properly doing client authentication when imported in a browser. Just like you described, I think.
My problem was caused because the .pem file was not listing the certificates in the proper order: seems that each certificate in the file has to be followed by its issuer certificate. I edited the file and changed the order of the sections and curl was happy.
For the record, my original .p12 file was obtained by backing up a certificate from Firefox.
Also note that in my case, I was not getting prompted for the password and was getting the
curl: (58) unable to set private key file: 'alice.pem' type PEM
before the password prompt
I was facing similar issues, I found out the problem was related to file permissions of the certificate and private key files. The process running PHP did not have read access to those files.
One thing you can try (and that helped me figuring this out) is to run the following code:
$result=openssl_get_privatekey('file://path/to/private/key.pem','password');
and check if the returned value is not false and there are no errors. I was getting:
file_get_contents(/path/to/private/key.pem): failed to open stream: Permission denied
Thanks Hugh for the thread and raugfer for the openssl hint. The later: both helpful and misleading. ;-)
Actually, I solved the problem by making sure that the path of the key file is correct. And here is why the openssl hint was misleading, dispite helping me to check if my PEM file was ok:
cURL needs the complete path, but without 'file://' prefix. While fopen is happy with a relative path, cURL is not. So, all my tests to open the key file had been successful, while cURL was not.
Btw.:
curl_easy_setopt(curl,CURLOPT_SSLCERTPASSWD,"changeit");
curl_easy_setopt(curl,CURLOPT_SSLCERTTYPE,"PEM");
curl_easy_setopt(curl,CURLOPT_SSLKEYTYPE,"PEM");
are not needed, as the password is only used to decrypt the private key and PEM is the default.