Disable password and enable SSH keygen like AWS EC2 instances - authentication

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

Related

How can I obtain the known_hosts formatted public key value for ec2 instance ssh-key?

AWS outputs this key line 2048 SHA256:2p2o3eIz/XxxX6IIegXx5FkHo3Lap7xR+Ue2qJ0zV4w root#ip-****** (RSA) to the system log. How can I replicate this format for the ssh-rsa key from the command line? I was scraping the logs until I realized that you can't rely on ec2's console-log fetching command because it's buffered and only stores a small amount of the output.
To clarify the ssh-key file in question is a PEM style file with the beginning and ending tags for a base64 encoded ----RSA PRIVATE KEY----
If it's helpful to know the ssh-rsa line value for the public key is base64 encoded.
I've tried...
sudo ssh-keygen -E md5 -lf /etc/ssh/ssh_host_rsa_key
2048 MD5:10:b6:fd:21:fb:f4:ca:6b:ef:15:50:15:af:8b:5a:5d root#ip-****** (RSA)
and
sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key
2048 SHA256:2p2o3eIz/XxxX6IIegXx5FkHo3Lap7xR+Ue2qJ0zV4w root#ip-****** (RSA)
But neither produce output looking
-----BEGIN SSH HOST KEY KEYS-----
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7+hIGwj+cfT6tLdaVuUewnY/NwoQUdAaLw30auAHQS1B/HAEEJ+f+iLjC7JM2IV00Pgbt1trttRmaApghwkB75h0NXArxrfcHTKKV2FO0d8slO9HwDUMbLOEN+L5H0/T0Xtq9u1vnOz2LyMb5KeIywa0HXZ6bGqt1rYCV3Qi369+FUrtTFw8jo8Y21LmqHVltd/d7Kv40Hb3jzqAOCh3jtZ3bilenMA9pAtXM+XJP54oS6z0NutDJLU2n1DVg2q+5wwjJJqljgYg98t5Xj8VmGlWrtam6FMcaSJ77UwMyxLsSe/Ow7DYGAMrd6PLY5RA1stj4W0WYeB8IOSgyGWPf root#ip-******
-----END SSH HOST KEY KEYS-----
I had an ah-ha moment.
You can just use ssh-keyscan -t rsa localhost to generate the known_hosts key entry for the rsa public key of the server. Since I'm logging into the ec2 instance now instead of trying to scrape the logs I can just trust the results.

How can I determine the format of an ssh private key file?

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-----

PAM module that uses SSH

Is there a PAM module that can authenticate a user with an SSH challenge-response?
I'm trying to write a PAM aware application that essentially has the same authentication process as an SSH connection. I have been unable to find a PAM module that already does this (the pam_ssh module is still password-based), so I have been attempting to write my own.
However, I cannot find an API that will allow me to access SSH in this way. Even with a PAM module for sshd, there doesn't seem to be a clean way of verifying an SSH public key.
To be more explicit, if I am given an SSH public key for a given user on a machine (consider localhost for simplicity), I want to send a challenge to that user on that machine to test if they own that SSH key. Does anyone know a way of doing this?
Thank you!
You could encrypt some random data using the public key, send it to the user, and assert that they are able to decrypt it with the private key. If you're using RSA keys, you can perform the encryption/decryption with OpenSSL. For example,
# server
$ ssh-keygen -e -m PKCS8 -f ~/.ssh/id_rsa.pub >pub.pem
$ openssl rsautl -pubin -inkey pub.pem -encrypt -pkcs -in random -out encrypted
# client
$ openssl rsautl -inkey ~/.ssh/id_rsa -decrypt -in encrypted -out random
and verify that the client is able to reply with the correct contents of random.
These commands are inspired by jass, which you could use instead of ssh-keygen+openssl.
Unfortunately, this doesn't work with Ed25519 keys; OpenSSH has its own custom format and doesn't have a way to convert them.

Amazon Elastic Load Balancer SSL certificate installing How To

I'm having troubles making my Amazon-servers secure and I need some help here.
I purchased a wildcard cert, and the company sent me lots of different files:
DigiCertCA2.pem
mydomain.pem
TrustedRoot.pem
And all the files in one file as a chain, and also the same files in .crt -format.
Now I'm trying to install these to the Amazon Elastic Load Balancer, which keeps telling me that the key is in wrong format. Amazon asks for these:
Private Key:
Public Key Certificate:
Certificate Chain:
What do I put and where to make this work?
I got it to work! Yay!
Here's what I did for anyone else having hard times with this. :)
Amazon ELB will ask for "Private Key", which is the key that you created the first time you needed to give your certificate issuer the CRS-code. My key was in wrong format, which can be seen by looking at the beginning of the file. I had it like this:
-----BEGIN PRIVATE KEY-----
And it should be like this:
-----BEGIN RSA PRIVATE KEY-----
So I did this to convert it to the right format:
sudo openssl rsa -in mydomain.key -out mydomain_new.key
Then copy-paste the contents of the mydomain_new.key -file, into the "Private Key" -textarea.
Next is the "Public Key Certificate". This is the contents of mydomain.pem -file.
And finally it's turn for the "Certificate Chain". This is the contents of the DigiCertCA2.pem -file.
And that's it. Amazon accepted it beautifully without complaints.

