Telnet Login Fails

I have a RedHat 6.1 server for an Intranet that my predessessor put up, works fine.  It is remotely located from me, as Administrator, in our building and I need to update our Thwate certificate.  When I try to use Telnet I connect correctly and get the correct response, but when I try to login I get an error stating I have the incorrect name or password.  I am using the same name and password as when I login locally and yes, I am using the correct capitalization, as required.  Why can I log in on this server locally but not telneting from a remote workstation.  Flat network, same segment.

daveM
LVL 6
d50041Asked:
Who is Participating?
 
ahoffmannConnect With a Mentor Commented:
> .. the deny file has a line that reads: ALL:192.168.151.51

That's the reason why you cannot login.
Set this according your policies, or remove it. Then restart inetd.
0
 
ahoffmannCommented:
could you please post the exact error message
0
 
vsamtaniCommented:
Are you trying to log in as root?

Root login over telnet is usually disabled because it's such a security risk. If you want to allow it, look for a file /etc/securetty. This lists the consoles from which root is allowed to log in, and usually it just lists the local consoles (tty1..n). To allow root logins over telnet, you can rename this file to (for example) /etc/securetty.disabled. Remember to rename it back afterwards.

Vijay

0
[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

 
d50041Author Commented:
vsamtani

I think you are on to the cause but there is no such file as securetty in the /etc folder. There is a /etc/security folder.  Can you repost what file this info is located in??
0
 
ahoffmannCommented:
the exact error message would be graet.
So we can avoid barking up the wrong tree ...
0
 
d50041Author Commented:
There is no error message, after I type Telnet xxx.xxx.xxx.xxx I get the proper response from the RedHat server and the Login prompt, then, after entering the user name, I get the password prompt.  After entering the password the server response is "Login Incorrect".  I am using exactly the same login as when I at at the server console.  And I am not using any uppper case characters.
0
 
vsamtaniCommented:
We really need to see the output in /var/log/messages and /var/log/secure at the time that you try and fail to log in.

Are you trying to log in as root?

Vijay
0
 
vsamtaniCommented:
We really need to see the output in /var/log/messages and /var/log/secure at the time that you try and fail to log in.

Are you trying to log in as root?

Vijay
0
 
ahoffmannCommented:
> "Login Incorrect".
.. is an error message :)

is it an ordinary user or root to log in?
Did you check /etc/hosts.{allow,deny} ?
0
 
d50041Author Commented:
Here are the "messages"

/etc/hosts:

# /etc/hosts for intranet.mesadev.org

# for loopbacking
127.0.0.1     localhost.localdomain     localhost

# This machine

# Other hosts on the network
192.168.151.11     database.mesadev.org     database
192.168.151.2     intranet.mesadev.org      intranet
192.168.151.8     mds.acsol.net
192.168.151.51  sys157.mesadev.org

/var/log/messages:


Jul 30 10:09:05 intranet PAM_pwdb[1940]: authentication failure; (uid=0) -> root for login service
Jul 30 10:09:06 intranet login[1940]: FAILED LOGIN 1 FROM sys157.mesadev.org FOR root, Authentication failure
Jul 30 10:09:57 intranet inetd[402]: pid 1939: exit status 1

/var/log/secure:

Jul 30 10:08:56 intranet in.telnetd[1939]: connect from 192.168.151.51
0
 
vsamtaniCommented:
Hmm - trying to remember how RH6.1 dealt with this. Have a look to see if you have one or both of

/etc/hosts.allow
/etc/hosts.deny

If you do, then rename them both so that they won't be read. (This again makes your system less secure, so you should also read the man pages for these files so that you can assess the implications of removing them).

Vijay
0
 
d50041Author Commented:
The server has both files in that directory.  There are no stations listed in the allow file, the deny file has a line that reads:

ALL:192.168.151.51

that's my station, however I cannot telnet from any station.
0
 
housetierCommented:
you alos could log in with a normal user account and then "su -" to root...

---Lasse
0
 
dkloesCommented:
vsamtani is correct that telnet login as root is prohibited as a security measure.  housetier has the appropriate solution to how you should access the root account.  To verify, try logging in as another user account - it will probably work.  If not, that will tell us that you have other problems.  The allow file is read first and should have the IP or network addresses of those you want to allow.  The deny file should have ALL others.
0
 
GnsCommented:
The /etc/hosts.deny entry is perhaps troublesome, but probably not the reason telnet fails for root (if it was, no telnet session could be "connected" at all).

I have a last surviving RH6.1 box, so I don't have to guess.
Let's look at why it doesn't work.

The authentication "mode" for telnet sessions is controlled by -a option to to "in.telnetd". The default (no -a option) is off - which in turn means that all user authentication (in the clear) will be defered to the login program. You can check what "mode" has been chosen on your system with, by looking at the telnet line in /etc/inetd.conf (since inetd is very likely to have been used to start telnet services).
In any event the login program gets spawned, which on RH6.1 use PAM (Pluggable Authentication Modules).
Exactly what modules are "stacked" on your system can be found in /etc/pam.d/login, the lines starting with "auth" are the relevant ones.
On a plain vanilla RH6.1, these would be pam_securetty.so, pam_pwdb.so and pam_nologin.so.
login will check (through the pam_securetty.so module) for the existance of the file /etc/securetty (if there is one, check that the terminal device is mentioned (without the /dev/ part), or deny root access. If the file doesn't exist, log that and then allow root access), and the existance of the /etc/usertty file which (through an arcane syntax) can allow/deny any user based on a tight set of criterions.

Now, I've checked that this actually work as stated on my machine, and I've come to some conclusions:

The log entries you've reported look slightly "wrong" for a "plain vanilla RH6.1", so either it isn't RH6.1, or it has been updated with a more recent PAM. This could slightly alter log entries, default settings and behaviour.

You might have misstyped when checking for /etc/securetty (you should have a log entry otherwise mentioning that it wasn't found).

You might have a /etc/usertty file that is the culprit denying the remote root-logon.

You have already recieved advice as to a good workaround (plain user -> su), so I'll just belabour this point: telnet _is_ insecure. You shouldn't use it if you can help it, and if you have to use it, please see to it that it is in a controlled network environment.
In a perfect world, telnet would be as obsoleted as the horrid 'r'-commands.

The information above was readily available in the man-pages on the system:
man in.telnetd login

-- Glenn
0
 
d50041Author Commented:
Lots of useful feedback and comments.  Thanks to all

daveM
0
All Courses

From novice to tech pro — start learning today.