SRX

After upgrading our SRX300 from 15.1X49-D100 to 17.3R1 yesterday everything continued to work just fine, except that we now get an "access denied" error when trying to login via ssh.

 

The OS upgrade was done via SSH from the uploaded local OS image file. Config validation was successful, no errors whatsoever. After rebooting the box came up fine with the new OS version. We were able to use the previous root password to login to Jweb.

 

During troubleshooting we generated another user with super-user privileges, and this user can login via ssh an jweb. Changing the root password was possible, but even with the new root password only jweb login is possible. system.log  error is: '<fw-name> sshd 14613 - - error: PAM: authentication error for root from >ip>'

 

The 17.3R1 Readme does not mention any changed behaviour for ssh root access. Is this a bug?

We need to explicitly configure below command to allow root login through ssh in 17.3.
set system services ssh root-login allow

Hello ,

 

This is an expected behaviour , we need to add the following command on 17.3R1

 

set system services ssh root-login allow

Hello,

Please see https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/root-login-edit-system.html

Default

root-login deny-password is the default for most systems.

Supported Platforms

• EX4600
• M Series
• MX Series
• OCX1100
• PTX Series
• QFX Series
• QFabric System
• SRX Series

This was introduced in JUNOS 16.1 & 12.3R13 via confidential PR 1143440.

HTH

Thx

Alex

 

 

Just wanted to add the note that it is widely considered best practice on unix systems to disable direct ssh login by root and elevate privledges when needed on the cli.

 

You can find many discussions on this recommendtion to understand the pros and cons via google. I'm sure the change in default behaviour is to follow this recommendation and you should enable this only after reviewing and understanding the issues making a conscious choice in the matter and not just because we have always done so.

I agree that this change in default behaviour makes sense. However, if a remote upgrade via root ssh would result in a complete lockout, it would have been great if this important change of behaviour were to be found somewhere in the accompanying release docs or the upgrade instructions.

 

Anyway, thanks a lot for this very fast and helpful response!

it would have been great if this important change of behaviour were to be found
somewhere in the accompanying release docs or the upgrade instructions.

totally agree with this.  Since it was listed in the documentation listed above, I assumed the change in behavior was also called out in the release notes.  But when I pull them up you are correct.  No listing of this in the appropriate section.  I'll post a note for the documenation team to review this.

 

https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.1/topic-105576.html

Hello,

 

In response to this issue, iX posted updates to the following Release Notes:

• Release Notes: Junos OS Release 16.1R4 (PDF)
• Release Notes: Junos OS Release 16.1R5 (HTML and PDF)
• Release Notes: Junos OS Release 17.3R1 (HTML and PDF)

The next release of the User Access and Authentication Feature Guide (17.4) will include the change as well.

 

Regards,

Linda

Building new stacks, new to Juniper... So I just upgraded from oob to 15 then to 17, lost access via ssh but can get in under http. How is that more secure? Now I have to transmit my password in clear text to clear this up... 

Yes, they probably should also prevent root access via the Jweb interface too.

 

The basic idea here on a nix server is that on first login you create a super user account for administrative access.

Then disable root ssh login.

Always then ssh is via the admin accounts and use sudo for those functions that require root.

 

This is a major change in default behavior to push teams towards this best practice.  But it certainly could be better called out during the first install process and upgrade process.  Warnings when the non-root accounts do not exist would be a good idea.