incorrect login on one terminal for one user only

[Inquisitive]

I need help with this one.
On one particular terminal (ttys02) (sane hardware as the other terminals) a certain user gets "incorrect login" after entering their password.
They can log in successfully using the same login & password on all other terminals.
Other users can log in on the terminal in question without a problem.

I cannot find what would be causing the "incorrect login" for one user only on one particular terminal only.

All suggestions eagerly accepted.
TIA
PS - they are not logging in as root.

 

[stanhubble]

not sure about sco but with linux you can restrict a users ability to login by device with the /etc/usertty file. there are also a pile of other filters that you can use in this file.
this may not be the cause of your sco problem but depending on the security level you have implemented it may be something similar.

good luck

 

[abovebrd]

Are all the terminals the same ?

I have noticed that wyse terminals have a different keyboard layout from the standard PC keyboard.

Just tring to ruleout the old "FAT FINGERS" problem.

With that ruled out I would look at the terminal manger

* scoadmin
* security
* Terminal manager

I believe from here you have the ability to lock and unlock tty devices. I think you can even lock users from using specific tty's. Which sounds like the issue yuo are having.

I am not sure which files the terminal manger creates or edits. My guess is this could some how be done from the command line.

-Danny

 

[Inquisitive]

Thank you for the suggestions. I tried them all. No usertty but look for more & similar. Checked scoadmin, etc but could find nothing that would restrict only one specific user on one specific terminal (the others are the same, others can log in on all, this user can log in on others).
Poking around I realized this is on a PortServer.
Researching I found that that on this system a user on a tty maybe locked out but I could not find the correct commnds.
In the meantime the system was rebooted - the problem has gone away. I don;t know if this cleared ossomething on the port sever or not; there was no process running on this tty (other than getty) or for this user when no one was logged in.
SOLUTION: reboot! Thanks for the suggestions.

 

[JCOest]

Is -Solutions reboot- still your solution. I'm having a similar problem currently. What version of SCO are you running and what is the client that connects to the host running for OS and terminal emulation?

 

[edfair]

Reboot clears some stuff that can get screwed up with gettydefs. There is also some stuff that can get screwed up with the terminals. Then there is the cable problem.
Depending on the cable type, distance, and speed, you can get corruption of the signal that will kill logins. It will also create all sorts of other problems too.
What are you using for ports on the SCO, what type of terminals, what speed , and what distance? Ed Fair
unixstuff@juno.com
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[drtrinidad]

On a (digi) PortServer, the portserver itself can present a login before the RealPort driver takes over. This has caused me some problems in the past with people getting 'login invalid'.

In order to tell the portserver not to allow a local login, you can tell it

set ports range=1-16 dev=prn

Newer portservers allow 'dev=rp' but I don't know if there is any advantage other than clarity.

 

[apeasecpc]

It is unlikely that this is a unix lock because someone would have to have set it up that way. You should check your /etc/ttytype file to make sure it is configured the same as the other ports that work.

The terminal hardware settings themselves may be causing the device to operate differently even if it is the same hardware, especially if the user has some unusual characters in their password, or they are mixing upper and lower case letters in their password. I recommend you have the user change their password and try it again.

If that doesn't work, you should try physically swapping the problem terminal with another one to determine if the problem stays with the port or the terminal.