Automate SSH Key Rotation on Ubuntu with Ansible

Overview

Changing your SSH keys is as important as changing your underpants daily, running this script on a frequent basis will ensure access to the servers are changed on a regular basis. Use Ansible to do ssh key rotation in your sleep!

Test Bed

  • Ansible control server running Ubuntu 18.04 LTS
  • Test server running Ubuntu 18.04 LTS

Requirements

  1. Ansible control server
  2. SSH keys established between Ansible control server and destination server(s)
  3. A folder called “pubkeys” where the script is running from

Break Down

  1. Creates a new directory on the remote server to generate the new keys on
  2. Generates the new key pair in the newly formed folder
  3. Copies the new public key to the local machine running the ansible script under /pubkeys/ and names it “id_rsa.%hostname%.pub
  4. Removes existing private key
  5. Removes existing public key
  6. Moves new private key to the users .ssh folder
  7. Moves new public key to the users .ssh folder
  8. Changes new private key to read only
  9. Invalidates existing keys and applies the public key copied to the local host to the server
  10. Copies the new private key local host and changes the file to “id_rsa.%hostname%
  11. Removes “newsshkey” folder on remote host as a clean up

ssh_key_rotation.yml

Note: You will need to change/remove the “- hosts:” entry

Key Management

To fully automate this I have mounted a cifs share and created a symbolic link on the Ansible server from the ~/.ssh folder to the cifs share. All my other clients are set up the same way so when you update the key it copies the key to a central repository which all other clients are symbolically linked to.

Conclusion

This can be greatly be improved on but is a good starting point in the rotation of your ssh keys. I’m happy to hear suggestions on how this could be improved.

Ansible – mySQL root password change on Ubuntu

 

This Ansible script will fully rotate your MySQL root account passwords (or change any MySQL account passwords if you change the script) and implement my.cf so you don’t have to keep putting the password in. This took me a while to figure out, there are 

Test Bed

  1. Ansible control server running Ubuntu 18.04
  2. Ubuntu 18.04 Bionic test server running mySQL 5.7.25

Requirements

  1. Ansible control server
  2. SSH keys established between Ansible control server and destination server

Overview

  1. Install mySQL package with required dependancies
  2. Stop mySQL service
  3. Set mySQL environment variables
  4. Start mySQL
  5. Change mySQL root password to a mySQL native password (native is very important!)
  6. Copy .my.cnf from local source to ~
  7. mySQL flush privileges
  8. Stop mySQL service
  9. Unset mySQL environment variables
  10. Start mySQL

sql.yml

etc/mysql/.my.cf

global-vars/config.yml

Execution

Other Considerations

You will need to remove lines 7 to 19 if you are not installing MySQL for the first time.

If any applications are using the account you are rotating, the application will auth fail (I would hope your not using root for app authentication) – if you use this against any other username this will need to be considered.

Conclusion

The gotcha for a lot of people (from what I’ve read on blogs/github) is that when the mysql root password changes you also need to change it from “auth_socket” to “mysql_native_password”. 

 

Regenerating SID’s using Powershell

I’ve devised a handy way of regenerating SID’s on Microsoft operating systems using a third party tool and a little PowerShell magic.

The Breakdown

The first part of the script sets variables that can be called upon to randomise the SID number.

The next part sets the source location to download newsid.exe and defines a destination location.

The “set-itemproperty” adds a key into the registry to trick Newsid to think it has already accepted the EULA.

The “start-bitstransfer” initiates the download of newsid.

The real magic is in the last part – newsid is executed with “/a” to run with no prompts and “/n” to not reboot after.

execution”. The “S-1-5-21-“ is the first part of any SID then it calls the three random numbers generated from $random%.

The Script

Considerations

Having this script on a gold imaged server set to auto run on login (with a restart afterwards) would be the best implementation of this. You wouldn’t need to use the source and destination either and just point to a local copy of newsid.exe. I did however write this with a remote copy of newsid.exe in mind.

You will need to change the source and destination to suit your needs.

This is written for Microsoft PowerShell Version 5+.

You could drop the “/n” in the newsid.exe switch so it does reboot on completion.

The “S-1-5-21-” at the beginning of the SID is always going to be the same.

Conclusion

With the ever increasing demand for automating the deployment of servers, this is as important as ever if you start interconnecting the automated servers.

Atlassian Backup to AWS S3

If you have a self hosted Atlassian suite (Bitbucket, Confluence or Jira) you might want to consider creating a backup of the data to an external repository such as AWS S3 in-case your server fails.

Overview

This script creates a tar of all your Atlassian data and uploads it to AWS s3 using the aws cli package. 

Requirements

  1. 1 x AWS S3 bucket
  2. AWS programmatic account that has writeable access to the AWS S3 bucket
  3. AWS CLI installed on the Linux server and configured with a AWS programmatic account

Script

Considerations

You will need to change lines 3 and 4 to match your requirements.

By default data is located in the “/var/atlassian/appliction-data” however you will need to change this location if it isn’t.

It creates the following folder structure in the S3 bucket: /year/month/day/host

Add this to a cron for automated results.

Conclusion

By setting up this script to run in a cron you will have the data in at least two places and depending on your cron schedule a lot of points to restore from.

Nagios XI – Adding Microsoft Server Services via API

When automating server provisioning you might be considering implementing Nagios for monitoring servers and services as part of the build process. Apart from the help section of Nagios console giving some hints on how to interact with the API, there isn’t much else to go on so I’m sharing my learnings on how to do this.

I’m not going to go through the whole implementation of automating Nagios into server builds but more specifically connecting to the API.

The Nagios reference is http://host.example.com/nagiosxi/help/ and then click on “Config Reference”

The first step is to add the host – now this is in the Nagios help section so hopefully, this is nothing new

You will need to change the FQDN, API Key, Hostname and address to your requirements to make this work for you.

Scroll to the right of the code to see it all.

One thing to note is every setting is separated by a “&” and variables specified by the check start with “!”. This is the key to understanding how this works.

Add Processor

Add Disk

Add Memory

Add Uptime

Make sure you change the FQDN, API Key, Hostname and password variables for this to work.

I found the configuration wizard very helpful, what I did was add the service I wanted to check, see what the “check command” was and the variables set and then crafted my own curl command to add to Nagios.