Trusted mode and only ssh certificates

[JohnFjeldberg]

Hi everyone,

I'm trying to set up a particular application user account to only accept connection using ssh keys, but not password, similar to " "PermitRootLogin without-password", but for normal users. System is trusted, and when I try #passwd -l <account> the key stops working as well... I'm thinking of replacing the hash in the tcb file with some garbish, but I was hoping to get around it in a better way.

System is:

HP-UX 11.23 IA

OpenSSH_5.3p1+sftpfilecontrol-v1.3-hpn13v5, OpenSSL 0.9.8l 5 Nov 2009
HP-UX Secure Shell-A.05.30.008, HP-UX Secure Shell version

Thansk&Regards,

JF

[Turgay Cavdar · Accepted solution]

Please set the foloowing in sshd_config file and restart sshd.

PubkeyAuthAllowUsers  user_x
PasswordAuthDenyUsers user_x
ChallRespAuthDenyUsers  [pam] user_x

[Arunabha Banerjee]

You need to generate public key. For an example if you are trying to login from serverA to serverB then you need to generate a public key in serverA and export thaa key into serverB authorized_keys file.

Steps:

1. Login to serverA using particular application user id

2. Generate public key ($ ssh-kegen -t rsa  OR  $ ssh-keygen -t dsa)

3. ssh-copy-id -i ~/.ssh/id_rsa.pub user@serverB OR ssh-copy-id -i ~/.ssh/id_dsa.pub user@serverB

OR

scp ~/.ssh/id_rsa.pub user@serverB:/home/user/.ssh/authorized_keys

Please take a backup of existing authorized_keys file backup in serverB before proceeding

4. Check with some simple command like $ ssh serverB hostname (it will not ask for password)

[JohnFjeldberg]

Thanks Turgay, that's exactly what I needed. Strangely they have forgotten to mention this in the man pages, but at least it is in their "HP-UX Secure Shell Getting Started Guide" . Your response is much appreciated.

BTW, might be worth mentioning that you have to tweak "UsePAM or ChallengeResponseAuthentication" to get the desired behaviour.

[Doug O'Leary]

Hey;

If you're interested in *completely* removing password authentication from a user, you can update the encrypted hash with NP (no password) or some other ascii less than 13 characters and also is not LK.

The rason that ssh stopped working after the "passwd -l command" is that ssh honors locked accounts.  If the account is locked, you can't get into it via ssh either.  Another side affect of locking an account is the user's cron will stop working as well.

NP works because there is no password that will get hashed through the crypt function to NP.  This removes any possibility of password based authentication while still allowing access via ssh/pka and keeping the cron jobs running.  

One added benefit is you don't have to keep editing the sshd_config file for users coming in or leaving, if that's an issue.    

The sshd approach listed above will require public key authentiaciton; however, users will still be able to telnet, ftp, or rlogin assuming those protocols are still enabled.  

Last point: if you do go the NP encrypted passwd hash route, make sure you remove any entries associated with password aging.

Hope that helps.

Doug O'Leary

[JohnFjeldberg]

Hi Doug,

that would be a more ideal method, however, I can't find a "supported" methode to do this when you have a trusted system. I guess you could:

1) Hacb the tcb files for the useracounts directly and change the hash

2) Use /usr/sam/lbin/usermod.sam -p "NP" user

But I still can't find any doco that NP is a support/proper way of doing it, do you know about a manpage/doco that verifies this around trusted systems?

Thansk&Regards,

[Doug O'Leary]

Hey;

Sorry for the delay in answering.  I was expecgint my rss reader to let me know when there were new responses.

There is no documentation for this action - it relies on logic and an understanding of the system operation.

First, if you lock an account it will either put 'LK' or a '*' in the encrypted password field.  The reason this works is that an encrypted password hash is 13 characters long - always.  Regardless of how many or how few characters you type as a password, the encrypted hash will be 13 characters long.

Both LK and * have a special meaning to the account management process - they mean the account is administratively locked.  If an account is locked, it won't allow you to log in (obviously) but will also prevent the account's cron jobs from running.

So, the next thing is to come up with an 'encrypted password' that won't resolve to anything and doesn't mean anything to the account management process: hence 'NP'.  That prevents any password based authentication, but enables shh/pka access and keeps the cron jobs running.

Personally, I just update the encyrpted hash with a perl oneliner.  We're using the shadow passwd file so it's a bit easier, but it'd still be pretty easy for tcb:

awk -F: '$3 > 100 {print $1}' /etc/passwd | while read user

do

    c=$(echo ${user} | cut -c 1)

   p=/tcb/files/auth/$[c}/${user}

   [[ ! -f ${p} ]] && echo "${user} missing tcb file ${p} || \

      perl -i -ple 's/.../.../g' ${p}

done

you'll have to work out the search/replace on your own as it's been *years* since I've seen a tcb file... Been working with a bunch of previous solaris admin managers who insisted that we use the shadow passwd patch even before it was very useful..

HTH;

Doug O'Leary

[JohnFjeldberg]

Thanks Doug, your reply is much appreciated!