How are the public and private keys stored and related on both client and server?
up vote
0
down vote
favorite
I have tried to match the public keys and private keys on both my client and server as well as the configuration files but cannot get my head around the mismatches. I can successfully connect to the server on ssh despite the mismatches. This is a bit worrying.
I will show exactly what is stored where.
Client: Mac
Server: Ubuntu (hosted on AWS)
Files on my local mac /Users/sm/.ssh directory
ls -la
Sanjays-iMac:.ssh sm$ ls -la
total 24
drwx------ 5 sm staff 160 26 Nov 21:29 .
drwxr-xr-x+ 59 sm staff 1888 26 Nov 21:29 ..
-rw------- 1 sm staff 1696 26 Nov 20:49 id_rsa
-rw-r--r--@ 1 sm staff 451 26 Nov 20:50 id_rsa.pub
-rw-r--r-- 1 sm staff 1151 26 Nov 21:08 known_hosts
Files on my ubuntu server:
ubuntu@ip-172-31-30-19:~/.ssh$ ls -la
total 12
drwx------ 2 ubuntu ubuntu 4096 Nov 26 14:37 .
drwxr-xr-x 8 ubuntu ubuntu 4096 Oct 30 18:02 ..
-rw------- 1 ubuntu ubuntu 391 May 25 2018 authorized_keys
Present working directory on Ubuntu:
ubuntu@ip-172-31-30-19:~/.ssh$ pwd
/home/ubuntu/.ssh
Contents of authorized_keys
file on the server:
ubuntu@ip-172-31-30-19:~/.ssh$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
(contents are chopped off for privacy reasons)
Similarly, there is a known_hosts file on my local server:
Sanjays-iMac:.ssh sm$ cat known_hosts
54.251.104.13 ecdsa-sha2-nistp256 AAAAE2VjZHNhLX..Xsb/RBY=
52.76.85.25 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI....hAkfLOc5g=
ec2-13-127-241-121.ap-south-1.compute.amazonaws.com,13.127.241.121 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN....fu5Co4vYB0=
ec2-13-232-81-251.ap-south-1.compute.amazonaws.com,13.232.81.251 ecdsa-sha2-nistp256 AAAAE2VjZHNhL....nhNcRyfu5Co4vYB0=
35.154.168.85 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNo....NcRyfu5Co4vYB0=
13.126.30.42 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTIt....NcRyfu5Co4vYB0=
(contents are chopped off for privacy reasons)
Now my question is:
What should be equal to what?
I would think that the public key on the client should match with one of the entries inside the authorised_keys
file on the server and the public key of the server should match with one of the entres in the known_hosts
file on the client.
Unfortunately, when I manually try to match them they did not match fully (only first few characters match). It is important to note that the ssh connection still goes through without giving the -i <pemfile>
on the command line.
ssh openssl
New contributor
add a comment |
up vote
0
down vote
favorite
I have tried to match the public keys and private keys on both my client and server as well as the configuration files but cannot get my head around the mismatches. I can successfully connect to the server on ssh despite the mismatches. This is a bit worrying.
I will show exactly what is stored where.
Client: Mac
Server: Ubuntu (hosted on AWS)
Files on my local mac /Users/sm/.ssh directory
ls -la
Sanjays-iMac:.ssh sm$ ls -la
total 24
drwx------ 5 sm staff 160 26 Nov 21:29 .
drwxr-xr-x+ 59 sm staff 1888 26 Nov 21:29 ..
-rw------- 1 sm staff 1696 26 Nov 20:49 id_rsa
-rw-r--r--@ 1 sm staff 451 26 Nov 20:50 id_rsa.pub
-rw-r--r-- 1 sm staff 1151 26 Nov 21:08 known_hosts
Files on my ubuntu server:
ubuntu@ip-172-31-30-19:~/.ssh$ ls -la
total 12
drwx------ 2 ubuntu ubuntu 4096 Nov 26 14:37 .
drwxr-xr-x 8 ubuntu ubuntu 4096 Oct 30 18:02 ..
-rw------- 1 ubuntu ubuntu 391 May 25 2018 authorized_keys
Present working directory on Ubuntu:
ubuntu@ip-172-31-30-19:~/.ssh$ pwd
/home/ubuntu/.ssh
Contents of authorized_keys
file on the server:
ubuntu@ip-172-31-30-19:~/.ssh$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
(contents are chopped off for privacy reasons)
Similarly, there is a known_hosts file on my local server:
Sanjays-iMac:.ssh sm$ cat known_hosts
54.251.104.13 ecdsa-sha2-nistp256 AAAAE2VjZHNhLX..Xsb/RBY=
52.76.85.25 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI....hAkfLOc5g=
ec2-13-127-241-121.ap-south-1.compute.amazonaws.com,13.127.241.121 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN....fu5Co4vYB0=
ec2-13-232-81-251.ap-south-1.compute.amazonaws.com,13.232.81.251 ecdsa-sha2-nistp256 AAAAE2VjZHNhL....nhNcRyfu5Co4vYB0=
35.154.168.85 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNo....NcRyfu5Co4vYB0=
13.126.30.42 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTIt....NcRyfu5Co4vYB0=
(contents are chopped off for privacy reasons)
Now my question is:
What should be equal to what?
I would think that the public key on the client should match with one of the entries inside the authorised_keys
file on the server and the public key of the server should match with one of the entres in the known_hosts
file on the client.
Unfortunately, when I manually try to match them they did not match fully (only first few characters match). It is important to note that the ssh connection still goes through without giving the -i <pemfile>
on the command line.
ssh openssl
New contributor
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have tried to match the public keys and private keys on both my client and server as well as the configuration files but cannot get my head around the mismatches. I can successfully connect to the server on ssh despite the mismatches. This is a bit worrying.
I will show exactly what is stored where.
Client: Mac
Server: Ubuntu (hosted on AWS)
Files on my local mac /Users/sm/.ssh directory
ls -la
Sanjays-iMac:.ssh sm$ ls -la
total 24
drwx------ 5 sm staff 160 26 Nov 21:29 .
drwxr-xr-x+ 59 sm staff 1888 26 Nov 21:29 ..
-rw------- 1 sm staff 1696 26 Nov 20:49 id_rsa
-rw-r--r--@ 1 sm staff 451 26 Nov 20:50 id_rsa.pub
-rw-r--r-- 1 sm staff 1151 26 Nov 21:08 known_hosts
Files on my ubuntu server:
ubuntu@ip-172-31-30-19:~/.ssh$ ls -la
total 12
drwx------ 2 ubuntu ubuntu 4096 Nov 26 14:37 .
drwxr-xr-x 8 ubuntu ubuntu 4096 Oct 30 18:02 ..
-rw------- 1 ubuntu ubuntu 391 May 25 2018 authorized_keys
Present working directory on Ubuntu:
ubuntu@ip-172-31-30-19:~/.ssh$ pwd
/home/ubuntu/.ssh
Contents of authorized_keys
file on the server:
ubuntu@ip-172-31-30-19:~/.ssh$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
(contents are chopped off for privacy reasons)
Similarly, there is a known_hosts file on my local server:
Sanjays-iMac:.ssh sm$ cat known_hosts
54.251.104.13 ecdsa-sha2-nistp256 AAAAE2VjZHNhLX..Xsb/RBY=
52.76.85.25 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI....hAkfLOc5g=
ec2-13-127-241-121.ap-south-1.compute.amazonaws.com,13.127.241.121 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN....fu5Co4vYB0=
ec2-13-232-81-251.ap-south-1.compute.amazonaws.com,13.232.81.251 ecdsa-sha2-nistp256 AAAAE2VjZHNhL....nhNcRyfu5Co4vYB0=
35.154.168.85 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNo....NcRyfu5Co4vYB0=
13.126.30.42 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTIt....NcRyfu5Co4vYB0=
(contents are chopped off for privacy reasons)
Now my question is:
What should be equal to what?
I would think that the public key on the client should match with one of the entries inside the authorised_keys
file on the server and the public key of the server should match with one of the entres in the known_hosts
file on the client.
Unfortunately, when I manually try to match them they did not match fully (only first few characters match). It is important to note that the ssh connection still goes through without giving the -i <pemfile>
on the command line.
ssh openssl
New contributor
I have tried to match the public keys and private keys on both my client and server as well as the configuration files but cannot get my head around the mismatches. I can successfully connect to the server on ssh despite the mismatches. This is a bit worrying.
I will show exactly what is stored where.
Client: Mac
Server: Ubuntu (hosted on AWS)
Files on my local mac /Users/sm/.ssh directory
ls -la
Sanjays-iMac:.ssh sm$ ls -la
total 24
drwx------ 5 sm staff 160 26 Nov 21:29 .
drwxr-xr-x+ 59 sm staff 1888 26 Nov 21:29 ..
-rw------- 1 sm staff 1696 26 Nov 20:49 id_rsa
-rw-r--r--@ 1 sm staff 451 26 Nov 20:50 id_rsa.pub
-rw-r--r-- 1 sm staff 1151 26 Nov 21:08 known_hosts
Files on my ubuntu server:
ubuntu@ip-172-31-30-19:~/.ssh$ ls -la
total 12
drwx------ 2 ubuntu ubuntu 4096 Nov 26 14:37 .
drwxr-xr-x 8 ubuntu ubuntu 4096 Oct 30 18:02 ..
-rw------- 1 ubuntu ubuntu 391 May 25 2018 authorized_keys
Present working directory on Ubuntu:
ubuntu@ip-172-31-30-19:~/.ssh$ pwd
/home/ubuntu/.ssh
Contents of authorized_keys
file on the server:
ubuntu@ip-172-31-30-19:~/.ssh$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
(contents are chopped off for privacy reasons)
Similarly, there is a known_hosts file on my local server:
Sanjays-iMac:.ssh sm$ cat known_hosts
54.251.104.13 ecdsa-sha2-nistp256 AAAAE2VjZHNhLX..Xsb/RBY=
52.76.85.25 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI....hAkfLOc5g=
ec2-13-127-241-121.ap-south-1.compute.amazonaws.com,13.127.241.121 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN....fu5Co4vYB0=
ec2-13-232-81-251.ap-south-1.compute.amazonaws.com,13.232.81.251 ecdsa-sha2-nistp256 AAAAE2VjZHNhL....nhNcRyfu5Co4vYB0=
35.154.168.85 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNo....NcRyfu5Co4vYB0=
13.126.30.42 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTIt....NcRyfu5Co4vYB0=
(contents are chopped off for privacy reasons)
Now my question is:
What should be equal to what?
I would think that the public key on the client should match with one of the entries inside the authorised_keys
file on the server and the public key of the server should match with one of the entres in the known_hosts
file on the client.
Unfortunately, when I manually try to match them they did not match fully (only first few characters match). It is important to note that the ssh connection still goes through without giving the -i <pemfile>
on the command line.
ssh openssl
ssh openssl
New contributor
New contributor
New contributor
asked Nov 27 at 6:51
user30994
101
101
New contributor
New contributor
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
up vote
4
down vote
There are two kinds of keys: Server or host keys, which identify the server to the user, and user keys, which allow logging in.
The private host key of the server is stored in /etc/ssh/
. The corresponding public key is automatically added (after a prompt) to known_hosts
in ~/.ssh
on the client. The purpose of these keys is detect a man-in-the-middle (MITM) attack: If the host key suddenly changes when you type ssh ...
as usual, and you know nothing has changed on the server, you should get suspicious.
Usually you don't have to concern yourself with the host keys, they are managed automatically.
User keys allow authentication without entering passwords. User keys are managed on the client: You have created a key pair consisting of your public key id_rsa.pub
and your private key id_rsa
. They are stored on the client under ~/.ssh
. The public key is not used, it's just stored there to be available when needed. You must manually add the public key to the ~/.ssh/authorized_keys
for the corresponding user on the server. One key per line; if the authorized_keys
file is empty, a copy (e.g. via scp
and password) of id_rsa.pub
is enough.
So in your case, the
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
in the authorized_keys
file on the Ubuntu server must be equal to your id_rsa.pub
key on the Mac.
If it is equal and you still can't log in, something else is wrong.
... and if you don’t like manually editingauthorized_keys
,ssh-copy-id
can take care of it for you.
– Stephen Kitt
Nov 27 at 7:59
1
One advantage of editingauthorized_keys
manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.
– dirkt
Nov 27 at 8:04
Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important.
– Stephen Kitt
Nov 27 at 8:07
What you conclude at the end is actually my question. Your statement: "the entry in theauthorised_keys
file on the Ubuntu must be equal to yourid_rsa.pub
on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting:key_load_public: invalid format
. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.
– user30994
Nov 27 at 8:17
1
@user30994+ you revealed on another answer you usedopenssl rsa -pubout
to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Usessh-keygen -y -f privatefile
if you need to (re)generate the public key for OpenSSH.
– dave_thompson_085
2 days ago
|
show 2 more comments
up vote
1
down vote
The known_hosts
is from the server's sshd key - in /etc/ssh/*pub
add a comment |
up vote
1
down vote
Key Format Fun
From your comments listed on other answers, it looks like you may have a key format problem.
It is true that a cryptographic key created with one standardized program is the same mathematically as a key generated in another. However, a given cryptographic protocol expects keys in a given format.
Converting Keys
- openssl to ssh keys
Keys generated in openssl
and outputted in PEM format can be converted to ssh format using the ssh-keygen
program.
ssh-keygen -i -m pem -f key.pem
- ssh keys to PEM
Keys generated using ssh-keygen can be converted to PEM format:
ssh-keygen -e -m pem -f id_rsa.pub
- PGP to ssh keys
PGP keys generated in GPG can be converted to ssh format using the --export-ssh-key
option:
gpg --export-ssh-key <keyid>
Location of keys
As listed in other answers, the remote system requires the public key stored in ssh format in the ~/.ssh/authorized_keys
file. And the local system requires that the private key is:
- Stored as id_rsa in
~/.ssh
or
- Supplied using the
ssh -i
option
or
- Added to the ssh agent using
ssh-add
or
- Added to the ssh agent using GPG's
sshcontrol
file
Comparing Public Keys
In order to compare public keys, those keys must be in the same format. Otherwise, the keys won't look the same, even though they are the same objects mathematically. So, since you've indicated that you generated your ssh public key using openssl
in PEM format, the public key is probably not going to look the same as the one stored in the server's ~/.ssh/authorized_keys
file.
PEM format keys look like this:
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAr/CvdghgkYT1Z38d
...
NlBcCYnrjvfFAj5HQydWc9CfP02rdtCIewIDAQAB
-----END RSA PUBLIC KEY-----
SSH Public Keys look like this:
ssh-rsa AAAAB3N...voZypjC/Y2UFwJie...t20Ih7
PGP Public Keys look like this:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFN/ZjIBCADad3mv...
...
nE42ZvKt632ZAQ==
=EKbR
-----END PGP PUBLIC KEY BLOCK-----
So, make sure you are comparing keys in the same format.
add a comment |
up vote
0
down vote
The authorized_keys
file should have a line containing the contents of id_rsa.pub
, and the known_hosts
file should have a line containing the server's host key. (The server usually stores its host keys in a file under /etc/ssh/
.)
Also, id_rsa
should kind of match id_rsa.pub
in the sense that they need to be a key pair, but unless you mangle it manually, that's how ssh-keygen always places them.
I did not have an id_rsa.pub
so I generated a public key usingopenssl rsa -in mykey.pem -pubout
– user30994
Nov 27 at 8:26
@user30994 Hmm? Your question clearly lists yourid_rsa.pub
with a matchingid_rsa
?
– Bass
Nov 27 at 8:34
I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
– user30994
Nov 27 at 10:19
@user30994 ... You usedopenssl
to create a public key from a private key. However,ssh
usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key inssh
format ...ssh-keygen -i -m pem -f id_rsa.pem
... Please add your key generation process to your question
– RubberStamp
Nov 28 at 3:04
@RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or-o
since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed)ssh-keygen -y -f private
to generate OpenSSH public key.
– dave_thompson_085
2 days ago
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
There are two kinds of keys: Server or host keys, which identify the server to the user, and user keys, which allow logging in.
The private host key of the server is stored in /etc/ssh/
. The corresponding public key is automatically added (after a prompt) to known_hosts
in ~/.ssh
on the client. The purpose of these keys is detect a man-in-the-middle (MITM) attack: If the host key suddenly changes when you type ssh ...
as usual, and you know nothing has changed on the server, you should get suspicious.
Usually you don't have to concern yourself with the host keys, they are managed automatically.
User keys allow authentication without entering passwords. User keys are managed on the client: You have created a key pair consisting of your public key id_rsa.pub
and your private key id_rsa
. They are stored on the client under ~/.ssh
. The public key is not used, it's just stored there to be available when needed. You must manually add the public key to the ~/.ssh/authorized_keys
for the corresponding user on the server. One key per line; if the authorized_keys
file is empty, a copy (e.g. via scp
and password) of id_rsa.pub
is enough.
So in your case, the
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
in the authorized_keys
file on the Ubuntu server must be equal to your id_rsa.pub
key on the Mac.
If it is equal and you still can't log in, something else is wrong.
... and if you don’t like manually editingauthorized_keys
,ssh-copy-id
can take care of it for you.
– Stephen Kitt
Nov 27 at 7:59
1
One advantage of editingauthorized_keys
manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.
– dirkt
Nov 27 at 8:04
Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important.
– Stephen Kitt
Nov 27 at 8:07
What you conclude at the end is actually my question. Your statement: "the entry in theauthorised_keys
file on the Ubuntu must be equal to yourid_rsa.pub
on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting:key_load_public: invalid format
. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.
– user30994
Nov 27 at 8:17
1
@user30994+ you revealed on another answer you usedopenssl rsa -pubout
to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Usessh-keygen -y -f privatefile
if you need to (re)generate the public key for OpenSSH.
– dave_thompson_085
2 days ago
|
show 2 more comments
up vote
4
down vote
There are two kinds of keys: Server or host keys, which identify the server to the user, and user keys, which allow logging in.
The private host key of the server is stored in /etc/ssh/
. The corresponding public key is automatically added (after a prompt) to known_hosts
in ~/.ssh
on the client. The purpose of these keys is detect a man-in-the-middle (MITM) attack: If the host key suddenly changes when you type ssh ...
as usual, and you know nothing has changed on the server, you should get suspicious.
Usually you don't have to concern yourself with the host keys, they are managed automatically.
User keys allow authentication without entering passwords. User keys are managed on the client: You have created a key pair consisting of your public key id_rsa.pub
and your private key id_rsa
. They are stored on the client under ~/.ssh
. The public key is not used, it's just stored there to be available when needed. You must manually add the public key to the ~/.ssh/authorized_keys
for the corresponding user on the server. One key per line; if the authorized_keys
file is empty, a copy (e.g. via scp
and password) of id_rsa.pub
is enough.
So in your case, the
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
in the authorized_keys
file on the Ubuntu server must be equal to your id_rsa.pub
key on the Mac.
If it is equal and you still can't log in, something else is wrong.
... and if you don’t like manually editingauthorized_keys
,ssh-copy-id
can take care of it for you.
– Stephen Kitt
Nov 27 at 7:59
1
One advantage of editingauthorized_keys
manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.
– dirkt
Nov 27 at 8:04
Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important.
– Stephen Kitt
Nov 27 at 8:07
What you conclude at the end is actually my question. Your statement: "the entry in theauthorised_keys
file on the Ubuntu must be equal to yourid_rsa.pub
on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting:key_load_public: invalid format
. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.
– user30994
Nov 27 at 8:17
1
@user30994+ you revealed on another answer you usedopenssl rsa -pubout
to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Usessh-keygen -y -f privatefile
if you need to (re)generate the public key for OpenSSH.
– dave_thompson_085
2 days ago
|
show 2 more comments
up vote
4
down vote
up vote
4
down vote
There are two kinds of keys: Server or host keys, which identify the server to the user, and user keys, which allow logging in.
The private host key of the server is stored in /etc/ssh/
. The corresponding public key is automatically added (after a prompt) to known_hosts
in ~/.ssh
on the client. The purpose of these keys is detect a man-in-the-middle (MITM) attack: If the host key suddenly changes when you type ssh ...
as usual, and you know nothing has changed on the server, you should get suspicious.
Usually you don't have to concern yourself with the host keys, they are managed automatically.
User keys allow authentication without entering passwords. User keys are managed on the client: You have created a key pair consisting of your public key id_rsa.pub
and your private key id_rsa
. They are stored on the client under ~/.ssh
. The public key is not used, it's just stored there to be available when needed. You must manually add the public key to the ~/.ssh/authorized_keys
for the corresponding user on the server. One key per line; if the authorized_keys
file is empty, a copy (e.g. via scp
and password) of id_rsa.pub
is enough.
So in your case, the
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
in the authorized_keys
file on the Ubuntu server must be equal to your id_rsa.pub
key on the Mac.
If it is equal and you still can't log in, something else is wrong.
There are two kinds of keys: Server or host keys, which identify the server to the user, and user keys, which allow logging in.
The private host key of the server is stored in /etc/ssh/
. The corresponding public key is automatically added (after a prompt) to known_hosts
in ~/.ssh
on the client. The purpose of these keys is detect a man-in-the-middle (MITM) attack: If the host key suddenly changes when you type ssh ...
as usual, and you know nothing has changed on the server, you should get suspicious.
Usually you don't have to concern yourself with the host keys, they are managed automatically.
User keys allow authentication without entering passwords. User keys are managed on the client: You have created a key pair consisting of your public key id_rsa.pub
and your private key id_rsa
. They are stored on the client under ~/.ssh
. The public key is not used, it's just stored there to be available when needed. You must manually add the public key to the ~/.ssh/authorized_keys
for the corresponding user on the server. One key per line; if the authorized_keys
file is empty, a copy (e.g. via scp
and password) of id_rsa.pub
is enough.
So in your case, the
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev
in the authorized_keys
file on the Ubuntu server must be equal to your id_rsa.pub
key on the Mac.
If it is equal and you still can't log in, something else is wrong.
answered Nov 27 at 7:29
dirkt
16.2k21335
16.2k21335
... and if you don’t like manually editingauthorized_keys
,ssh-copy-id
can take care of it for you.
– Stephen Kitt
Nov 27 at 7:59
1
One advantage of editingauthorized_keys
manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.
– dirkt
Nov 27 at 8:04
Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important.
– Stephen Kitt
Nov 27 at 8:07
What you conclude at the end is actually my question. Your statement: "the entry in theauthorised_keys
file on the Ubuntu must be equal to yourid_rsa.pub
on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting:key_load_public: invalid format
. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.
– user30994
Nov 27 at 8:17
1
@user30994+ you revealed on another answer you usedopenssl rsa -pubout
to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Usessh-keygen -y -f privatefile
if you need to (re)generate the public key for OpenSSH.
– dave_thompson_085
2 days ago
|
show 2 more comments
... and if you don’t like manually editingauthorized_keys
,ssh-copy-id
can take care of it for you.
– Stephen Kitt
Nov 27 at 7:59
1
One advantage of editingauthorized_keys
manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.
– dirkt
Nov 27 at 8:04
Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important.
– Stephen Kitt
Nov 27 at 8:07
What you conclude at the end is actually my question. Your statement: "the entry in theauthorised_keys
file on the Ubuntu must be equal to yourid_rsa.pub
on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting:key_load_public: invalid format
. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.
– user30994
Nov 27 at 8:17
1
@user30994+ you revealed on another answer you usedopenssl rsa -pubout
to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Usessh-keygen -y -f privatefile
if you need to (re)generate the public key for OpenSSH.
– dave_thompson_085
2 days ago
... and if you don’t like manually editing
authorized_keys
, ssh-copy-id
can take care of it for you.– Stephen Kitt
Nov 27 at 7:59
... and if you don’t like manually editing
authorized_keys
, ssh-copy-id
can take care of it for you.– Stephen Kitt
Nov 27 at 7:59
1
1
One advantage of editing
authorized_keys
manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.– dirkt
Nov 27 at 8:04
One advantage of editing
authorized_keys
manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.– dirkt
Nov 27 at 8:04
Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important.
– Stephen Kitt
Nov 27 at 8:07
Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important.
– Stephen Kitt
Nov 27 at 8:07
What you conclude at the end is actually my question. Your statement: "the entry in the
authorised_keys
file on the Ubuntu must be equal to your id_rsa.pub
on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting: key_load_public: invalid format
. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.– user30994
Nov 27 at 8:17
What you conclude at the end is actually my question. Your statement: "the entry in the
authorised_keys
file on the Ubuntu must be equal to your id_rsa.pub
on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting: key_load_public: invalid format
. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.– user30994
Nov 27 at 8:17
1
1
@user30994+ you revealed on another answer you used
openssl rsa -pubout
to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Use ssh-keygen -y -f privatefile
if you need to (re)generate the public key for OpenSSH.– dave_thompson_085
2 days ago
@user30994+ you revealed on another answer you used
openssl rsa -pubout
to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Use ssh-keygen -y -f privatefile
if you need to (re)generate the public key for OpenSSH.– dave_thompson_085
2 days ago
|
show 2 more comments
up vote
1
down vote
The known_hosts
is from the server's sshd key - in /etc/ssh/*pub
add a comment |
up vote
1
down vote
The known_hosts
is from the server's sshd key - in /etc/ssh/*pub
add a comment |
up vote
1
down vote
up vote
1
down vote
The known_hosts
is from the server's sshd key - in /etc/ssh/*pub
The known_hosts
is from the server's sshd key - in /etc/ssh/*pub
answered Nov 27 at 7:13
danblack
3416
3416
add a comment |
add a comment |
up vote
1
down vote
Key Format Fun
From your comments listed on other answers, it looks like you may have a key format problem.
It is true that a cryptographic key created with one standardized program is the same mathematically as a key generated in another. However, a given cryptographic protocol expects keys in a given format.
Converting Keys
- openssl to ssh keys
Keys generated in openssl
and outputted in PEM format can be converted to ssh format using the ssh-keygen
program.
ssh-keygen -i -m pem -f key.pem
- ssh keys to PEM
Keys generated using ssh-keygen can be converted to PEM format:
ssh-keygen -e -m pem -f id_rsa.pub
- PGP to ssh keys
PGP keys generated in GPG can be converted to ssh format using the --export-ssh-key
option:
gpg --export-ssh-key <keyid>
Location of keys
As listed in other answers, the remote system requires the public key stored in ssh format in the ~/.ssh/authorized_keys
file. And the local system requires that the private key is:
- Stored as id_rsa in
~/.ssh
or
- Supplied using the
ssh -i
option
or
- Added to the ssh agent using
ssh-add
or
- Added to the ssh agent using GPG's
sshcontrol
file
Comparing Public Keys
In order to compare public keys, those keys must be in the same format. Otherwise, the keys won't look the same, even though they are the same objects mathematically. So, since you've indicated that you generated your ssh public key using openssl
in PEM format, the public key is probably not going to look the same as the one stored in the server's ~/.ssh/authorized_keys
file.
PEM format keys look like this:
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAr/CvdghgkYT1Z38d
...
NlBcCYnrjvfFAj5HQydWc9CfP02rdtCIewIDAQAB
-----END RSA PUBLIC KEY-----
SSH Public Keys look like this:
ssh-rsa AAAAB3N...voZypjC/Y2UFwJie...t20Ih7
PGP Public Keys look like this:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFN/ZjIBCADad3mv...
...
nE42ZvKt632ZAQ==
=EKbR
-----END PGP PUBLIC KEY BLOCK-----
So, make sure you are comparing keys in the same format.
add a comment |
up vote
1
down vote
Key Format Fun
From your comments listed on other answers, it looks like you may have a key format problem.
It is true that a cryptographic key created with one standardized program is the same mathematically as a key generated in another. However, a given cryptographic protocol expects keys in a given format.
Converting Keys
- openssl to ssh keys
Keys generated in openssl
and outputted in PEM format can be converted to ssh format using the ssh-keygen
program.
ssh-keygen -i -m pem -f key.pem
- ssh keys to PEM
Keys generated using ssh-keygen can be converted to PEM format:
ssh-keygen -e -m pem -f id_rsa.pub
- PGP to ssh keys
PGP keys generated in GPG can be converted to ssh format using the --export-ssh-key
option:
gpg --export-ssh-key <keyid>
Location of keys
As listed in other answers, the remote system requires the public key stored in ssh format in the ~/.ssh/authorized_keys
file. And the local system requires that the private key is:
- Stored as id_rsa in
~/.ssh
or
- Supplied using the
ssh -i
option
or
- Added to the ssh agent using
ssh-add
or
- Added to the ssh agent using GPG's
sshcontrol
file
Comparing Public Keys
In order to compare public keys, those keys must be in the same format. Otherwise, the keys won't look the same, even though they are the same objects mathematically. So, since you've indicated that you generated your ssh public key using openssl
in PEM format, the public key is probably not going to look the same as the one stored in the server's ~/.ssh/authorized_keys
file.
PEM format keys look like this:
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAr/CvdghgkYT1Z38d
...
NlBcCYnrjvfFAj5HQydWc9CfP02rdtCIewIDAQAB
-----END RSA PUBLIC KEY-----
SSH Public Keys look like this:
ssh-rsa AAAAB3N...voZypjC/Y2UFwJie...t20Ih7
PGP Public Keys look like this:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFN/ZjIBCADad3mv...
...
nE42ZvKt632ZAQ==
=EKbR
-----END PGP PUBLIC KEY BLOCK-----
So, make sure you are comparing keys in the same format.
add a comment |
up vote
1
down vote
up vote
1
down vote
Key Format Fun
From your comments listed on other answers, it looks like you may have a key format problem.
It is true that a cryptographic key created with one standardized program is the same mathematically as a key generated in another. However, a given cryptographic protocol expects keys in a given format.
Converting Keys
- openssl to ssh keys
Keys generated in openssl
and outputted in PEM format can be converted to ssh format using the ssh-keygen
program.
ssh-keygen -i -m pem -f key.pem
- ssh keys to PEM
Keys generated using ssh-keygen can be converted to PEM format:
ssh-keygen -e -m pem -f id_rsa.pub
- PGP to ssh keys
PGP keys generated in GPG can be converted to ssh format using the --export-ssh-key
option:
gpg --export-ssh-key <keyid>
Location of keys
As listed in other answers, the remote system requires the public key stored in ssh format in the ~/.ssh/authorized_keys
file. And the local system requires that the private key is:
- Stored as id_rsa in
~/.ssh
or
- Supplied using the
ssh -i
option
or
- Added to the ssh agent using
ssh-add
or
- Added to the ssh agent using GPG's
sshcontrol
file
Comparing Public Keys
In order to compare public keys, those keys must be in the same format. Otherwise, the keys won't look the same, even though they are the same objects mathematically. So, since you've indicated that you generated your ssh public key using openssl
in PEM format, the public key is probably not going to look the same as the one stored in the server's ~/.ssh/authorized_keys
file.
PEM format keys look like this:
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAr/CvdghgkYT1Z38d
...
NlBcCYnrjvfFAj5HQydWc9CfP02rdtCIewIDAQAB
-----END RSA PUBLIC KEY-----
SSH Public Keys look like this:
ssh-rsa AAAAB3N...voZypjC/Y2UFwJie...t20Ih7
PGP Public Keys look like this:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFN/ZjIBCADad3mv...
...
nE42ZvKt632ZAQ==
=EKbR
-----END PGP PUBLIC KEY BLOCK-----
So, make sure you are comparing keys in the same format.
Key Format Fun
From your comments listed on other answers, it looks like you may have a key format problem.
It is true that a cryptographic key created with one standardized program is the same mathematically as a key generated in another. However, a given cryptographic protocol expects keys in a given format.
Converting Keys
- openssl to ssh keys
Keys generated in openssl
and outputted in PEM format can be converted to ssh format using the ssh-keygen
program.
ssh-keygen -i -m pem -f key.pem
- ssh keys to PEM
Keys generated using ssh-keygen can be converted to PEM format:
ssh-keygen -e -m pem -f id_rsa.pub
- PGP to ssh keys
PGP keys generated in GPG can be converted to ssh format using the --export-ssh-key
option:
gpg --export-ssh-key <keyid>
Location of keys
As listed in other answers, the remote system requires the public key stored in ssh format in the ~/.ssh/authorized_keys
file. And the local system requires that the private key is:
- Stored as id_rsa in
~/.ssh
or
- Supplied using the
ssh -i
option
or
- Added to the ssh agent using
ssh-add
or
- Added to the ssh agent using GPG's
sshcontrol
file
Comparing Public Keys
In order to compare public keys, those keys must be in the same format. Otherwise, the keys won't look the same, even though they are the same objects mathematically. So, since you've indicated that you generated your ssh public key using openssl
in PEM format, the public key is probably not going to look the same as the one stored in the server's ~/.ssh/authorized_keys
file.
PEM format keys look like this:
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAr/CvdghgkYT1Z38d
...
NlBcCYnrjvfFAj5HQydWc9CfP02rdtCIewIDAQAB
-----END RSA PUBLIC KEY-----
SSH Public Keys look like this:
ssh-rsa AAAAB3N...voZypjC/Y2UFwJie...t20Ih7
PGP Public Keys look like this:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFN/ZjIBCADad3mv...
...
nE42ZvKt632ZAQ==
=EKbR
-----END PGP PUBLIC KEY BLOCK-----
So, make sure you are comparing keys in the same format.
answered Nov 28 at 4:03
RubberStamp
1,7201418
1,7201418
add a comment |
add a comment |
up vote
0
down vote
The authorized_keys
file should have a line containing the contents of id_rsa.pub
, and the known_hosts
file should have a line containing the server's host key. (The server usually stores its host keys in a file under /etc/ssh/
.)
Also, id_rsa
should kind of match id_rsa.pub
in the sense that they need to be a key pair, but unless you mangle it manually, that's how ssh-keygen always places them.
I did not have an id_rsa.pub
so I generated a public key usingopenssl rsa -in mykey.pem -pubout
– user30994
Nov 27 at 8:26
@user30994 Hmm? Your question clearly lists yourid_rsa.pub
with a matchingid_rsa
?
– Bass
Nov 27 at 8:34
I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
– user30994
Nov 27 at 10:19
@user30994 ... You usedopenssl
to create a public key from a private key. However,ssh
usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key inssh
format ...ssh-keygen -i -m pem -f id_rsa.pem
... Please add your key generation process to your question
– RubberStamp
Nov 28 at 3:04
@RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or-o
since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed)ssh-keygen -y -f private
to generate OpenSSH public key.
– dave_thompson_085
2 days ago
add a comment |
up vote
0
down vote
The authorized_keys
file should have a line containing the contents of id_rsa.pub
, and the known_hosts
file should have a line containing the server's host key. (The server usually stores its host keys in a file under /etc/ssh/
.)
Also, id_rsa
should kind of match id_rsa.pub
in the sense that they need to be a key pair, but unless you mangle it manually, that's how ssh-keygen always places them.
I did not have an id_rsa.pub
so I generated a public key usingopenssl rsa -in mykey.pem -pubout
– user30994
Nov 27 at 8:26
@user30994 Hmm? Your question clearly lists yourid_rsa.pub
with a matchingid_rsa
?
– Bass
Nov 27 at 8:34
I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
– user30994
Nov 27 at 10:19
@user30994 ... You usedopenssl
to create a public key from a private key. However,ssh
usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key inssh
format ...ssh-keygen -i -m pem -f id_rsa.pem
... Please add your key generation process to your question
– RubberStamp
Nov 28 at 3:04
@RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or-o
since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed)ssh-keygen -y -f private
to generate OpenSSH public key.
– dave_thompson_085
2 days ago
add a comment |
up vote
0
down vote
up vote
0
down vote
The authorized_keys
file should have a line containing the contents of id_rsa.pub
, and the known_hosts
file should have a line containing the server's host key. (The server usually stores its host keys in a file under /etc/ssh/
.)
Also, id_rsa
should kind of match id_rsa.pub
in the sense that they need to be a key pair, but unless you mangle it manually, that's how ssh-keygen always places them.
The authorized_keys
file should have a line containing the contents of id_rsa.pub
, and the known_hosts
file should have a line containing the server's host key. (The server usually stores its host keys in a file under /etc/ssh/
.)
Also, id_rsa
should kind of match id_rsa.pub
in the sense that they need to be a key pair, but unless you mangle it manually, that's how ssh-keygen always places them.
answered Nov 27 at 8:09
Bass
21113
21113
I did not have an id_rsa.pub
so I generated a public key usingopenssl rsa -in mykey.pem -pubout
– user30994
Nov 27 at 8:26
@user30994 Hmm? Your question clearly lists yourid_rsa.pub
with a matchingid_rsa
?
– Bass
Nov 27 at 8:34
I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
– user30994
Nov 27 at 10:19
@user30994 ... You usedopenssl
to create a public key from a private key. However,ssh
usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key inssh
format ...ssh-keygen -i -m pem -f id_rsa.pem
... Please add your key generation process to your question
– RubberStamp
Nov 28 at 3:04
@RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or-o
since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed)ssh-keygen -y -f private
to generate OpenSSH public key.
– dave_thompson_085
2 days ago
add a comment |
I did not have an id_rsa.pub
so I generated a public key usingopenssl rsa -in mykey.pem -pubout
– user30994
Nov 27 at 8:26
@user30994 Hmm? Your question clearly lists yourid_rsa.pub
with a matchingid_rsa
?
– Bass
Nov 27 at 8:34
I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
– user30994
Nov 27 at 10:19
@user30994 ... You usedopenssl
to create a public key from a private key. However,ssh
usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key inssh
format ...ssh-keygen -i -m pem -f id_rsa.pem
... Please add your key generation process to your question
– RubberStamp
Nov 28 at 3:04
@RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or-o
since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed)ssh-keygen -y -f private
to generate OpenSSH public key.
– dave_thompson_085
2 days ago
I did not have an id_
rsa.pub
so I generated a public key using openssl rsa -in mykey.pem -pubout
– user30994
Nov 27 at 8:26
I did not have an id_
rsa.pub
so I generated a public key using openssl rsa -in mykey.pem -pubout
– user30994
Nov 27 at 8:26
@user30994 Hmm? Your question clearly lists your
id_rsa.pub
with a matching id_rsa
?– Bass
Nov 27 at 8:34
@user30994 Hmm? Your question clearly lists your
id_rsa.pub
with a matching id_rsa
?– Bass
Nov 27 at 8:34
I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
– user30994
Nov 27 at 10:19
I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
– user30994
Nov 27 at 10:19
@user30994 ... You used
openssl
to create a public key from a private key. However, ssh
usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key in ssh
format ... ssh-keygen -i -m pem -f id_rsa.pem
... Please add your key generation process to your question– RubberStamp
Nov 28 at 3:04
@user30994 ... You used
openssl
to create a public key from a private key. However, ssh
usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key in ssh
format ... ssh-keygen -i -m pem -f id_rsa.pem
... Please add your key generation process to your question– RubberStamp
Nov 28 at 3:04
@RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or
-o
since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed) ssh-keygen -y -f private
to generate OpenSSH public key.– dave_thompson_085
2 days ago
@RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or
-o
since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed) ssh-keygen -y -f private
to generate OpenSSH public key.– dave_thompson_085
2 days ago
add a comment |
user30994 is a new contributor. Be nice, and check out our Code of Conduct.
user30994 is a new contributor. Be nice, and check out our Code of Conduct.
user30994 is a new contributor. Be nice, and check out our Code of Conduct.
user30994 is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484378%2fhow-are-the-public-and-private-keys-stored-and-related-on-both-client-and-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown