Usually when su rejects an attempt to switch user it responds with "Sorry" but with a certain username on some unix servers the response is "Killed". I'm guessing the su accepted the username/password but refused to spawn child shell with the specified username. What's causing this and what has to be done to remediate it so the process is not killed?
What's going wrong of course depends a lot on what it's trying to do. Can the user login -- is it just su that breaks it?
I'm logged into the host using my personal credentials they su to a production username.
Here is the entire exchange:
~ $ su - produser
Enter your LAN Password:
<username produser entered>
Killed
~ $
If in another host under my personal credentials ssh into the other host is basically the same.
Here is the exchange
$ ssh produser@host
Enter your LAN Password:
<username produser entered>
Last login: Fri Sep 18 13:13:05 2009 from hostother
/bin/ksh: Not ownerConnection to host closed.
Hmm. The "Not owner" message makes me think that the SSH server couldn't change the ownership of the pseudo-terminal to be the name you specified. Usually that means the user doesn't exist or the user id numbers assigned to the user is outside the allowable range of values.
Check the stats for that user and look for anything unusual. Compare the entry to another username that works fine.
Thanks for reply but, unfortunately, I don't know where to go to get the info you mention for me to check.
There is a file called "/etc/passwd", where the user should have a corresponding line. Depending on the systems OS it should look like (or very similar to) this:
produser:x:1000:1000:Production User:/home/produser:/bin/ksh
Depending on your systems OS there might be several other files and/or commands outputs which might shed some light on this.
In case it is an AIX system: the users corresponding stanza in /etc/security/passwd if there is one and the output of "lsuser produser" issued as root.
To know what system you are on (and which OS you want to connect to) wouldn't hurt either. Also interesting would be the type of authentication you are using: local passwords, kerberos, NIS, NISplus, LDAP, other directory services?
Bottom line: describe your system better and help us to help you.
bakunin
If he doesn't know where to get the information, he also won't have the authority to fix it. So it's probably moot. Time for him to call his sys admin support center.
He has also asked this in the shell programming forum. I was curious so I tried to duplicate it on my home system and then went and had a look at the source code for ksh. It is not coming from it.
While reviewing the answers he provided to my queries, I noticed that I hadn't asked the most important question:
What is the goal of the effort?
Guess I've been doing this for too long because my internal flags went up....
Anyone doing that to my data center would raise a security alert. "Why?" you ask?
- Stated that he has valid creds that allow him access to systems
- Said he doesn't normally access those servers
- Said he is using produser@host as the probing login id - interesting user name to go probing unknown system with
- Doesn't seem to have enough understanding of Solaris 10 or unix systems to collect account setup information of the failing account when logged in using his personal creds.
- Hasn't contacted his SysAdmins or support people to resolve the issue
There probably is a good reason for his efforts and I'm not saying he doesn't have a justifiable reason to do what he is doing. Just that it may be better to error on the side of caution.
Yep, exactly. And numbers 4 and 5 were the deciding factors for me to stop providing any help.