Interesting tip to improve SSH security

This time we will see a short and simple tip that will help us improve fullfilment of security requirements of our remote connections with SSH.


OpenSSH, which is the package provided by GNU / Linux systems to handle SSH connections, has a wide variety of options. Reading the book SSH The Secure Shell and the manual pages I found the -F option, which tells the SSH client to use a different configuration file than the one found by default in the / etc / ssh directory.

How do we use this option?

As follows:

ssh -F / path / to_your / configuration / file user @ ip / host

For example, if we have a custom configuration file named my_config on the Desktop, and we want to connect with the user Carlos to the computer with the IP 192.168.1.258, then we would use the command as follows:

ssh -F ~ / Desktop / my_config carlos@192.168.1.258

How does it help the security of the connection?

Remember that an attacker, being inside our system, will immediately try to obtain administrator privileges if he does not already have them, so it would be quite easy for him to execute ssh to connect to the rest of the machines on the network. To avoid this, we can configure the / etc / ssh / ssh_config file with incorrect values, and when we want to connect via SSH we will use the configuration file that we will have saved in a location that only we know (even on an external storage device), that is say, we would have security by darkness. In this way the attacker would be puzzled to find that he cannot connect using SSH and that he tries to make the connections according to what is specified in the default configuration file, so it will be somewhat difficult for him to realize what is happening, and we will complicate him a lot. the job.

This added to change the listening port of the SSH server, disable SSH1, specify which users can connect to the server, explicitly allow which IP or range of IPs can connect to the server and other tips that we can find in http://www.techtear.com/2007/04/08/trucos-y-consejos-para-asegurar-ssh-en-linux they will allow us to increase the security of our SSH connections.

Everything described above can be done in one line. For my taste it would be quite tedious to have to write a large line with multiple options every time we try to log in via SSH to a remote PC, for example the following would be a sample of what I am saying:

ssh -p 1056 -c blowfish -C -l carlos -q -i myself 192.168.1.258

-p Specifies the port to connect to on the remote host.
-c Specifies how the session is to be encrypted.
-C Indicates that the session should be compressed.
-l Indicates the user that will be logged in to the remote host.
-q Indicates that diagnostic messages are suppressed.
-i Indicates the file to be identified with (private key)

We must also remember that we could use the terminal history so that we do not have to type the entire command every time we need it, something that an attacker could also take advantage of, so I would not recommend it, at least when using SSH connections.

Although the security issue is not the only advantage of this option, I can think of others, such as having a configuration file for each server we want to connect to, so we will avoid writing the options every time we want to make a connection to a server SSH with a specific configuration.

Using the -F option can be very useful in case you have several servers with different configuration. Otherwise, all the settings will have to be remembered, which is practically impossible. The solution would be to have a configuration file perfectly prepared according to the requirements of each server, facilitating and ensuring access to those servers.

In this link http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config You can find out how to edit the SSH client configuration file.

Remember, this is just one more tip of the hundreds that we can find to ensure SSH, so if you want to have secure remote connections, you must combine among the possibilities that OpenSSH offers us.

That's all for now, I hope this information will be of some use to you and wait for another post about SSH security next week.

