How to deploy Open-AKC(Authorized Key Chain)
Acting as a centralised trust management platform:
By allowing the “authorized_keys” mechanism on the hosts to be completely disabled, OpenAKC
permits SSH trust across an entire estate to be managed (with rich control and monitoring features)
centrally by “systems administration” or “information security” staff. This means that users, or
application developers etc. cannot add or remove trust relationships, effectively enforcing any
whitelist or approval process you might want to establish for the creation of trust relationships
within an estate.
A practical ‘Jump Host’:
Having worked in many Linux environments, the author of the software has seen a number of ‘jump
host’ solutions using dubious mechanisms such as “sudo” and others used to map users from AD or
LDAP directories to SSH trust relationships using shared private keys etc. and these solutions are
almost universally highly insecure.
OpenAKC implements a new approach and acts as an “drop in” upgrade for a legacy solution by simply migrating users to personal rather than sharedkeys with a “self service” key management mechanism. Requiring personal keys have pass phrases ensures increased security, and avoids ad-hoc automation from user accounts. The system provides rich control and monitoring features, while users can use familiar tools with little to no disruption to their workflow.
The problems everyone thinks about, but never finds a good solution.
The problem with joining every server to the domain:
◦ As soon as someone sudo’s to root. There is zero control on limiting what this root user can do. Which is a huge problem when getting compromised. Every key stroke is not logged and if you have multiple people sudo as root at the same time the logs can get blurry.
Well guess what….this is exactly what im talking about today. This architecture does take a few steps and time to understand its inner workings but security wise trumps anything out there currently being used by most folks.
This is a overview of a simplified architecture. This can be scaled out to new or legacy environment using many distros without interruption.
Combined jump host/security server architecture: This approach is generally used when it’s a small group managing things:
Benefits: The advantage here is your security server and your jumphost are on the same server. If you’re admin team is also managing the security then this approach is ideal because when diagnosing and editing role rules everything is in one place. Another key benefit… There are only couple client packages that are deployed on client machines upon deployment the client is already brought into the trust, so no additional work is required to bring it in.
Cons: If your jumphost goes down, so does your security server. Now this can be scaled out so there are two servers if one is unavailable it tries the second. But if you have one this could be a single point of failure. Keep in mind this is a VM and would takes seconds to bring back up, so durability is very good from a infrastructure stand point.
Or the alternative:
A Segregated jumphost/security server architecture: This approach is generally used when you have large groups and large infrastructure managing things.
Benefits: Now the advantage here is if you have a multiple groups and need to tighten the security. You can have a your security server and your jump hosts segregated. These two machines are the only two machines that talk you AD. You have roles setup on the security server. If your user is listed in the role on the security server and your apart the AD group that is allowed to login via ssh.
The security server will allow you to login as root via registered ssh keys. You can also strip away “roots” abilities, and every keystroke is logged per user on the security server. A key benefit here is that because the client machines are not joined to the domain. A hacker would never be able to determine information that leads to the heart of your network such as AD, the groups setup, and any of its users. The other benefit is the jump hosts are easily deployed as needed and ready to go if needed. Since the security stuff is not local, the jump host is also secured.
Cons: If your security servers are not functioning and you have disabled user/pass. You will be locked out unless you single user. However this is easily fixed by setting up a strong root/pass that can bypass all security and only give this to one person, such as your manager or someone in secureops. Which would be only used ever used in an extreme dire situation. I have yet to see this ever required once this is implemented correctly.
Special Features:
How to deploy Segregated jumphost/security server architecture:
Okay so the first thing we want to do is setup our security server host to Active Directory. The reason for this is we want to be able to setup centralised user management coupled with using authorised keys to jump to client machines.
Centos 7
Note: make sure you disable firewalld and selinux on your machine. Just a extra layer that not needed and only serves to tie your own hands behind your own back.
Install the following packages will be be using sssd/kerebros
[root@securityack1 ~]# realm discover AD.NICKTAILOR.COM
ad.nicktailor.com
type: kerberos
realm-name: AD.NICKTAILOR.COM
domain-name: ad.nicktailor.com
configured: kerberos–member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U
login-policy: allow-realm-logins
it will ask you for the AD admin password, enter it and it should go to the next prompt. This step will create the all the necessary files /etc/sssd/sssd.conf /etc/krb5.conf /etc/smb.conf file you need.
yum install openakc-server
Example:
[nicktailor@security1 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nicktailor/.ssh/id_rsa):
/home/tailorn/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nictailor/.ssh/id_rsa.
Your public key has been saved in /home/nicktailor/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:udhNKEp0txzfup7IxhUwNA+VSviWP1mu/aKPA5vZb3w tailorn@jumphost1.nicktailor.com
The key’s randomart image is:
+—[RSA 2048]—-+
| o+… |
| . ++. |
| . .oo=. |
| . . o=*… |
| . ..S.o=. |
| . . +.+=.. |
| . ..oBo= |
| .*.++= E |
| .o.**o+. |
+—-[SHA256]—–+
[nicktailor@jumphost1 ~]$ openakc register
OpenAKC Copyright (C) 2019-2020 A. James Lewis. Version is 1.0.0~alpha18-1.el7.
This program comes with ABSOLUTELY NO WARRANTY; see “license” option.
This is free software, and you are welcome to redistribute it
under certain conditions; See LICENSE file for further details.
Passphrase is requested to ensure you own this key.
Enter passphrase:
Escalating to perform API call
Connected to OpenAKC server. Sending key registration request
OK: Request processed
Here you will create a role block that will allow said user to jump to any client so long as your key is registered the openakc security server.
RULE=2020/01/13 19:17,2030/01/13 20:17,user,nicktailor
DAY=any
TIM=any
SHELL=/bin/bash
CMD=any
SCP=s,^/,/data/,g
CAP=cap_linux_immutable
REC=yes
FROM=any
RULE=2020/01/13 19:17,2030/01/13 20:17,group,linuxusers
DAY=any
TIM=any
SHELL=/bin/bash
CMD=any
SCP=s,^/,/data/,g
CAP=cap_linux_immutable
REC=yes
FROM=any
Note: The CAP section allows you to disable root abilities there is a long list of things. This particular one. Disables root from being able to edit any file with an immutable flag. So all your root users can not change these types of file eve as root.
You starting to see why this is how you do shit? Think for yourselves not because someone else said that best practice. Jeez…
Note: this is just a development setup I am doing for you. It can be scaled with two security servers using gluster of nfs to share the files system. This server will be what all the clients check with before allowing anyone to enter. They will need to first exist in AD and then their root key will need to be registered here, and then they will need to be allowed in the appropriate role and sssd and ssh groups before they can get in. This also eliminate the need to join any clients to the domain and protects against any hacker from being able to query the domain controller for user groups and if users exist. The would of also needed to get on to the jump host, have your key and also know your root passphrase. Unlikely going to happen
Okay now were going to setup the jumphost jump1.nickatilor.com
Note: You can have as many jumphosts as you like. This should be the only entry point to your servers. The jump host also talks to the security server. So even if you tried to go directly the server. You couldn’t since its only allowed from here. This is how you set shit up so you don’t end up like solarwinds and so many other idiots who follow rules old and out of date rule blindly.
Note: You also add this server to the domain. So please follow the joining of the domain setups from above and then carry on from here.
APIS=”nickack1.nicktailor.com“
PORT=”889″
ssh-copy-id –i ~/.ssh/id_rsa.pub root@192.168.1.200
[nicktailor@jumphost1 keys]$ openakc ping
OpenAKC Copyright (C) 2019-2020 A. James Lewis. Version is 1.0.0~alpha18-1.el7.
This program comes with ABSOLUTELY NO WARRANTY; see “license” option.
This is free software, and you are welcome to redistribute it
under certain conditions; See LICENSE file for further details.
Connected to OpenAKC server. Sending Test Run Ping Message
Test Run Response – OK: Pong! – from server – securityakc1.nicktailor.com
If you see that above that is a good sign
Now were going to add a client machine so you jump to it. This is the easiest part. So say you have a bunch of legacy systems and you want to centralise login without joining to the domain, you want everyone who using root to be tracked by logging every keystroke and logging what incident they logged in for to use root.
curl https://netlore.github.io/OpenAKC/repos/openakc-el7.repo | sudo tee
/etc/yum.repos.d/openakc.repo
vi /etc/openakc/openakc.conf
APIS=”192.168.1.200“
ENABLED=”yes”
PORT=”889″
CACHETIME=”60″
DEBUG=”no”
PERMITROOT=”yes”
AUDIT=”yes”
QUIZ=”no”
HIDE=”restrict”
FAKESUDO=”yes”
Note: Quiz if you set it to yes. When you log into root it will ask for a service now ticket number and description which will get logged on the security server.
That’s it!….
Now if you go back the jump host and try to log in
[@jumphost1 ~]$ ssh root@192.168.1.38
Enter passphrase for key ‘/home/nicktailor/.ssh/id_rsa‘:
OpenAKC (v1.0.0~alpha18-1.el7) – Interactive Session Initialized
[root@nickclient1 ~]#
This is session is now being logged and and you can not see if the user belongs to the domain
[root@nickclient1 ~]# id nickatilor
id: nicktailor: no such user
This is how you setup security like pro. Hope you enjoyed this.
Hope you enjoyed this.
Special thank you the author of the project “James Lewis” I enjoyed learning this and am a big fan of the innovation behind the open-akc project.
How to add new users:
That’s it your done. Now the new user is able to login into the estate via ssh from the jump host.