Update sshusingkeys.md

pull/416/head
cdg123 2024-10-04 16:23:53 +01:00 committed by GitHub
parent b758b3b5a2
commit dfb0d23831
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 119 additions and 23 deletions

View File

@ -3,43 +3,139 @@
SSH access using public key authentication
==========================================
In OpenIPC remote access via SSH is handled by the Dropbear module [see https://github.com/mkj/dropbear]
## Introduction
OpenIPC uses a package called Dropbear for managing **S**ecure **SH**ell (SSH) client connections. By default this is configured to use the root username and associated password however it can be made both more secure and simpler by making it passwordless.
To enable password free access and enhance security you can simply configure the required key details by completing the following steps:
If you are new to understanding SSH and PKI then it is suggested you read one of the [many articles](https://www.ssh.com/academy/ssh) already written for a full understanding however unless you need to debug why connections are failing in detail the basic understanding of the terms client, server and keys should be sufficient as described here.
The term PKI is used to describe all of the elements used for creating a secure encrypted connection between two devices. These devices are referred to as clients or servers. In simple terms the target machine you are connecting to is the server and the host machine you are connecting from is the client.
To create a secure connection your client is setup with a 'private' key and each server you access is setup with a matching 'public' key. The public key is exchanged during the connection process and tested to make sure it matches with the private key.
Your private key is the only thing that can decrypt data that has been encoded with the matching public key hence why your private key must be safely guarded and the public key part is what we share.
In the initial connection phase there is also a check that the server is the correct device and so these identities are stored in a 'known_hosts' file.
There are many algorithms that have been implemented over the years to ensure connections are extremely hard to break into and so with modern computing power this has meant some of the earlier ones are no longer supported. Modern popular public key encryption standards include RSA (RivestShamirAdleman) and EdDSA (Edwards-curve Digital Signature Algorithm).
There are a few things to watch out for to ensure a successful connection as the security settings, for example, are crucial on the files and folders so ensure you follow the instructions step by step below.
This article has been written on how to achieve this using the standard SSH clients included with most modern Linux and Windows distributions i.e. OpenSSH.
## OpenIPC camera with public key (most common setup)
For the most common configuration, where we have the private key as described above, we first need to generate a key pair and securely get our key to the camera into the authorized_key file.
#### Step 1: connect to the camera
First we need to establish a terminal connection to the camera using the traditional way with your current root password
e.g. ssh root@192.168.1.10. This is because we need to find the existing private key file so we can get the public key for our client end configuration.
First we need to establish a terminal connection to the camera using the traditional way with your current root password (as per the Majestic web login) e.g. ``` ssh root@192.168.1.10 ```
#### Step 2: check there is a symlink to the dropbear files
When using clients for remote login they look for two key files, authorized_keys and known_hosts, which reside in the users .ssh directory in both Windows and Linux systems.
In OpenIPC these files are actually located in the /etc/dropbear directory and so by default there is a link created in the root user home directory (/root) that points to the required files
and will look like this **.ssh -> /etc/dropbear/**
When using SSH there are two key files, authorized_keys and known_hosts, which are expected to be found in the users **.ssh** directory in both Windows and Linux systems.
If this has been deleted or changed in your camera then create it with the command **ln -s ~/.ssh /etc/dropbear**
As OpenIPC uses Dropbear, and not OpenSSH, these files are actually located in the /etc/dropbear directory and so on the camera there is a link created in the root user home directory (/root) that points to the required files and will look like this **.ssh -> /etc/dropbear/**.
#### Step 3: get the public key
There are two keys used in the public key authentication process a private key and a public key. As their names suggest the private key must be kept secure and not shared with anyone however the public key is what we want to get and use in the client end.
If this is missing then it is critical to recreate it with the command **ln -s ~/.ssh /etc/dropbear**
By default dropbear creates a file named **dropbear_ed25519_host_key** with is located in the the **/etc/dropbear** directory and this is the private key.
Logout again from the camera.
We need to use the dropbearkey tool to get the public key
#### Step 3: create a key pair
To create our private and public key pair we use **ssh-keygen**. This gives us options on what type of key to create and it is recommended you use either the RSA or EdDSA type with EdDSA being the newest and potentially will take longer to break than the older RSA format.
at the prompt enter dropbearkey -y -f /etc/dropbear/dropbear_ed25519_host_key
To create the key pair on your **client** machine open a terminal window enter ```ssh-keygen -t ed25519``` .
This will display the public key which we need. Simply highlight the text on screen after the statement Public key portion is: and copy it to your clipboard or a text file for temporary storage.
You will be prompted with a few questions, simply press enter to accept the defaults.
#### Step 4: configure your client
On your client machine find your .ssh directory typically in the user home direcotry so on linux ~/.ssh or in windows the /users/yourloginnanme/.ssh
You should see an output similar to.
Paste in the copied text on a single line and save the file
```Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/<yourusername>/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<yourusername>/.ssh/id_ed25519
Your public key has been saved in /home/<yourusername>/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:caaCz/2+eXiIbIPTkIo0/1+7njo8+7tHzaVVA4gworc <yourusername>@<yourmachinename>
The key's randomart image is:
+--[ED25519 256]--+
| . o. . ... |
| . . .. . ..|
| . . . o o|
| ... = o|
| .E..S o + |
| o ooo . + |
| . + .o*...+ |
| . o o Xoo++ |
| ..++X&O |
+----[SHA256]-----+
```
#### Step 5: test the connection for no password challenge
Now when you reconnect to the camera you should find that after a short delay that you are logged in without being asked for your password.
If using windows then you will see /users/<yourusername> instead of the Linux /home/xxx format.
If you connect to the camera from multiple clients then configure the clients as above.
#### Step 4: get the public key on the camera
So we now have a private key and the associated public key on our host machine and the challenge is how to securely get this onto our target, in this case our camera, and added to the authorized_keys file in the target .ssd folder.
#### Trouble shooting
SSH access is very strict about ensuring that the keys in use are protected and therefore secure so if the permissions on the directories and files are not correct this can cause failures
Thankfully this has been thought of and there is a utility called ssh-copy-id which allows us to do that.
Enter the following:
```
ssh-copy-id -i /home/<yourusername>/.ssh/id_ed25519 root@<yourcameraip>
To check what is going on and find any issues then use the -v option in ssh to get a verbose output
```
You should get the following
```ssh-copy-id -i /home/<yourusername>/.ssh/id_ed25519 root@<yourcamipaddress>
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/<yourusername>/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@<yourcameraip>'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@<yourcamipaddress>'"
and check to make sure that only the key(s) you wanted were added.
```
Now test it is working by trying to access the camera. You should find it will successfully login without asking for a password.
```~$ ssh root@<yourcamipadddress>192.168.1.173
.d88888b. 8888888 8888888b. .d8888b.
d88P" "Y88b 888 888 Y88b d88P Y88b
888 888 888 888 888 888 888
888 888 88888b. .d88b. 88888b. 888 888 d88P 888
888 888 888 "88b d8P Y8b 888 "88b 888 8888888P" 888
888 888 888 888 88888888 888 888 888 888 888 888
Y88b. .d88P 888 d88P Y8b. 888 888 888 888 Y88b d88P
"Y88888P" 88888P" "Y8888 888 888 8888888 888 "Y8888P"
888
888
888 local+build, 2024-10-04
Please help the OpenIPC Project to cover the cost of development and
long-term maintenance of what we believe is going to become a stable,
flexible Open IP Network Camera Framework for users worldwide.
Your contributions could help us to advance the development and keep
you updated on improvements and new features more regularly.
Please visit https://openipc.org/sponsor/ to learn more. Thank you.
root@openipc-hi3516ev300:~#
````
Now if you enter ```cd .ssh``` and ```ls -la``` you will see similar to the following
```
drwxr-xr-x 1 root root 0 Oct 4 14:54 .
drwxr-xr-x 1 root root 0 Oct 4 12:28 ..
-rw------- 1 root root 101 Oct 4 14:54 authorized_keys
-rw------- 1 root root 83 Oct 4 12:29 dropbear_ed25519_host_key
```
#### Step 4: Troubleshooting
There are few reasons why if you have followed the above that this will not work however the main issue faced is if for some reason the permissions are not correct on the .ssh folder and the files within it.
Ensure the .ssh folder has 700 permissions and the authorized_keys file 600 or similar in Windows only your user and administrators have permission.
To get a clue how to resolve issues then when entering the ssh command add -vvv which gives verbose debug output and usually will highlight where things are failing.
#### Finally
Remember the private key in your local host machine should never be duplicated or moved Enjoy no more passwords to enter :-)