Guides and How-To’s

Basic Security for the Operations Impaired: Stop Sharing Credentials

Really, don’t do it

Today we’re going to go over credential sharing, the importance of avoiding it, and some possible methods for making sure it doesn’t happen.

Computer Security is a balancing act between ease of use, available time (I.E Money), and the desire to make sure script kiddies don’t run off with all your valuable business data.

I decided to write this article after seeing many of my clients sharing SSH Keys and otherwise ignoring basic security principles.

I’ll be paying particular attention to SSH keys and API Keys in my example as these are resources that are commonly shared between technical personnel. Some understanding of these subjects are required but I will attempt to offer simple explanations for someone unfamiliar with the subject.

Who is this for?

  • You’re a person who often finds themselves sharing secrets (API Keys, SSH Keys, username/passwords, etc) with other members of your team
  • You’re a (likely exasperated) operations team member trying to explain the importance of not sharing credentials with non-operations team members.
  • You’re a small business owner (Likely without a CTO) trying to understand the implications credential sharing may have on your business.

What is Credential Sharing?

Credential sharing is a concept that is easy to understand.

It’s the exchange of privileged credentials (sometimes called secrets) such as API Keys, SSH Keys, and Usernames/Passwords between a privileged user (Someone who has access to a resource) and an unprivileged user (Someone who doesn’t have access to a resource).


John is the only developer on a project at Acme LLC. Acme LLC has a single system user for server management that is accessed by John using his SSH Private Key.

For the layperson: An SSH Key consists of two components. A public key, which is like a lock and a private key, which is the key that goes to that lock. Any resource you place the public key on can be accessed by it’s associated private key. It is always OK to share the public key, you should virtually never share the private key.

After some time, Acme LLC decides it wants to add another developer to the team, Jimmy.

When Jimmy is added to the team John provides Jimmy with his SSH Private Key instead of generating a new SSH Key.

There are now two people accessing the same user account with the same private key.

So what’s the big deal?

It’s a problem for a few reasons:

  • With a single user being utilized to access the system, it’s difficult to determine who actually performed what action (For example, if Jimmy or John carries out a malicious action on the system).
    • Let’s assume John and Jimmy would never do anything malicious (They’re good guys). If the SSH Key is compromised (By one of those darn script kiddies), you can’t tell if it was Jimmy or John who was compromised because you’re only using a single account and a single key.
      • The person compromised might have a rootkit or similar on one of their machines that has the SSH key, in which case changing the keys would be useless without solving the underlying problem.
  • Due to some organizational changes, Jimmy has to be let go from the team. At this point, anywhere these credentials were used has to be rotated. A new key must be generated and added to all the system and then distributed to everyone who needs access.
    • If you have a team of more than 2 people, this problem will become even more pronounced. You would be looking at interrupting the work of what are likely some of the most expensive personnel in your organization while you add and distribute the keys.
  • If you’re sharing credentials in this manner, it’s also likely you will forget to rotate the keys. At this point Jimmy has a key that could still be used to access these systems past the period of his employment. Even if Jimmy isn’t malicious, you now have another vector for the key to be compromised.

In short, sharing credentials of any type in this manner is not only a major security concern, it can also waste the time of some of the most expensive members in your organization.

How can I prevent this?

As with many security issues, the answer can partially be solved by technology but the other (often more difficult part) must be solved culturally (By those difficult to manage people).


You want people in your organization to understand the dangers and you want them to know that the operations team is there to help. Inversely, you want an operations team that views themselves as an enabler of the business.

Nobody wants to communicate with this guy after all

  • Go over basic security with organizational members to stress the importance of not sharing credentials (As well as the importance of security throughout your organization).
    • Be sure to explain the potential damage credential sharing can cause the business.
  • Provide avenues for people to communicate with your operations team (Preferably via a set process) to request access to systems.
  • Ensure your operations team is receptive to the requirements of the rest of your organizations.
    • If someone is authorized (At an organizational level) to access a resource, providing the credentials should be as quick and painless as possible (While still maintaining reasonable security)


