Labels

Android (1) Apache (1) bash (2) boost (2) C (36) C++ (4) cheatsheet (2) CLion (6) css (3) Debian (33) DL (17) Docker (3) Dreamweaver (2) Eclipse (3) fail2ban (5) git (6) GitHub (5) Hacking (4) html (8) http (1) iOS (1) iPad (1) IRC (1) Java (33) javascript (3) Linux (181) Mac (21) Machine Learning (1) mySQL (52) Netbeans (6) Networking (1) Nexus (1) OpenVMS (6) Oracle (3) Pandas (3) php (17) Postgresql (8) Python (9) raid (1) RedHat (15) Samba (2) Slackware (52) SQL (14) ssh (1) svn (1) tar (1) ThinkPad (1) Virtualbox (4) Visual Basic (2) Visual Studio (1) Windows (5) wire (1)

Monday, 12 February 2024

SSH HostkeyAlgorithms and private keys

A note for .ssh/config and .ssh/authorized_keys

The file should contain

HostkeyAlgorithms =+ssh-dss,ssh-rsa

Note the =+

I had received the following error earlier;

Unable to negotiate with xx.xx.xx.xx port 22: no matching host key type found. Their offer: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

and couldn't for the life of me understand why. Eventually tracing down the config file from above was missing the =+ and I'm assuming this meant is was only allowing ssh-dss,ssh-rsa and causing the error above.

Private Keys

In other news, if we wish to login to a box using a private key, we would normally do something like:

ssh -i path_to_key user@ip_address

We can also create a .ssh/config (600) file or amend it to include the details so that we can login with something like:

ssh host

As an example, we would add the below:

Host oracle
    HostName 192.168.254.121
    User opc
    IdentityFile ~/.ssh/oracle.key

where oracle would be the host name and the private key would be in .ssh/oracle.key

We can then do ssh oracle


Summary                           

1) On the server - ssh-keygen -t ed25519 -f ./name_of_key -C "SolarOS"

this will create two files, name_of_key and name_of_key.pub

2) On the server - Copy the file into authorized_keys;

cat name_of_key.pub >> .ssh/authorized_keys (ensure permissions of authorised_keys is 700)

3a) On the server - Copy name_of_key (private key) to clients and place in  ~/.ssh/ 

scp name_of_key user@192.168.192.6:/home/user/.ssh/

OR

On the Client:

3b) On the client -  Copy name_of_key (private key) from the server and place in  ~/.ssh/

scp user@192.168.192.198:/home/user/.ssh/name_of_key /home/user/.ssh/


[Public Key]  -  Remote Machine (server) ~/.ssh/authorized_keys

[Private Key] -  Local Machine (client)  ~/.ssh/ 


On the client, the private key needs to be included when connecting, for example:

ssh -i ~/.ssh/the_private_key.key user@192.168.192.6

which can also be included in a config file, see above.




The below can read back a bit confusing but it is generally meant to explain that the key pair can be used in two different ways, with the client creating the key pair and placing the client's public key on the server, it its authorized_keys.
Or with the server creating the key pair and the private key being placed in ~/.ssh/  on the client machine.
The latter requires linking to the file when logging in, the former doesn't.


To login using a private key

1) Generate a public key on the client machine, for example;

ssh-keygen -t ed25519 -C "SolarOS"

This will create id_ed25519 and id_ed25519.pub (where the *.pub is the public key).

Note: we can use the -f flag to provide the name for the key pair, for example;

ssh-keygen -t ed25519 -f ./solar_os_deploy_key -C "SolarOS"

2) Copy the public key to the server, for example;

scp ed25519.pub a_user@192.168.254.198:/home/a_user/

3) copy the file into .ssh/authorized_keys, for example;

cat ed25519.pub >> .ssh/authorized_keys (make sure the permissions of authorised_keys is 700)

4) Remove the ed25519.pub key form the server.

Then to log in from the client, simply do ssh host@server


The above can also be done on the server (my preferred method);

Step 1 creating the private and public key pair. 

Step 2 would then mean copying the private key and not the public key to the client, with the client saving it in .ssh/

Step 3 would be done on the server, with its own public key.

Step 4 is the same, removing the public key from the server.

We would then login from the client with ssh i .ssh/name_of_private key user@host


The .ssh/authorized_keys contains the public keys and .ssh/ contains private keys which you reference with ssh -I



No comments:

Post a Comment

Note: only a member of this blog may post a comment.