"Public key certificate and private key doesn't match" when using Godaddy issued certificate [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I'm trying to install a GoDaddy SSL certificate on a new load balancer I'm setting up on Amazon AWS. I originally created the certificate at Godaddy using the keytool program for direct installation on a Glassfish 3.1 server (Amazon linux ami). I had no problems getting that setup directly on the server. I now need to move the certificate from the web server to the new load balancer. Amazon requires the private key and certs to be in PEM format, so I used the "rekey" tool at GoDaddy to create new certs. When I load those in the load balancer setup screen on AWS Mgmt Console, I get the error message: "Public Key Certificate and Private Key doesn't match."
Here is how I'm creating the keys:
$ openssl genrsa -des3 -out private.key 2048
$ openssl req -new -key private.key -out apps.mydomain.com.csr
I then submit the .csr file to GoDaddy during the "rekey" process. Once the rekey is complete, I download the 2 newly created certs (apps.mydomain.com.crt & gd_bundle.crt). I download them selecting (Apache) as the type of server (I've also tried "other" and "Cpanel" but the all look to be the same).
At this point, I remove the encryption from the private.key file by using the following command:
$ openssl rsa -in private.key -out private.pem
At this point, I go back into the AWS Mgmt console, create the load balancer, add the secure server redirect and put the contents of the following files in the respective fields on the screen where it asks to setup the ssl certificate:
private.pem --> Private Key
apps.mydomain.com.crt --> Public Key Certificate
gd_bundle.crt --> Certificate Chain
When I click the "continue button" I get the error "Error: Public Key Certificate and Private Key doesn't match."
-Is there a way that I can test that I'm getting a valid error message from Amazon? It seems odd to me that the keys wouldn't match when I'm following GoDaddy's instructions pretty closely.
I've tried creating the private.key file without RSA encryption prior to creating the .csr and that doesn't seem to make any difference.
I'm also assuming that the .crt files I'm downloading from GoDaddy are in .PEM format, but I'm not sure how to verify this.
Any ideas?
For me, it was an easy two-step:
Convert the private key to PEM:
openssl rsa -in yourdomain.key -outform PEM
Convert the certificate and certificate bundle to PEM:
openssl x509 -inform PEM -in yourdomain.crt
openssl x509 -inform PEM -in bundle.crt
Just for the record and anyone else who is trying to figure it out:
yourdomain.key
-> terminal command: sudo openssl rsa -in yourdomain.key -outform PEM -out yourdomain.pem
-> private key
yourdomain.crt
-> public key
gd_bundle.crt
-> certificate chain
and you're good to go :)
Looks like the issue was the way in which I was copying the contents of the key and certs into the AWS Management console. I was using an Ubuntu desktop running in Virtual Box on a Windows 7 desktop; copy and pasting the values from a gedit screen into the browser running on the Windows box. Once I opened the key and cert files on the same box as the web browser (Windows in this case) the certs went through just fine. I'm guessing some parts of the file aren't making it over correctly when using the shared clip board between Virtual Box client and host. Case closed.
We found an alternate solution to this problem. We were having the same symptoms with the same error.
Then we tried reentering the pem codes one more time, but this time we made sure to hit enter one time and make sure the cursor was on a blank line at the end of each window. Then we saved it.
IT WORKED.
This solved our problem, so it might solve it for others.
One little gotcha. I'm using a Windows box (Win 7 Pro) and when I used the windows port of OpenSSL, the outputted files had Unix style end-of-line characters (LF).
I had to convert the file to Windows style (CRLF) for the uploading of the private key.
I can suggest you with an alternative solution and an information to you folks.
Generally all certificates are of PEM file format. You can just open a notepad or any text editor and drag the files which you received in .crt file format. Which is normally called as .PEM file.If the certificate loaded in your keytool you can export the certificate as a pfx file from keytool. Then you can separate the pfx file from the private key from the pfx file. Because the pfx file is the combination of your certificate and the private key.So you can get separately the private key file and use it on your amazon aws.
I suspect there may be another way to install the certificate. May be you can contact the certificate authority and is there any way to get your certificate to be reissued.