Let’s continue with our SSH key example from earlier. We want to increase security while keeping the amount of friction to a minimum.

  • Stop using a single account to access your servers. Each user should utilize their own system account.
    • Each user should also utilize an SSH key that they generate themselves. This key should preferably be passworded as well.
  • Create an easy to utilize system for the creation of users and adding of public keys to servers.
    • Directory Servers and Identity Management Systems can provide for great granularity but can be rather complex to manage and operate. This include things like OpenLDAP, 389 server, and FreeIPA.
    • A simple option for AWS is a solution from Widdix that utilizes IAM Code Commit public keys. You can find that here. For organizations with simple requirements (And who use AWS) this can be a great fit and is absolutely better than simply sharing keys. The solution is easy to utilize and implement.
    • Alternatively, one can manage user accounts and keys using a config management system like Ansible.

Similar rules apply for other resources like API Credentials. You should have credentials for your dev, staging, and production instances and if anyone needs access to the same resources, they should also have their own keys generated.


Sharing isn’t always caring, particularly when it comes to privileged credentials.

After reading this I hope you understand the security/monetary implications of credential sharing and are equipped with some basic guidance on how to accomplish it.

If you’re looking for an experienced Automation Engineer/Linux Sys Admin to help whip your infrastructure into shape, I hope you won’t hesitate to schedule a short meeting to talk about how I can help (You can easily schedule at the bottom of this post).

Want to understand how I can help? Take a look at my article here.

Till next time.


How To Create A URL Branded Calendly Link: A Step by Step Guide


So you’ve setup a fancy new Calendly to help ease scheduling for you and your clients. All your clients have to do is visit and they can quickly schedule a meeting with you. How neat!

That’s all well and good but what if you want to keep customers within your website (or at least your domain)?

Below I show you a quick and easy way to setup a branded Calendly URL like you can see at

Most of you are likely using cPanel based hosts so setting this up is a complete cinch, just follow the steps below.


  1. Create a subdomain
    1. Open your cPanel dashboard. This is normally at yourdomain.tld/cpanel.
    2. In the search box type “Subdomain” and select the Subdomains option.
    3. Under the subdomain box type the name you’d like your clients to type in. For example “schedule” (without quotes of course).
    4. Under “domain” select the domain you’d like to do this to. In my case this would be “”
    5. Point to the “Document Root” of your new subdomain.
      1. If the domain is your default cpanel name, you can put something like “public_html/schedule”.
      2. If the domain is an addon domain (Like mine was) it will be something closer to “public_html/”
  2. Create an index.html file with the correct contents
    1. On your computer open a text editor (On Windows, this would be “Notepad”).
    2. Inside the file, paste the following contents while replacing the bolded section.
      <!-- Calendly inline widget begin -->
      <div class="calendly-inline-widget" data-url="" style="min-width:320px;height:580px;"></div>
      <script type="text/javascript" src=""></script>
      <!-- Calendly inline widget end -->
    3.  Now go to the file menu and select “save as”. Where it says “Save as Type” select “All files”. Set the file name as “index.html”. Under “Encoding”, select “UTF-8”. Click save.
  3. Upload the index.html file created in the last step to the “Document Root” you specified in Step 1.
    1. We’ll use Filezilla, a free cross platformFTP/SFTP program. You can download Filezilla here.
    2. Install Filezilla.
    3. Open Filezilla.
    4. NOTE: Many hosts have SFTP (Secure FTP) disabled by default. Contact your web hosting support if you have issues with the following section. 
    5. Under host put “” or just “”.
    6. The username and password are the ones you use to login to cPanel.
    7. IMPORTANT: Under “Port” be sure to specify “22” or the SSH port for your host, otherwise standard FTP will be used. This is a security risk.
    8. Click connect.
    9. Use the panel at the bottom left to locate the “index.html” file you saved in Step 2.
    10. On the panel at the bottom right locate the “Document root” folder specified in step 1.
    11. Drag the “index.html” panel from the left panel to the Document root folder in the right panel.
    12. Allow the upload to finish and you’re done!
  4. Visit “schedule.yourdomain.tld” and you should see your Calendly page displayed!


I hope this guide helps you get a branded URL setup for your freelancing business. As mentioned in the guide above, be sure to contact your web host if you’re having issues connecting via SFTP.

If you have any questions, don’t hesitate to ask in the comments.