Then Permitting Access Through a Palo Alto PA-220 Next-Generation Firewall to Destination Server
By Charles Buege, Fuel User Group Member | Friday, October 5, 2018
Being able to securely connect with an SSH connection is one item that IT professionals need to do all the time, and knowing that the pathway to your system is as secure as possible is of vital importance. In this article, I will review the following items:
- Setting up a second instance of SSH on a non-standard port number
- Configuring SSH to require a certificate for authentication instead of a username and password
- Configuring your Palo Alto PA-220 next-generation firewall (PA-220) to allow the connection through that port
With this demo, I will be working with CentOS 7.
When working with ssh, the first thing you need to make sure of is that ssh is installed. I know this sounds silly, but when I first started playing around with Linux, I found that different distributions would and would not have ssh installed by default. I now check to make sure that a particular distribution installs ssh as a default. If you don’t know or aren’t sure, here’s the command to install it:
yum install openssh-server -y
Once you see that ssh is installed, you should also make sure that ssh is set to automatically start.
Using the above image as an example, on the line starting with ‘Loaded:’ line, look for the word ‘enabled.’
Once we have confirmed that SSH is installed and running on this system, we now want to setup SSH on another port. For this example, I will be choosing the port number of 43210.
When I change my system over from port 22 to a different port number, I don’t like to change the existing port 22 unless I have to for security or compliance reasons. This way if you have a problem, you can console into the system and start up port 22 to grant yourself access.
Here are the steps I follow to set up a new set of files, keeping the default sshd files intact. I will share the steps section-by-section to explain what is happening each time.
cp /etc/ssh/sshd_config /etc/ssh/sshd_config_43210
sed -i "s~^#Port 22~Port 43210~g" /etc/ssh/sshd_config_43210
sed -i "s~^#PubkeyAuthentication yes~PubkeyAuthentication yes~g" /etc/ssh/sshd_config_43210
sed -i "s~^#PasswordAuthentication yes~PasswordAuthentication no~g" /etc/ssh/sshd_config_43210
sed -i "s~^PasswordAuthentication yes~# PasswordAuthentication yes~g" /etc/ssh/sshd_config_43210
sed -i "s~^#PidFile /var/run/sshd.pid~PidFile /var/run/sshd_43210.pid~g" /etc/ssh/sshd_config_43210
echo "" >> /etc/ssh/sshd_config_43210
echo "# This is the group of users that has permission to access this port via certificate authentication" >> /etc/ssh/sshd_config_43210
echo "AllowGroups ssh-remote-users" >> /etc/ssh/sshd_config_43210
Make a copy of the sshd_config and name it with the port number that is going to be used as part of the file name to make it self-documenting – sshd_config_43210 in this example. In this file, the following items are changed:
- Port Number is enabled and changed from 22 to 43210
- Public key authentication is turned on
- Password authentication is turned off
- There are two places in the default version of this file where PasswordAuthentication is listed by default, hence why it is listed twice.
- A dedicated pid file for the process is also specified with the port number appended to the file name – ssh_43210.pid.
- After the blank line is appended to the file, there is a group added ‘ssh-remote-users’ which limits which users can access this server via this port.
firewall-cmd --permanent --zone=public --add-port=43210/tcp
The group ‘ssh-remote-users’ is created for controlling access to the server via this port.
Firewalld is updated for the specified zone and is opened for this port. If you are using a different zone, change this accordingly.
cp /etc/sysconfig/sshd /etc/sysconfig/sshd_43210
Another file is created from the system default: /etc/sysconfig/sshd_43210
- This file is created but not modified, as there is no current need, so that in the event that changes are made to the default sshd file, this sshd configuration isn’t affected.
cp /usr/lib/systemd/system/sshd.service /usr/lib/systemd/system/sshd_43210.service
sed -i "s~^Description=OpenSSH server daemon~Description=OpenSSH server daemon - Port 43210~g" /usr/lib/systemd/system/sshd_43210.service
sed -i "s~^After=network.target sshd-keygen.service~After=network.target sshd.service~g" /usr/lib/systemd/system/sshd_43210.service
sed -i "/Wants=sshd-keygen.service/d" /usr/lib/systemd/system/sshd_43210.service
sed -i 's~ExecStart=/usr/sbin/sshd -D $OPTIONS~ExecStart=/usr/sbin/sshd -Df /etc/ssh/sshd_config_'43210' $OPTIONS~g' /usr/lib/systemd/system/sshd_43210.service
The service file, sshd_43210.service, is now created.
- The ‘Description’ is being changed.
- The ‘After-‘ line is being changed to specify that this service should start after the normal sshd.service has started.
- Important note: If after you have this port 43210 setup and you plan to disable port 22, be sure to disable this ‘After’ setting requiring sshd.service to start first. If you don’t, then you won’t be able to get this port started until port 22 has been started.
- The ‘Wants’ line removes the requirement that sshd-keygen.service be available to be run.
- Since this comes in automatically with sshd.service, if you are disabling port 22 as mentioned in the important note above, then you will want to keep the ‘Wants’ line in the service file.
- The ExecStart line is modified to include the reference to the sshd_config_43210 file created previously. If this is not specified, then sshd will try to use ‘sshd_config’ by default and if other changes are made to that file, you will have problems later.
systemctl enable sshd_43210.service
systemctl start sshd_43210.service
After the systemctl daemon-reload command occurs, the service sshd_43210 is both enabled and started.
usermod -a -G wheel remote_user
echo remote_user:DLKjRE&$hwdhK@3djwis24 | /usr/sbin/chpasswd
usermod -a -G ssh-remote-users remote_user
chown remote_user.remote_user .ssh
chmod 700 .ssh
chown remote_user.remote_user *
chmod 600 *
At this point, the user ‘remote_user’ (or whatever you desire) is created and granted access to both the ‘wheel’ group and the ‘ssh-remote-users’ group with their password being specified.
- Usage of the ‘wheel’ group is presuming that the user who will be remotely accessing this port will need to be doing root-level/sudo commands. If this is not the case for you, be sure to update the group membership, rights, etc. accordingly for your needs.
For the ‘remote_user’ user, the .ssh. directory in their home directory and two commonly used .ssh files are created: known_hosts and authorized_keys. The rights are set on the files and directory so they are secure as possible.
At this point, you want to take and upload your previously created PUBLIC ssh key onto the server and put it into the file /home/remote_user/.ssh/authorized_keys.
Security Note: I know that certificates seem like a more secure way to control your connections (and they do to a point). However, it is strongly recommended that when you create your private and public keys that you specify a passphrase. Without this passphrase, someone could acquire your certificate and use it to connect to the secure server – or servers if you use this pair of files in multiple places – and you may never know it.
The server is now ready for you to allow the external connectivity through the PA-220 to the server.
Configuring the PA-220 for the external connectivity is a straightforward process depending on your needs. In my case, I will redirect port 43210 from my PA-220’s external IP address to a host that is internal to my network via port and NAT redirection.
First, I defined the following NAT policy:
After the NAT policy was created, I created the following Security Policy:
Once your public key is in the authorized_keys file, you can connect to this newly setup server via this port using a command structure like the following:
ssh –i [NameOfPrivateKey] –p [PortNumber] [RemoteUserID]@[IPAddressOfHost]
ssh –i from_server_to_demo –p 43210 email@example.com
After entering your passphrase, you will now be connected to the server.
After you’re confident that your secondary port is good to go, you can then stop the sshd service running on port 22.
That’s it. You’re all set.
Have thoughts or questions? We want to hear from you. Start a discussion in the Fuel Virtual Water Cooler.
More to Explore
Check out these Fuel blog posts for further reading: