Background

Terms in Encryption

MD5 & SHA-1 & SHA-2

Hash functions are designed for digesting messages.

  • MD5: output 128 bit hash value, no longer safe.
  • SHA-1: Secure Hash Algorithm, output 160-bit value, was considered safer than MD5, but no longer safe now.
  • SHA-2: it has many variants, the most commonly used one is SAH-256, outputs 256 bits, it is 30% slower compared with md5 or sha-1.

RSA & DSA

RSA is an asymmetric encryption algorithm, A.K.A. public/private key pair. It can be used for 2 purposes:

1. Encryption

Encryption: A -> B;
A encrypt messages with the B's private key then send to B,
then B uses its own private key to descypt the message.

2. Digital Signature

If you reverse the keys for RSA, it can be used to generate a digital signature.

Signature: A -> B;
A encrypt messages with the A's private key then send to B,
then B can only use A's public key to descypt the message.

STEPS to generate a sign:

  1. Digest message with hash function, generate a blob
  2. Encrypt the blob with its own private key, RSA is a widely used algorithm.

NOTE: In term RSA in digital signature can have difference senses, in some articles

1. RSA: SHA1withRSA, SHA-1, RSA key length recommended 2048
2. RSA2: SAH256withRSA, SHA-2, RSA key length >= 2048

DSA: Digital Signature Algorithm, based on discrete logarithms computation.

Diffwith RSA:

1. DSA is using symmetric key.
2. DSA can only be used for signature, not encryption.
3. DSA is 100 faster compared with RSA.
4. DSA is safer.
5. DSA is not supported for sshv1, only sshv2.

SSHv1 vs. SSHv2

In version 1 of the SSH protocol, the server has a RSA key (always) and the client asymmetrically encrypts a random blob with the server’s public key. The random blob is then used as basis for the session key which will be used to encrypt the data.

In version 2 of the SSH protocol, client and server use Diffie-Hellman (or an elliptic curve variant thereof) to established a shared session key. The server signs his half of the protocol with his key, which might be RSA or DSA.

In general, for SSH, the client makes sure that it talks to the right server by remembering the public key of each server (that’s the .ssh/known_hosts file).

SSH config

SSH (Secure Shell): ssh user@hostname requires typing password each time which can be annoying. Using SSH Key-Based Authentication is an alternative.

Generate a key pair:

In you local computer(Mac/Linux), generate a key pair

ssh-kengen

you will see:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):

You can save to another directory if you know what you are doing. It will then generate a id_rsa and id_rsa.pub, the private and public key pair.

It then will prompt options for you to configure, won’t go wrong, but you would better leave the pass-phase blank, otherwise you will have to type extra password to using this key pair for ssh authentication.

Copy the public key to your remote server:

Copy the id_rsa.pub to the server.

ssh-copy-id use@remote_host

This will copy the contents of id_rsa.pub into a file called .ssh/authorized_keys in the remote user’s home directory.

If you don’t have ssh-copy-id in you local, you can simple copy it manually by scp, e.g.

scp ~/.ssh/id_rsa.pub user@remote_host:~/.ssh/authorized_keys

Set config for sshing to the remote server:

Then you will be able to ssh to remote host by:

ssh -i ~/.ssh/id_rsa user@remote_host

to make it even more simpler:

vim ~/.ssh/config

Add these lines to it:

Host my_remote_server
    User user
    HostName ip4
    IdentityFile ~/.ssh/github_key

Then you can just do ssh my_remote_server.

Reverse Tunnel:

SSH from remote server to a router nested host (your local)

Option1: setup port forwarding in the local host, say configure router’s port 3000 to map to local host’s port 22.

Option2: open a live connection from the firewall nested host

target-nested-host$ ssh -f -N -T -R22222:localhost:22 my-server-host

Then, you should be able to ssh into a public server host:

operational-host$ ssh my-server-host

Then in the remote shell:

my-server-host$ ssh -i key_to_target_host -p 22222 localhost

Use case; I have a remote server and a linux box that connected to a router, I want someone else to connect to the box via ssh, and due to my complex router-network setup, this is actually the simplest solution.

General usage

Generate public-private key pair with openssl, the last number is the key length, RSA2 requires 2048 minimum.

openssl genrsa -out keypair.pem 2048

To extract the public part use the rsa context:

openssl rsa -in keypair.pem -pubout -out publickey.crt

Convert the original keypair to PKCS#8 format with pscs8 context:

openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.pem

View contexts of PEM certificate file:

openssl x509 -in keypair.pem -text -noout

Convert PEM to DER:

openssl x509 -inform PEM -outform DER -in CERTIFICATE.pem -out CERTIFICATE.der

NOTE:

  1. PEM: Privacy Enhanced Mail, is the most common format for X.509 certificates and cryptographic keys. A PEM file is a text file containing one or more items in Base64 ASCII encoding, each with plain-text headers and footers (e.g. —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–). A single PEM file could contain an end-entity certificate, a private key, or multiple certificates forming a complete chain of trust. Most certificate files downloaded from SSL.com will be in PEM format.
  2. DER (Distinguished Encoding Rules) is a binary encoding for X.509 certificates and private keys. Unlike PEM, DER-encoded files do not contain plain text statements such as —–BEGIN CERTIFICATE—–. DER files are most commonly seen in Java contexts.
  3. PEM files are usually seen with the extensions .crt, .pem, .cer, and .key (for private keys)
  4. DER-encoded files are usually found with the extensions .der and .cer.