The other day, I tried to ssh into a client and to my surprise, I couldn’t. Now if you are the guy in charge of managing macs and you can’t get into a mac that you clearly should be able to, you start asking yourself some questions.
Sometimes it’s the user, sometimes it’s the system and sometimes, it’s all the above playing tricks at your expense.( In this particular case, it turned out to be the user doing something that caused it.)
Long story short I used my magic hand and brought the mac back into the fold… There will be no black sheep running around.
From that escapade, I decided to write something that could allow me to easily identify those black sheep, whether it was intentional or not (One way or another I would eventually find out what is what.)
As always I like to keep my script in pairs (One to find and the other to rectify).
I know there are other scenarios I haven’t accounted for but this works for me (One scene I want to look into is ssh connection failing when the firewall is enabled and set to block connections).
The first piece is the attribute ssh_status, which for my current needs, checks for two things:
– That ssh is enabled (just because it is doesn’t mean you can connect)
– That the sshd_config file exists
(Again, I know there are other variation of blocking ssh but for now this solves my issue, I plan on building on top).
When ssh is turned off
The connection is refused on port 22
When /etc/sshd_config is removed like this
As such, the script checks if ssh is turned on and if the sshd_config file exists; and if both are True, it sets the attribute result to Enabled and if not, Disabled.
Pretty straight forward…..
Given that this is coming from an attribute, I suggest you let your inventory update for a day or so before enabling the policy.(Why fix what’s not broken?)
Now that we have our smart group, let’s load the ssh_enabler script into Casper Scripts.
(I am skipping that part because it’s self explanatory.)
Let’s create our Policy according to the following rules:
Scope: Computers with SSH Disabled (Our Smart group)
Trigger: Network State change and Recurring Check-ins
Make available Offline is optional but as the name says, it will run even if the client can’t reach the JSS.
I am also adding an inventory update config so that I have an accurate report every time the policy runs.
Voila… We now have an ongoing policy that will reset ssh on any clients that dares to fall into it’s scope.
While this setup will not address everyone’s needs, I am hoping some will find it useful.
There are many scenarios that can be added here; some of which I will explore such as ssh status in relation to the built-in firewall settings been enabled; or ensuring the needed user is allowed to ssh but for now this works.
The scripts are available on my github.