Odd sudo behavior when logging via GSP console over LAN.

[Eric Yruegas]

We have a private-network LAN setup for access to our GSPs for our various 8400's and SuperDomes. Works great to get in and log in as root when necessary. Normally we use 'sudo' to do root things.

I just noticed something very odd. When I connect to the GSP, log in at the console as myself (not root), then issue my 'sudo sh' to get a root shell, my password is NOT accepted! I just typed it in order to log in!?

If I connect direct over the network (SSH), all works as expected.

SUDO version is 1.6.8p9.

Anyone else seen this one? I saw one other thread here in the forums by someone with perhaps the same issue... no joy.

Any help/pointers/insight is appreciated. Thanks!

[Rick Garland]

Do not use sudo when in the GSP.
The Guardian Service Processor does not recognize the OS commands.

Any login to the GSP has the full system priviledges. Again, this is separate from the OS.

[Mel Burslan]

when you come over network, i.e., telnet/ssh, your terminal type is whatever your terminal emulator announces itself to be, whereas when you come through GSP Console, the terminal type must be of some certain variety (check configuration menu on GSP to figure out what it is set to, usually hp700/96). Even though when you type in the password when you are logging in, it is being treated verbatim, character-by-character, once you are at the prompt, you may be using an xterm terminal caps whereas system thinks you are on 700/96 and treating the the input in a different way by adding an extroneous character or something.

Not necessarily with sudo but I have seen weird things happen when you login from a strange terminal while the system thinks you are using something else.

My 2 cents.

[Eric Yruegas]

Just to clarify:

I connect to the GSP, "CO" to the console of my choice, log in to the system on that partition, then issue the sudo command. I'm not trying to do this at the GSP prompts.

TERM type shows as xterm when logging in over network, but vt100 when at the console (environment variable TERM).

I do notice that prior to the "incorrect password" message from sudo, there is a bit of a pause (1/2 second?) prior to the message, whereas when logging in over the network (and deliberately mistyping my password) the error message comes up almost instantly...

Mystery to me...

[Torsten.]

Hi Eric,

I know, sudo is checking $TERM, but I don't know what this is causing.
Try to set your TERM var before issuing sudo.

[Matti_Kurkela]

Sounds like a character conversion/transmission problem.

If the conversion is symmetric (for example, when you press "{" the keypress gets translated to "[" on the way to the server, and the "[" output by the server gets translated back to "{" on the way to your screen) it can't be detected by just typing away and checking what's displayed.

Try this: when using the GSP connection, write all the "special" characters of your password (anything that is not a number nor a US-ASCII letter) into a file on the server. Let's call that "file1". Disconnect and do the same over SSH, creating "file2". Try to make it identical to the first file.

Now compare the files, both by eye and using a server-side tool (like "diff"). Do the files look identical? Does "diff" agree?

Another thing, which may or may not be relevant: when logging as non-root over the GSP, I sometimes seem to get the TERM environment variable set as "dumb". This might cause strange behaviour: check the variable and set it to proper value if necessary before using sudo.

[Devesh Pant_1]

I normally do a sudo su -
and that makes me root
try his instead of sudo sh

thanks
DP

[D Block 2]

Eric- when you come into your Private Lan via GSP, what are your Terminal definitions ?

grep console /etc/inittab

when on the Console or GSP type: $ stty

when on a telnet to your Public IP type: $ stty

any difference ?

Does the Private vs the Public have any TERMIO(7) differences ?

just wondering. pls report to the Forum, thanks.

[Ermin Borovac]

I think Tom is on the right track. I would check the output of 'stty -a' and see if any of the characters that appear in stty output are part of your password string.

[Eric Yruegas]

First off - you guys are great! Excellent ideas...

I did retype my password into a text file on both sessions to make sure that a character wasn't getting translated or dropped. They are identical.

Regarding the stty -a output diffs:

The only differences:

Console - 0 rows, 0 columns.
Public - 43 rows, 102 columns (putty screen size)

Console - eol2 = ^@, swtch = ^@
Public - both are

All other signal defs are the same. No characters in my password appear.

More data: It's not just me - but my other 2 admins have the same issue. Persists across hardware platforms (meaning the GSP for the SuperDomes, 8400's, 7410's... all exhibit the behavior).

Thanks to all again for helping out...

[Devender Khatana]

Hi,

Does your passwords include some special characters like *,#,@ etc. This can also be caused by this.

From "man passwd"
======================================

WARNINGS
Avoid password characters which have special meaning to the tty driver, such as # (erase) and @ (kill). You may not be able to login with these characters.

HTH,
Devender

[Eric Yruegas]

Nope - only special chars are parens ().

[Eric Yruegas]

I think I'll open up a software call through one of my support contracts... Worst they can say is that they'll report the bug back to the OSS community.

[Matti_Kurkela]

Check the syslog (/var/adm/syslog/syslog.log). Normally sudo records any succesful and failed sudo attempts there. There might be a message telling _why_ some of your attempts failed.

[Eric Yruegas]

Syslog was my first stop - all it says is "incorrect password attempt" just like when I *do* fat-finger my password...

[Eric Yruegas]

Ugh.

Unfortunately my support case was closed citing the "OSS iExpress components are not supported by HP".

Anyone else have any ideas?

[Ermin Borovac]

Are you using 'putty' to login to console via GSP? If so, have you tried using another telnet client?

Does direct su to root (from console) work ok?

[Eric Yruegas]

Our GSP's are on a private network, and we multi-home a server in order to access. So to connect to the GSP, we use straight HPUX telnet to connect. I did just try using the Hummingbird product to make my SSH connection to that server prior to the telnet to the GSP, no dice. Only difference appeared to be $TERM (vt200).

Next step is to haul to the data center and directly plug into the console port and see what happens. Bizarre.

[Ermin Borovac]

Just out of curiousity, can you try using sudo -S option? It reads from standard input instead of terminal.

$ sudo -S sh

[Eric Yruegas]

Ermin-

Tried it two ways with -S option - still no go. I typed it in when I was prompted, and then tried the "echo {pw} | sudo -S sh". Ugh.

[Ermin Borovac · Accepted solution]

I just found this

http://www.courtesan.com/bugzilla/show_bug.cgi?id=187

Is your sudo compiled with --with-pam? If so, try compiling without PAM.

[Eric Yruegas]

Ermin-

Great find!!! I'll try that today and see what happens. Thanks for the link!

[Jeff Schussele]

Hi Eric,

Just a note on compiling sudo w/o PAM
If you do this and you are running the LDAP client as well you'll break LDAP. It needs sudo with the PAM option compiled in.

My 2 cents,
Jeff

[Eric Yruegas]

Ack! The recompile will have to be a no-go then. I guess I'll just use a workaround for the foreseeable future.

I appreciate all the input! Great forum.

[Eric Yruegas]

Closing - bug found in underlying OSS product.