Resetting SSH Configuration

Linux Security
1

New Member Here!

Thanks for the Awesome Videos, Channel & Community! :grinning: :wave:

I have watched the videos on SSH config and troubleshooting…

Just One Question (Brief Background Explanation):

I am considering “re-doing” my SSH setup between 2 of my physical machines (I am “root”). I understand about deleting the SSH keys and “known_hosts” on the “Client”-side, and the “Authorized_Keys” file on the “Host”-side (machine I am logging into).

Here’s my Question:

Should I also delete the “host keys” on the “Client”-side, which are stored in “/etc/ssh/” ? For example:

ssh_host_ecdsa_key.pub  ssh_host_ed25519_key.pub  ssh_host_rsa_key.pub ssh_host_ecdsa_key  ssh_host_ed25519_key  ssh_host_rsa_key

I basically want to start completely over, this time using the more secure/informative id_ed25519 type.

For “cleanliness” and “readability”, is it a good idea to also delete the host keys in /etc/ssh ? (on Client side-- see files listed above in “code” section).

Would greatly appreciate advice on this matter!
:+1:

2

My knowledge on ssh is a little lacking, but as a understand it, the host keys are used to “fingerprint” the device you are connecting to. These are the keys used to build the known hosts file on the client side. If you delete these you are effectively changing the identity of the ssh daemon. It shouldn’t affect you if your ssh connections are starting fresh. But it would cause a warning for anyone re-establishing an ssh connection. That’s how I understand it.

3

@hulxmash :grinning:
Thanks for the reply!
Since I am planning on starting-over with new SSH keys, I’m not too concerned about messing things up as they are. Anyway…
Sounds like what you’re saying is that it would be OK to delete the host keys on the client-side if I’m starting over.
Do I understand you correctly?

4

What I am saying, is that there is no real reason to delete these files.

First of all they should not be on the client-side at all. They are generated initially by the ssh server daemon. Unless the host is receiving ssh connections there should not be any host keys in /etc/ssh.

I’m not sure how you can recover them if you delete them either. They are used to secure the ssh connection to the server, and by deleting them you would need to find a way to regenerate them. The keys would be different, but would not really affect how your ssh connections work. They would not be any more secure. The only thing that it would affect is, if there is a current client that has the keys in the know hosts file, then that host would show a warning that the keys have changed.

If you have wiped out the known hosts file on the device you are making the ssh connection from then it’s not going to change anything for you.

5

@hulxmash :slight_smile: thanx!

You mentioned:

First of all they should not be on the client-side at all. They are generated initially by the ssh server daemon. Unless the host is receiving ssh connections there should not be any host keys in /etc/ssh.

I don’t understand why it’s a problem that the host keys are on the client side (residing in Client’s /etc/ssh/ directory). The host keys on the Client (machine I am connecting from) seem to be the private and public keys for the Host (machine I am connecting to). See my original post for file list. Oh, and as of now, the Host (Server) IS currently receiving connections from the Client.

I haven’t deleted anything yet, and I still have Client and Server (Host) connected; that is, my Client is still able to connect to the Server (Host), since I haven’t changed anything yet.

I was considering re-doing the whole set-up, and thought that I should just delete everything, including the “host keys” that reside on the Client side. From my original post:

Given what you have written, I think I will err on the side of caution and leave them alone.

Perhaps when “starting over” and deleting the keys from Client’s ~/.ssh directory (or the directory itself), as well as the “authorized_keys” file on the server side, and then regenerate new keys, hopefully, all will be well.

I appreciate your feedback, as I learn to take baby-steps in this new endeavor!
:hugs:

6

Unless you’ve copied your host keys from the server to the client, then these keys are not from the server. The ssh server daemon would never send out both the public and private key pairs. The private keys must necessarily be kept private, to keep the connection secure.

It’s not a problem that the host keys are on the client side. As long as you want to be able to ssh into your client, as well. In your client /etc/ssh/ directory, I’m willing to bet you’ll also find a sshd_config file. That means that you have installed the ssh daemon on the client side. In that case, if the daemon is enabled (and it is by default on ubuntu), your client is listening for an incoming ssh connection. That’s why the host keys would have been generated.

If you delete those host key files, it will stop your ssh daemon from starting and receiving a connection. I would remove (or purge) the openssh-server package if you don’t want to receive ssh connections on your client computer. Then you can safely remove the host keys without any issues.

If you want to be able to ssh into your client system too, then I would look at your sshd_config file and make sure it’s configured the way you want. This file is what you’ll want to change on your server too, if you want to limit the kind of authentication (like ed25519).

I would recommend setting up a couple of virtual machines for testing out your ssh settings. Snapshots are great for this type of thing. You can have a working setup, take a snapshot, reconfigure, and possibly break your system and restore. It’s a great way to learn without any stress.

I apologize for my incomplete and hopefully not too incoherent responses. I have been responding on very little sleep (shift work) and I have really dropped the ball on this one.

7

@hulxmash :smile:
Thanks So Much!
It’s starting to make more sense to me. As you say:

In your client /etc/ssh/ directory, I’m willing to bet you’ll also find a sshd_config file. That means that you have installed the ssh daemon on the client side. In that case, if the daemon is enabled (and it is by default on ubuntu), your client is listening for an incoming ssh connection. That’s why the host keys would have been generated.

Yes, on the client-side I do have an “sshd_config” file.
My installation comes with the ssh daemon enabled (running MX-Linux, Debian Based).

I probably do NOT want to receive SSH connections on the Client side, as this is my main computer that I want to use to log into a variety of other computers.

However, there may come a day when I’m “Out in the Wild”, and will want to “Phone Home” to this main computer.

Thank you for clarifying:

then I would look at your sshd_config file and make sure it’s configured the way you want. This file is what you’ll want to change on your server too, if you want to limit the kind of authentication (like ed25519)

That makes a lot of sense!

And, I really love your recommendation:

Thankfully, I am pretty-well set-up with backups, including snapshots…which have saved me more than once!

I hadn’t considered virtual machines, which I had played with about a year ago…but I think that is an excellent idea, and I’ll start delving into that again.

You have been clear and coherent, and extremely helpful. I really appreciate all of your responses!!!

:partying_face: :clap: :fireworks: