Hidden SSH account

[#1]

Can anyone refresh my memory and remind me the command to create the hidden SSH account in the OS image?

Thanks,

Danny Lee
Tech Support Specialist
650-350-4547
dlee at nuevaschool.org

[tlarkin]

sudo /usr/sbin/jamf createAccount -username cadmin -realname "Casper
Administrator" -password p at 55w0rd –home /var/cadmin –shell “/bin/bash”
-hiddenUser -admin

change it around to your liking

[tlarkin]

Or

Better yet also add the ssh account into your configuration from Casper Admin as well.

[ernstcs]

As always on a managed machine you can see the jamf binary commands and there options by going into terminal on a managed machine and typing:

/usr/sbin jamf help

Or just

Jamf help

Tom, I just want to make sure I'm understanding the comment below. Are you talking about the option for "Ensure that Computers Imaged with this Configuration are managed". If that's configured it will create the hidden account? Or what are you referring to. I wasn't under the impression it did that, actually created the account, unless that was something new in 6.0. That option merely stored that account information in the JSS for that machine so it knew how to connect with the remote tools.

I know that if a machine has existing autorun data, imaging using prestaging, or when you are using Casper Imaging to image the computer you can enter that information into the Accounts tab. However, I don't think those options hide the account like the -hiddenUser switch does using the binary.

I've always kept a current copy of the binary around on a network share to run that command, but if there was an easier way that'd be cool...sort of.

Thanks,

Craig E

[ernstcs]

Yup, that was: /usr/sbin/jamf help

Slash stopped working, I'm sure of it! ;)

[tlarkin]

According to my Casper bible it says this:

"If you would like computers that are imaged with this configuration to be managed by Casper and the JSS, enter the enter the user name and password that allows access to this configuration via SSH in the fields labeled SSH username and SSH password"

Wudi from JAMF totally went over that too at the CCA training, and I am not quite sure if it actually creates the account or not. I mean all you need is SSH to run, right? The account doesn't necessarily need a home directory since all the JAMF logs are piped out into like /var/jamf/jamf.log anyway right?

Because your frame work is going to force SSH on, and recon will add the account, but when it adds the account I don't ever see an account show up in the finder, I do see it though if I do a dscl . list /Users

I don't think I quite answered that question right either.

[ernstcs]

Someone else actually reads the manual?! =)

I'm pretty sure by setting the account information in the configuration it won't add the account, but if JAMF wants to confirm that and prove me wrong so I can save a step in my base image process that would be cool. Correct you can have the framework make sure that Remote Access is enabled, it just turns on the service, but then your remote tools use that SSH account information stored in the JSS for that computer and is typically the account you specified in your imaging configuration. Typically this account is built into your base OS image, but perhaps this concept has changed since the days of yore. Now this I could very well be wrong on, and again if JAMF wants to clarify, cool. I'd rather know what's right than not. I don't think Recon adds an account to your OS, all Recon really needs for an account is a user in the JSS to allow it to submit data when it runs. The manual (page 367 in the current 6 version) is somewhat vague to me about this setting in the management framework. What confuses me is that it says you need to select an account for machines not added to the JSS. Then what is it using to run Recon and submit data to the JSS if I don't have a specified account and it's a machine in the JSS? Is this what you see for a user with your dscl command, some secret account it adds? I just see the account I created with the binary in my base, but I do have an account specified in the framework as well and may not add an account if that's set? That setting has probably been used way before I took over here... Yup, everything should log to jamf.log.

I probably haven't answered it right either. I just want to make sure we're telling people the right things. My official CCA training may be out of date being version 4.x.

Craig E

[#8]

This looks similar to what I have used to set up the hidden account, but Casper has been unable to use this account to manage our machines. I end up using an admin account that is not hidden to manage the machine and that seems to work. I think SSH is enabled for the hidden account but I am not totally sure. It just seems kinda pointless for the hidden account if it doesn't work.

[John_Wetter]

That's why when in doubt, I just use a quickadd package. Have an auto-login user on your JSS that just takes Recon, and hand out the QuickAdd package. Have it set to create the hidden user and recon and manage using that hidden user.

If you run recon on a machine in the JSS, the user/pswd field should auto-populate if it is a managed computer. Recon does not add an account, hence why I just use a quickadd package.

I think it's quite important to have Casper manage the computers with a hidden user. This way, if someone changes the visible admin username, you can still manage the computer. This also becomes handy if your admin password gets compromised as the netadmin user is still there to manage and change the password for your visible admin account.

-John

*
Now this I could very well be wrong on, and again if JAMF wants to clarify, cool. I’d rather know what’s right than not. I don’t think Recon adds an account to your OS, all Recon really needs for an account is a user in the JSS to allow it to submit data when it runs. The manual (page 367 in the current 6 version) is somewhat vague to me about this setting in the management framework. What confuses me is that it says you need to select an account for machines not added to the JSS. Then what is it using to run Recon and submit data to the JSS if I don’t have a specified account and it’s a machine in the JSS? Is this what you see for a user with your dscl command, some secret account it adds? I just see the account I created with the binary in my base, but I do have an account specified in the framework as well and may not add an account if that’s set? That setting has probably been used way before I took over here...

* Yup, everything should log to jamf.log.

I probably haven’t answered it right either. I just want to make sure we’re telling people the right things. My official CCA training may be out of date being version 4.x.

Craig E

[#10]

Something wrong here, then. We add a hidden admin account to all our On 27 Aug 2008, at 04:15, Danny Lee wrote:
managed machines (with a QuickAdd package generally) and it's essential to the way things work, particularly because amost all end users here are admins so can and will meddle. I agree with John Wetter about the importance of using a hidden account. In fact I'd go further and say that it's *essential* that the management account is hidden. If it's visible then people mess with it. There are a couple of checks you can do if this account isn't working for you:

First, try logging in as the hidden user ('netadmin', 'cadmin', or whatever else you call it) on the client machine just to check it works locally. I do this in Terminal with 'su netadmin' but you can also do it from the login window, of course. If that works and your JSS still can't connect to the machine then maybe the hidden user password is garbled in the JSS. Pull up the machine in the JSS inventory, click on 'Edit', and in the 'Computer Info' tab retype the password in the 'Management Password' fields. I mention this even though it seems obvious because we've had occasional problems in the past with this field getting corrupted when using a QuickAdd package.

If you can login as your 'netadmin' user locally, and you're sure the credentials are correct in the JSS, then everything should work, assuming that Remote Login is enabled on the client machines, of course. Those are really the only criteria you need to satisfy.

Another big advantage of the hidden admin account is that you can use the kickstart command to enable ARD for that user and set all the necessary access privileges without this being visible to the end user in System Preferences. We always do this with the user's permission (extolling the virtues of remote access with ARD) so it's not a big secret, but it's critical that they can't see and tamper with the settings. They soon forget about it!

The specific command we use is: "sudo /System/Library/CoreServices/ RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate - configure -access -on -users netadmin -privs -all -restart -agent" but see <http://support.apple.com/kb/HT2370> for more info.

HTH, and apologies if all this is stating the obvious.

James

~~~~~~~~~
James Partridge
Systems Development & Support (Apple)
NSMS
Oxford University Computing Service
13 Banbury Road
Oxford OX2 6NN

Tel.: (01865) 273207
iChat: james.partridge at mac.com

[ernstcs]

I think that either method is fine as long as there is one account for management that is hidden. I think that's a best practice thing.

Use the QuickAdd stuff from recon if you like to create the account or the command line. I'd take things one step further using command line for security and add another switch:

jamf createAccount -username <username> -realname <realname> -password <password> -home /var/<username> -admin -hiddenUser -secureSSH

My notes about this:

shell is optional unless you really plan to logon locally with that account on the box and have a preference be careful with hiddenUser as I've missed the capital U in there at times * and secureSSH just sets the box so only that account can access the system via SSH, a little more security, but unless you know these accounts then others who don't but have admin on the box from other accounts like AD groups etc. will not be able to SSH in through terminal if they needed to for some reason. For us this hasn't been a problem thus far. They can still get at the machine in other ways given the right access in the JSS using the othe remote tools.

That's all I got on this one.

Craig E

[tlarkin]

Personally, I create two hidden local admin accounts on every machine
for this exact reason. 1 is solely for casper stuff, and I don't give
that password out at all. There is never a need to log into that
account to do anything. The other one is a local hidden admin account
for administration, troubleshooting, and maintenance of the computer. I
hide them from the finder and put their home directory in /private/var.

I sort of found a bug with Casper 6.0 already. It seems that when you
try to update the Casper SSH account password on version 6, but your
clients haven't updated their command line application yet, it doesn't
change it right. Of course, someone in my department gave that password
out to someone who didn't know what it was for, and I was forced to do a
massive password change. So, I no longer give out the ssh account
password, and all the casper servers have passwords that only me and one
other person I work with know, both of us are CCA so I figured that
would be best practice. So, I just made my update JAMF binary policy
more aggressive as well as my update inventory. I also added the jamf
command to change a password to that account since the built in feature
seems to bug out a bit when working with a 5.13 client. Since the 5.13
was in my image and deployed to 6,000 Macbooks you can't really
instantly update the command line app for casper.

You could create post script actions for when you add quickadd.pkg that
create accounts using the jamf binary, it is very easy and straight
forward. I have a script that uses the JAMF binary that creates an
account, runs recon, and sets master passwords for root, firmware and
whatever else I need done. If you use the JAMF commands it makes your
script less code and a lot easier to follow since they simplify it, and
I prefer to keep things simple.