lock account but still need access via ssh

[terrytapp]

Team:

Is there a way to lock an account on HP-UX, but still allow access via ssh using public keys? On Solaris I can set an account up that has no password (an "NP" in the encrypted password field in /etc/shadow) which
means a user can't directly login via telnet, but can still login using ssh and public keys. It seems that if I lock accounts on HP-UX (trusted) and normal, then I'm unable to log in via ssh. is there a way? Please help?

Thanks

Terry

[skt_skt]

In HP_UX u cant.

I am a little confised about the statement "On Solaris I can set an account up that has no password which
means a user can't directly login via telnet, but can still login using ssh and public keys"

Setting no password is not same as account is locked. So i dont think you are comapring apple to apple.

[blah2blah]

you usually determine what methods are going to be allowed to be used to login, then enable those that are allowed and disable those that are not allowed to be used.

In your case, you don't want to allow telnet logins. So, you would disable the telnet daemon, telnetd. You would have to do this for other methods you don't want to allow, such as ftp and the "r" commands.

you want to have access using ssh. So, install the secure shell software. sshd can be configured as to which methods of authentication that can be used. You would configure sshd to disallow password authentication and to allow public keys.

you should check as to what you mean by "locking" the account. when an account is locked on a unix system you cant login weather your using ssh with public keys or telnet with a password. And that is the way it is on solaris, hp-ux, aix or linux.

[Ollie Rowland]

Hi,

As far as I know, locking the account will prevent access via SSH too on any platform.

But if you set a password and expire it, then TELNET access will not be possible (unless the user knows the old password of course), but SSH using keys will continue to work fine.

[Ollie Rowland]

Hi,

Addendum:

In fact, if you just have a valid password for an account but don't let the user know what the password is then you get the same scenario.

If you don't set a valid password then the SSH will fail.

[Sandeep_Chaudhary]

same thing not true with hp-ux

[Ollie Rowland]

Which bit isn't true? Could you please explain constructively rather than simply dismiss other postings?

[Sandeep_Chaudhary]

If u lock account and then try ssh

here i enter "NP" in /etc/shadow
sandchau:NP:14133::::::

after thois if i try ssh it is OK.

then i tried to lock account

suxde033 # passwd -l sandchau
root as root@suxde033 [/root]
suxde033 #

cat /etc/shadow|grep sandchau
sandchau:*:14133::::::


sandchau@suxde900 /home/sandchau > ssh suxde033
Connection closed by 10.55.243.35

[Yavor Balabanov_1]

Don't try to do it like on Solaris.
On hpux you have the /var/adm/inetd.sec file which can restrict the telnet/ftp users by IP.
This doesn't affect sshd as it runs as daemon and not by inetd.conf.
Usually lately the telnet/ftp are completely disabled in /etc/inetd.conf.
After having the telnet disabled, you can play with the ssh configuration - on hpux it's in /opt/ssh.

[Deepak Kr]

Terry,

As already said it is not true in case of HP-UX. Not worked on solaris much but if this is the case it is a security concern.

Once user is blocked intensionally then there should not be another mean to open backgate to him..

[Doug O'Leary]

Hey;

I have to disagree with all previous posters. You *can* do this exactly as you can on solaris. Doing this is a good security practice for accounts that you don't want to have directly accessible but still want/need to be accessible. The other advantage to this is cron still works. If you lock an account via the passwd command, the cron jobs for that account are disabled. Using the NP option, cron still works.

The trick is the same in HPUX as it is in solaris. You replace the encrypted password in the /etc/shadow or appropriate /tcb/files file with NP. Since NP is an invalid encrypted password, people will not be able to use password authentication to access the account *but* ssh/public key authentication still works as does sudo.

You can provide sudo access to the account set up this way so that users have to log in as themselves, then sudo to the user. The approriate sudoers entries would look similar to:

User_Alias ORA = ${user1}, ${user2}
Cmnd_Alias ORASU = /bin/su - oracle, /usr/bin/su - oracel
ORA ALL=(ALL) ORASU

I'm honestly a little surprised at the previous posts. This is a fairly standard security practice for disallowing direct password access to application admin accounts - usually for all the same reasons you don't want to have direct password access to root.

Doug O'Leary