Guide | Asymmetric Encryption | SSH RSA Login
This blog is called EncryptedGardens – so I really wanted to create this post to get the most out of my domain name. Asymmetric encryption is really hard to understand – at least it was for me. Generally, the algorithm deals with two types of keys. A public key and a private key. A private key is kept secret on a server or user, and can be used to encrypt outgoing messages with the and decrypt incoming messages to the client or server. A public key, as the name suggests is held by a client or server and is known by everyone that wants to communicate with the private key owner. Clients can encrypt messages going out with the server’s public key, and the server can decrypt these messages with its private key. This process can be reversed, the server can send messages encrypted with its private key, and the clients can decrypt this message with the server’s public key.
One way I really like to explain asymmetric encryption is through social security numbers and people’s names. Let’s say for instance everyone had a unique name (because public keys are unique). However, I know John Doe’s name, but not his social security number. But, John wants to send a message to encryptedgardens. John could encrypt a message with encryptedgardens public key (which would be the like domain name, because it is widely known), and encryptedgardens could decrypt the message with encryptedgardens’ private key. This would validate that John DID send this message to encryptedgardens because I can decrypt it with encryptedgardens’ private key, and not anybody else. This process can be reversed, encryptedgardens can reply with either John’s public key or with encryptedgardens’ private key. Respectively, John can open the message with his private key, or with encryptedgardens’ public key.
Applying it SSH
Let’s look into SSH for a real life example.
I used the command ssh-keygen – which is a tool for creating (or generating) a set of authentication key pairs for SSH. This keygen is for my client, in the image, I’m using megaman-exe as my user, then I will send it to this website: encryptedgardens.com
[username@local-device]$ ssh-keygen
Next, I need the server to know who I am – how I do this is by sending my public key to the server (in this case it’s encryptedgardens.com) so that they can decrypt my messages with my public key. Like stated earlier, my messages will be encrypted with my private key- I should be the only one that has access to my private key – then the server will decrypt the message with the given public key. This process ensures two things:
1) The message is confidential – meaning that only the sender and intended recipients are the only people that can read the message
2) The message is non-repudiated – meaning that the message can only be written and sent by the sender.
Below is a basic process on what happens.
(John’s message) -> encrypted with John’s private key -> (John’s encrypted message) -> sent to server -> decrypted with John’s public key -> (John’s message)
And now I’m going to allow my server to accept my private key, we can do this pretty easily with the ssh-copy-id command. Disregard the ‘-p’ value, I don’t advertise my 22 port on the public network, because there’s a lot of bots that go around. [This is before I migrated my website]
[username@local-device]$ ssh-copy-id root@encryptedgardens.com
That’s basically it. Now I can log in more securely. I can also technically do it without a password if I didn’t put a password value during my private key creation.
The next thing is to ssh into your device, the general format is the following:
[username@local-device]$ ssh user@domain_or_IPAddress
