# Lab 8: SSH and SSL
## *Kseniya Evdokimova*
---
## **Questions to answer:**
### 1. Generate ssh key pair with different than in the excercise encryption algorithm. Use those keys to access a remote machine (VM for example). Provide all necessary secure configuration.
**First steps are to create ssh directory and limit access rights:**
`$mkdir -p ~/.ssh && chmod 700 ~/.ssh`
**And then to create config file and limit access rights to it:**
`$touch ~/.ssh/config && chmod 600 ~/.ssh/config`

**Next step is to create a key pair on the machine.** In the exercise rsa by default was used. Let's estimate the encryption algorithms:
SSH supports several public key algorithms for authentication keys. These include:

- **rsa** - an old algorithm based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm may be advisable. It is quite possible the RSA algorithm will become practically breakable in the foreseeable future. All SSH clients support this algorithm.
- **dsa** - an old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
- **ecdsa**- a new Digital Signature Algorithm standarized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. We would recommend always using it with 521 bits, since the keys are still small and probably more secure than the smaller keys (even though they should be safe as well). Most SSH clients now support this algorithm.
- **ed25519** - this is a new algorithm added in OpenSSH. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable.

Therefore, after estimation I will choose *ecdsa with 521 bits* key size:
`$ ssh-keygen -t ecdsa -b 521`
- -b “Bits” This option specifies the number of bits in the key. The regulations that govern the use case for SSH may require a specific key length to be used.
- -t “Type” This option specifies the type of key to be created. Commonly used value for elliptic curve DSA keys is ecdsa.


The previous steps are made on VirtualBox.
The same I do on Innopolis VM:

**Copying the Public Key to Your Ubuntu Server**
The quickest way to copy your public key to the Ubuntu host is to use a utility called ssh-copy-id by calling `$ssh-copy-id username@remote_host`:
The same will happen for VMs vice versa.

**Authenticating to Your Ubuntu Server Using SSH Keys**
If you have successfully completed one of the procedures above, you should be able to log into the remote host without providing the remote account’s password.
The basic process is the same:
`$ssh username@remote_host`
Type “yes” and then press ENTER to continue.
Now, ssh to another VM is available without further password providing:

Open up the SSH daemon’s configuration file:
`$sudo vim /etc/ssh/sshd_config`

Inside the file, I've searched for a directive called PasswordAuthentication, uncommented it and set the value to no. This will disable an ability to log in via SSH using account passwords:
/etc/ssh/sshd_config

Saved and closed the file. Activated these changes by restarting the sshd service:

Opened up a new terminal window and tested that the SSH service is functioning correctly before closing my current session:

Once verified the SSH service is functioning properly, we can safely close all current server sessions.
The SSH daemon on my Ubuntu server now only responds to SSH-key-based authentication password-based logins have been disabled.
- Alternative way to disable root login by adding the following line to sshd_config:

PermitRootLogin no
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

- All password-based logins must be disabled. Only public key based logins are allowed. Add the following in your sshd_config file:

AuthenticationMethods publickey
PubkeyAuthentication yes

- Limit Users’ ssh access
`AllowUsers user1 user2`
Alternatively, you can allow all users to login via SSH but deny only a few users, with the following line in sshd_config:
`DenyUsers user3 user4`

### 2. Create root certificate CA and generate your domain certificate with public and private keys. Generate a Certificate Signing Request for your domain certificate then generate your certificate with use the CA’s signature to form a certificate using CA cirtificate, set expiration days to 365. Show your content of certificate with attributes: ISSUER, Validity, Serial Number, Subject etc. Convert your certificate to DER format (install openssl tool with apt/yum). Keep these certificates, it will be used for the next LAB.

**Creating a CA-Signed Certificate With Our Own CA**

**Create Root Key**
We can be our own certificate authority (CA) by creating a self-signed root CA certificate, then install it as a trusted certificate in the local browser.
- **des3** - option that helps to encrypt the key; user will be asked for a pass phrase
- **out** option specifies the root key name
- **4096** is a number of bits of an rsa key

**Create and self sign the Root Certificate**
`$openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt`
- -req - request a certificate
- -x509 - certificate standard
new generate a new certificate request
- -key - keyname to create a certificate with
- -sha256 - encryption method
- -days - expiration time in days
Here we used our root key to create the root certificate that needs to be distributed in all the computers that have to trust us and embed it in the systems for encryption/signing .

**Create a certificate**
**Create the certificate key**
`$openssl genrsa -out mydomain.com.key 2048`

**Create the signing (csr), interactive method**
`openssl req -new -key mydomain.com.key -out mydomain.com.csr`

*Verify the csr’s content*
`openssl req -in mydomain.com.csr -noout -text`

**Generate the certificate using the mydomain csr and key along with the CA Root key**
As was asked in the task, by -days we will set the value to 365:
`Generate the certificate using the mydomain csr and key along with the CA Root key`

*Verify the certificate’s content*
`openssl x509 -in kseniyadomain.com.crt -text -noout`

**Convert your certificate to DER format**
The DER format is usually used with Java. Let’s convert our PEM-encoded certificate to a DER-encoded certificate:
`$openssl x509 -in kseniyadomain.crt -outform der -out kseniyadomain.der`