Enhancing SSH Access Security on Juniper SRX Routers

     In this article I will tell you how to configure truly secure SSH access to Juniper SRX series devices, i.e. make hacking our router a do-it-yourself batch a priori. I will describe two things:

• How to make SSH login possible only by ssh key.
• How to limit the list of IP addresses that can use ssh-access to Juniper.

     At one time, I honestly killed the whole day to finish off how to implement such simple things in Junipers. I hope my article helps you save time.

     Let's implement the first paragraph. And immediately a couple of spoons of tar for seed:

• On Junipers, DO NOT change the SSH port! We will connect our whole life to the 22nd! Okay. This is another reason to do key entry. I hope in future firmware somehow fix it ...
• This procedure does not affect access to the web interface. This is on the one hand bad, because anyone who breaks the password for the web face can change the config as he wants, but on the other hand it’s good, because makes us think, and who can even go to our web face and can he do it? You can restrict access to the web interface both by the interface and by ip. But more on that later.

     So let's get started. First you need to generate a pair of SSH keys. The PuTTygen utility from the standard set of PuTTy utilities is perfect for this . We launch it and see this window:



     Select SSH2-RSA, the key length is 1024 bits (Junipers do not support above). Click "Generate", move the mouse while the generation is in progress. When finished, be sure to enter the password twice firmly in the appropriate fields and click the "Private Key" button to save the private key. I think it’s not necessary to remind you that the private key is called a private key, that it should be stored in a very safe place? For example, I do not store it in open form, but use the KeePass2 utility . Well, this is already more convenient for someone!
     It is also advisable not to lose this key, because Further, we will configure Juniper so that without him he simply won’t let him go to the console. You will have to go into the web-face and delete the part of the config that is responsible for this setting. Well, or carry out a dreary procedure for resetting the root password to the device.
     Then, copy the contents of the "Public key ..." window into a notebook. We will need to fix something before inserting the public key into the Juniper config. First, delete the phrase “rsa-key- ...” from the end, then bring the key to the form:

«The ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBfkD3juKaLXqNKJfhUMIwt4Ro / aF38WDi7XlALiSYDYY8GZuhcAMJHL0FKJRTI07Qcr
Kfev4nFm2HbeSFkaI96l4TSKlqS90goemrbTkNTes / 2F9VBzRjogYcEfr57bgUQ DVmnSMWiLeWwFwT79pctJR1dJZbSuQf2jgmrqPpTfJ235u + + 8 + xoyIOzg3JFlCwTNIYSvGX8sdnJaJkt0IOWf V4O2KPmIbrjHaWg9MZQcu2pdDfLBFaLgkgh9wPlToKtaCk0577DN6OImhOpL + + KJrGQSXfc68Zw0hhakBojfotyFklGO390KxO
wVecS35kMuHjSRmhaGqf03yG1sQWt = root @ Juniper»

     Attention! It is important not to make a mistake here, otherwise Juniper will not accept the key! The key must always be enclosed in quotation marks. At the end there should be a “=” sign, followed by a space, and then root @ your_Juniper_name. That is exactly the same as the command line prompt of your device! The Juniper name, I recall, is set by the team set system host-namein configuration mode. If you later change this name, you will have to correct the key itself.
     Now that the private key is password-protected and stored in a safe place, and the public one is ready to be inserted into the config, the PuTTygen utility can be closed and entered into the console. We write:

root@juniper# set system root-authentication ssh-rsa открытый_ключ (вставляем копи-пастом)

     If everything was done correctly, then Juniper will write our key in his config.
     Now we make an entrance only on a key:

root@juniper# set system services ssh root-login deny-password

     Well, of course:

root@juniper# commit check
root@juniper# commit

     Now, in order to log in via SSH, we first need to specify our private key file in Putti in the “Connection - SSH - Authentication” section. Upon entering, we will see something like this:



     Here we enter the password that was set when generating the private key. After that, we are generously allowed! It is interesting that if someone now tries to enter without a key, then Juniper will all the same obediently ask him for a login password, but authentication will fail every time.

     Now let's talk about how to restrict SSH login at the network access level. There are two complementary methods for this. First: the directive host-inbound-trafficin the section edit security zones. Example:

root @ juniper # show security zones security-zone untrust
    screen untrust-screen;
    interfaces {
        fe-0/0 / 0.0 {
            host-inbound-traffic {
                system-services {
                    ping
                    ssh;
                }
            }
        }

     This directive governs the protocols for which the Juniper will be available for this zone / interface . For example, ssh, ping, https, https, dhcp, tftp, etc. If we specify host-inbound-traffic system-servicesthe ssh protocol in the section , then Juniper will listen to ssh-requests on this zone / interface.
     Good. But if we have ssh open on the interface for LAN, then all users of the LAN can potentially access Juniper via ssh. This in most cases is not buzzing, so you need to use firewall filters to give access only to certain IPs.
     Suppose we need to allow access only for ip 192.168.10.10, and disable all others. We write such a construction:

root@juniper# edit firewall filter deny-ssh

     (entered filter editing mode)

root@juniper# set term 1 from source-address 0/0

     (indicate coincidence with any source address ...)

root@juniper# set term 1 from source-address 192.168.10.10 except

     (... except what we need)

root@juniper# set term 1 from destination-port ssh
root@juniper# set term 1 then log discard

     (we deny access via ssh. Discard - means silently kill the packet. You can write reject - also a ban, but with icmp port unreachable sending. Log - means logging unsuccessful attempts to hit ssh. In principle, you can not write).

root@juniper# set term 2 then accept

     (do not forget to allow everything else, otherwise it will be very bad for both us and the router) We apply

     this filter to the loopback interface of the router (because it leads to the routing-engine, i.e. to the kernel of the system where the sshd daemon lives) .

root@juniper# set interfaces lo0 unit 0 family inet filter input deny-ssh

     The above method is quite tough and requires careful application , because adjusts ssh access to Juniper from ANY INTERFACE. If we do not need such a serious level of security, then the same filter can be similarly applied to the LAN interface. Only in this case, you need to take into account that the LAN interface is transit by definition, and therefore you need to add destination-addressJuniper himself to the filter rules , otherwise the ssh protocol on the given network will not work magically in general. There is destination-addressno need to specify a loopback interface , as It is not transitory.
     It’s clear that it’s not necessary, for example, to write insource-addressall zeros. You can specify any specific subnets and even interfaces. In other words, you can configure access very flexibly.

     By the way, we can restrict access to the Juniper web interface by a similar procedure!

     That's all! In this simple way, we have significantly increased the security of our ssh sessions!