Sunday, 16 July 2023

Linux User SSH Access Control

Technology growth is rapid, implementing solutions without proper restriction would cause data leak, cyberattacks. First line of defence for any solution would be its users. Granting granular privilege and role based access is one of the critical task that should be implemented.

SSH is Secure SHELL protocol works on port 22. In Linux, Users over remote connect to administer and manage daily activities on the server. There are multiple security ways of handling user access. In this blog I will be writing how we will restrict SSH access to server. 

Create a Group in Linux that will contain all the users who will be provided SSH access to the server. 

#groupadd ssh-users

You can also specify a group id for this group and maintain it across your environment to manage it with config automation tools like ansible and others in a large scale in future. 

#groupadd -g 3000 ssh-users

Create user and add to the ssh-users group 

# useradd -c "SSH Allowed user" -m -d /home/karthick -s /bin/bash -aG ssh-users karthick 

where, 

-c is comment for a administrator to identify what user or a brief about the user. 

-d is mention home directory of the user 

-s is login shell that the user will be using. 

-a is to append user to the mentioned group

-G is to add user to the secondary groups mentioned.

SSH Restriction

Edit the sshd_config file under /etc/ssh/sshd and add the following line in the end.

AllowGroups ssh-users

Restart the sshd service. 

#systemctl restart sshd

Now, ssh will be restricted to all users, except for those who are added in this ssh-users group.

Ansible Automation

I have written a sample ansible play to automate these tasks in my git - SSH-Restriction



Best Practices: 

Never allow any Privileged/Admin accounts Remote SSH Access.

Always provide SSH access to normal user and then allow sudo escalation or su to privileged user with password. 

References:

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html

OS: 

RHEL, SUSE Linux, Centos

Saturday, 1 July 2023

Azure Fence agent in Azure China for Pacemaker cluster


Microsoft has provided extensive documents for Pacemaker cluster on azure. They are efficient and easy to follow. 

On Azure china, so many things are different in terms of infrastructure connectivity. we see a lot of restrictions and security added. So in this blog I will be writing a small topic which is not covered in the global azure document. This topic would be in specific to government/China azure instances. 

For a Pacemaker cluster to operate in expected manner, we would need the STONITH device as you all know. On Azure there is fencing agent(fence_azure_arm)  to provide this feature. 

Fencing agent is created with python and it is granted with azure service principle rights or MSI(Managed system identity) roles to perform fence operation.  

Ideally this agent would communicate with the Azure AD and get authenticated to perform the stop/start/restart operation for a VM. All of this communication for global azure happens through the management.azure.com, however in china this api is different, and the fence agent script will need to be configured to inform which cloud api it needs to communicate explicitly. 

While configuring fence agent as cluster resource you will need to add additional option called cloud with value as china. This will ensure fence agent is communicating to the correct api and bring up the fence agent online.

The following is the Eg: to create fencing device for a pacemaker cluster in SUSE Linux

# replace the bold strings with your subscription ID and resource group of the VM

sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm params msi=true subscriptionId="subscription ID" resourceGroup="resource group"  cloud=china pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_delay_max=15 op monitor interval=3600 timeout=120

References -


Hope this topic is useful for you !!
- JK