Note: if you want to read the book "SSH The Secure Shell" be sure to consult the manual pages of the version you have installed, as the book is quite behind in terms of the options supported by OpenSSH.
Thanks Izkalotl for the contribution!
Interested in make a contribution?

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   HacKan & CuBa co. said

    what? I think you refer to another post, because I do not understand what you mention. This post gives a small tip to apply when establishing the connection with a computer, it does not refer to changing any configuration of it, or to solve anything if someone manages to enter. The idea is to make communication between computers secure, bypassing the default parameters that may not offer the appropriate level of security.
    Port-knocking is interesting to restrict attacks (it does not prevent them completely, but it does its thing), although I find it a bit uncomfortable to use ... I don't have much experience with it.
    There are several programs that scan logs to block access by ip when incorrect logins are detected.
    The safest thing is to use passwordless login using key files.

    Regards!

  2.   HacKan & CuBa co. said

    what? I think you refer to another post, because I do not understand what you mention. This post gives a small tip to apply when establishing the connection with a computer, it does not refer to changing any configuration of it, or to solve anything if someone manages to enter. The idea is to make communication between computers secure, bypassing the default parameters that may not offer the appropriate level of security.
    Port-knocking is interesting to restrict attacks (it does not prevent them completely, but it does its thing), although I find it a bit uncomfortable to use ... I don't have much experience with it.
    There are several programs that scan logs to block access by ip when incorrect logins are detected.
    The safest thing is to use passwordless login using key files.

    Regards!

  3.   HacKan & CuBa co. said

    Also ssh will look for the default user configuration in ~ / .ssh / config
    Unless the daemon has been configured not to, but by default it does.
    It is important to take into account the algorithm used for hashes, with the -m option; I recommend hmac-sha2-512, hmac-sha2-256, hmac-ripemd160 for being the ones that offer the best security. Be careful, because by default it uses MD5 (or sha1 hopefully) !! are those things that are not understood….
    Anyway, a good idea would be to run it with:
    ssh -p PORT -c aes256-ctr -m hmac-sha2-512 -C IP
    with -c you specify the encryption algorithm used, where the ctr (counter mode) are the most recommended (aes256-ctr and aes196-ctr), and if not the cbc (cipher-block chaining): aes256-cbc, aes192- cbc, blowfish-cbc, cast128-cbc

    Regards!

  4.   HacKan & CuBa co. said

    Also ssh will look for the default user configuration in ~ / .ssh / config
    Unless the daemon has been configured not to, but by default it does.
    It is important to take into account the algorithm used for hashes, with the -m option; I recommend hmac-sha2-512, hmac-sha2-256, hmac-ripemd160 for being the ones that offer the best security. Be careful, because by default it uses MD5 (or sha1 hopefully) !! are those things that are not understood….
    Anyway, a good idea would be to run it with:
    ssh -p PORT -c aes256-ctr -m hmac-sha2-512 -C IP
    with -c you specify the encryption algorithm used, where the ctr (counter mode) are the most recommended (aes256-ctr and aes196-ctr), and if not the cbc (cipher-block chaining): aes256-cbc, aes192- cbc, blowfish-cbc, cast128-cbc

    Regards!

  5.   ivaan11 said

    what I wanted is that nobody could access my pc and control it remotely
    then I understand from your words that if I do not open the port there is no access at least in this way

    mercii for answering!

  6.   ivaan11 said

    Hello
    I have followed some of the tricks and I have a question! from among the options I have also changed
    The port for another different from the traditional one. If I don't open that port on the router, will it be impossible for them to connect to my PC? or will it be redirected to any other port?

    I don't need to make any remote connection so I wanted to know what would be more effective if opening the port or leaving it blocked.

    I wait for answers!

  7.   Serge Weizenegger said

    > The safest thing is to use passwordless login using key files.
    It is exactly what I was going to say ... that the only way to log in to different computers is with a key that is on a pendrive hanging from your neck 😉
    The attacker can waste his whole life trying to brute-force a password crack, and will never realize that he does not need a password but an XD file.

  8.   linux izkalotl said

    I am not an expert in Security and Networks but to violate your security system with passworless login it would be enough to simply make a script to copy your key stored on a pendrive at the moment you mount it, so in a matter of seconds you would have access with your own key to the server remote (and of course, without the need for a password), the problem with passwordless is that it makes you feel a false security, since as you can see with a few lines in a script it would be very easy to take control of your remote servers. Remember that an attacker will not waste time or resources trying to crack passwords if there is a shorter way to breach your security. I recommend that you use at least 20 of the options that SSH allows you to configure and add something like TCP Wrappers, a good Firewall and even then your server would not be 100% protected, the worst enemy in security matters is being trusted.

  9.   gorlok said

    It is interesting, although I am not sure of the real benefit, being that we are talking about just making things a little difficult when an attacker has already joined the team, and adding more complexity to the administrators.
    I find a honeypot technique more useful to alert (and take action?) About suspicious activity, or some kind of sandbox that restricts the attacker's actions.
    Or I would look for other types of techniques that prevent entry, such as port-knocking.
    Also, thank you for sharing it and opening the debate.