root account can ssh, but can't telnet, why ?

[yyghp]

Now I can use ssh to login to Redhat with root account, but when I try to telnet, it failed:

# telnet host1
Trying...
Connected to host1
Escape character is '^]'.
Local flow control on
Telnet TERMINAL-SPEED option ON
Red Hat Enterprise Linux ES release 3 (Taroon Update 2)
Kernel 2.4.21-15.0.3.ELsmp on an i686
login: root
Password:
Login incorrect


I have setup telnetd properly.
And I can login the system with "oracle", both ssh and telnet.
Why just "root" doesn't work ?

Thanks !

[Rick Garland]

Could it be that you have root logins only on the console?

For ssh this config is set through the sshd_config file abd you can say NO to PERMIT ROOT LOGINS

For the telnet, check the /etc/securetty file and see if root logins are on console only.

[Muthukumar_5 · Accepted solution]

We can deny root login(s) of telnet using /etc/securetty file.

If it contains an entry as,

console

It will deny to login as root on telnet login service.

You can knew it more on login man page.

HTH.
+muthu+

[Alexander Chuzhoy]

To add the ability of root's login via telnet simply add lines with
pts/0
pts/1
pst/2
pts/3
and so on ...
untill at least
pts/20

to /etc/securetty

remember though that this is very unsecure.

[Thomas Bianco]

as microsoft likes to say "this behaviour is by design"

telnet, as it channels everything through clear, exposes any passwords sent over it to snooping. root password + exposed in clear = very bad things

SSH encrypts everything. so it doesn't have this issue.

i think you'll need to do one of the following:

1) telnet as some other normal user and su (recomended)
2) do as the last post states and change the secure tty behavior (not recomended).

[Unnikrishnan]

hi..

as everybody mentioned the problem is with /etc/securetty file only. but considering the security factor don't put pseudo terminal types in /etc/securetty file. it is always recomended to login as a normal user and then do a su - (switch user) from there.

regards
uk

[Thomas Bianco]

to be really honest, suing to root across telnet isn't much better, as the password still goes over clear.

if this is an internet facing host, using telnet is asking to be hacked.

most versions of redhat (and all other secure by default systems) ship with telnet disabled. SSH is MUCH MUCH (repeat, ad infinitum) MUCH better.

infact, most secure by default installs don't even trust the TTYs, as they're unencypted and can be snooped also.

[Lee Thoong Ching]

I suppose most of you guys answered the question already. Ya, Redhat or Fedora or I suppose most of the other distro as well , disabled root login by telnet. Most ppl would have done su - after telnet with another username which is against the whole idea of preventing root telnet in the first place. So , I would suggest you just stick with ssh, since it's more "reliable". : )

[rmueller58]

If you wish to disable pts/ssh root access you will need to modify your sshd_config file and add the following:

Securing SSH
In the /etc/ssh/sshd_config file change the following lines (if it is commented out, remove
the #):
Protocol 2
PermitRootLogin no
PermitEmptyPasswords no
Reboot your system (you installed a new kernel when you updated the installation, and
changed the SSH config, so a reboot is necessary).

By default Linux does have a /etc/securetty file, if this file exist root cannot telnet, if the file exists telnet is allowed:

I don't recommend connection via root either way, especially if system is exposed to the world. SSH can be root compromised, as can telnet. Why risk it?

If you must use root, be on the console OR
su -
It's plain lazy to not do that. And can jeopardize your livelihood.

[Steven E. Protter]

Openning up root telnet is a security problem.

Not disabling root ssh is not. Secure Shell transmits passwords in encrypted format. If they are sniffed they are useless to whoever gets them.

For more security you can exchange public keys with the document I'm attaching as a courtesy.

The bottom line is root needs shell access between systems. It is not laziness to allow that.

I suggest if the author doesn't want this thread popped to the top again since its obviously got a solution in it that he or she close it.

SEP

[Steven E. Protter]

doc

[Sergej_5]

You just have to do the following:

1) # mv /etc/securetty /etc/securetty.ORIG
2) In file /etc/xinetd.d/krb5-telnet
replace disable = yes with disable = no

3) And than reload xinetd on command prompt:
# service xinetd reload

I hope this will help!

Regards,
Sergej