what happened to user account?

[Rick Garland]

Hi all:

Got a rp7410 with multiple n-pars running HPUX 11.11.

My user account is playing tricks on me. When I ssh to the system using my account it will close the connection. I can telnet to the system using my account OK. Doing some searching I find that the `id` command for my account is listing my UID number but not the account name.

I go into SAM and the account does not exist in the list but when I try to add using the same values it says the account already exists. In the /etc/passwd file it is there and all is OK. I have done the search in SAM for the user list and SAM says the pattern does not exist in the list. The add function says the account does exist.

Anyway, here is the output of the `id` command for my user account.

id uid=1004() gid=122(wheel)groups=101(dba),113(admin)

As can be seen, the account name for the UID 1004 is blank. This is why ssh cannot login. But why is it blank?

[Steven E. Protter]

I've seen some issues where ssh gets a little confused by uid inconsistency between two boxes.

box1: userid steve uid 1004
box2: userid steve uid 1003

I've seen your exact results in that cirucmstance.

The easy fix is to play with uid in /etc/passwd

The hard one is getting ssh updated to a version that doesn't get confused.

SEP

[Simon Hargrave]

Check the passwd: entry in /etc/nwswitch.conf, it may be referencing a NIS server or something?

[Rick Garland]

I've made it a point to have the same UID on all my systems. The other systems I have not seen this happen.

The nsswitch.conf file is set to "files" for the passwd.

I've seen ssh get confused but I don't believe this is an issue in which ssh is the problem.

[Rick Garland]

I got it back. Did a passwd change on the account and it is back.

SAM now shows my account $LOGNAME in its list.

Honest, nothing was done except the `passwd` command against my account as the root user.
# passwd

I am now able to ssh into the system as well.

The uid name field is now populated with the account name (my $LOGNAME).

I was able to do pretty much any task except the ssh.

Any ideas what happened?

[Geoff Wild]

Is this a "trusted" system?

One thing to try, though maybe not the best solution, is delete your account, then recreate it again....


Rgds...Geoff

[Duncan Edmonstone]

Rick,

Have you checked for illegal chars in your entry in /etc/passwd (using cat -v /etc/passwd)

HTH

Duncan

[Rick Garland]

Not a trusted system (not yet - soon)
No wierd characters in the passwd file.

I did have that thought to remove and recreate. Doing in SAM would not have worked because SAM does not recognize that the account exists. Can do manually.

[Patrick Wallek]

Is the account name standard length (8 characters or less)?

[Rick Garland]

Yes, $LOGNAME is 8 characters. The passwd is 7 characters or 8 characters - I have 2 passwds that I rotate through. These passwds have uper and lower, special characters, numerals and alphas.

The $LOGNAME is just 8 characters all alpha.

[RAC_1]

Egar to know, what message ssh was giving.
You must have run pwc, grpck when that was happening. Did you?

Anil

[Rick Garland]

There were no errors for the /usr/sbin/pwck and grpck. Doing a ssh to the remote system produced the "remote connection closed" message when there was no $LOGNAME, telnet would still work.

The versions of ssh are A.03.10.002 on all systems.

[RAC_1]

Now, when it is resolved, we can say that it was because LOGNAME was not displayed. ssh -vvv and sshd -ddd on server could have given this information in details.

Just a thought.

Anil

[Rick Garland]

Thanks to all. To restate, I do not believe this was an issue caused by ssh. The ssh found the issue of no $LOGNAME with my account and acted accordingly.

SAM could not "see" the account yet when I try to add the account via SAM it would display the message "account already exists" - yet looking at SAM display and doing a search did not find the account.

I was able to telnet to the system.

The pwck and grpck produced no errors related to this account (the pwck produced 2 errors saying the "login directory not found" - the grpck produced errors stating that several LOGNAMEs did not exist, I am in process of cleaning)

I did not run ssh -v because it would have told me something I already know, the $LOGNAME for this account does not exist.

[Geoff Wild]

Is the SAM db corrupt somehow?

Do you have patch PHCO_28007 installed?

Rgds...Geoff

[Rick Garland]

Doing it again!

Some of the info requested:

ssh -v from my desktop to the HPUX server:
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to hsgccu21 [10.60.92.24] port 22.
debug1: Connection established.
debug1: identity file /home/rgarland/.ssh/identity type -1
debug1: identity file /home/rgarland/.ssh/id_rsa type -1
debug1: identity file /home/rgarland/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hsgccu21' is known and matches the RSA host key.
debug1: Found key in /home/rgarland/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/rgarland/.ssh/identity
debug1: Trying private key: /home/rgarland/.ssh/id_rsa
debug1: Trying private key: /home/rgarland/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: Next authentication method: password
rgarland@hsgccu21's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: request pty-req
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel 0: request x11-req
debug1: channel 0: request shell
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to hsgccu21 closed by remote host.
Connection to hsgccu21 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 79 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 621.6
debug1: Exit status -1


Try to do ssh on the HPUX host and login again:
"You don't exist, go away!"

In the syslog on the HPUX server:
Aug 31 12:19:53 hsgccu21 sshd[1306]: fatal: login_get_lastlog: Cannot find accou
nt for uid 1004

I do not have the PHCO_28007 patch. I would like to know why on this system but not another system which has same patch levels, OS rev, hardware, etc.

Again, the output from the `id` command:
uid=1004() gid=122(wheel) groups=101(dba),113(admin)

[Rick Garland]

Trying the passwd command is not working as it replies "Invalid login name."

[Rick Garland]

put it back on top.