Although the /etc/securetty file contains entries like pts/0...pts/24
it is not possible to (remote) telnet as root to a SLES10 SP1 system.
The /var/log/messages tells this:

pam_securetty(login:auth):access denied: tty 'pts/0' is not secure !

Normal users are able to remote login and the firewall is off.

Many thanks for all hints!

RainerB.

First of all, don't use telnet... use ssh ... seriously.

Now that that's taken care of. Edit the /etc/ttys or similar file where the pts's are listed and there should be line there which specifies where root can login. Look for entry like secure off or something like that.

That might be the problem.

That is correct. If you have a user who wants to do this, LART them repeatedly until the message sinks in.

The correct tool to remote manage SLES (or, indeed, any system) is openSSH.

@Zmyrgel
Unfortunately there is no such /dev/ttys in SLES 10.

Rainer

Tough.
This is A Good Thing.

You are not going to get much help from us when it comes to compromising your system.
There are enough insecure computers out there without adding yours to the bunch. Did you know that linux servers are favorite for controlling botnets?
http://it.slashdot.org/article.pl?sid=07/10/05/1234217
http://www.net-security.org/secworld.php?id=5129
http://www.mailradar.com/articles/Op...r-8/page1.html

Absolutely do not use telnet... at all.
http://blogs.ittoolbox.com/security/...internet-14547
http://searchsecurity.techtarget.com...ml?track=sy160

What is wrong with ssh?

http://suso.org/docs/shell/ssh.sdf

I have following line in my /etc/ttys [running OpenBSD]:
I need to change the option to following to allow logins from serial:
I think something similar needs to be done on SLED to allow root telnet connections. Have you checked the /etc/securetty file for lines similar to above.
This is still ridiculously unsecure as telnet sends passwords in plaintext and anyone in your network can then get systems root password. You have been warned.

But seriously, if you don't have any other reason but to allow remote logins to the computer, use OpenSSH. It's easier to setup and a lot more secure option than telnet.

Zmyrgel: why are you helping this guy?

Well, I'm such a nice guy

If he wants to compromise his network, fine. As long as it doesn't do it at my networks then it's cool.

I don't know anything beyond what I've said here about getting the telnet to work as root so if he doesn't get it to work then he's on his own.

He might have a reason to get telnet to work as root. I, personally don't have a clue what that could be but he might have a reason.

Unfortunately, compromising his network makes all our networks less secure.

Have a look through those links I provided earlier.

The criminals who get a-hold of his server will most likely use it to run a botnet as a master node. In other words, they will point it at us. Now, removing this one will probably not make the internet much safer for freedom, democracy and fake celebrity pron.... but lets not hand out an extra gun OK?

Lets not help people do dumb things.

Fine.

I still don't get where they even get the ideas to use telnet or better yet, rlogin and such. When I started my Unix-like experiences I didn't hear about them anywhere and used SSH. Only mention to those services where on SSH pages where it clearly states that SSH replaced them.

At least telnet is still useful but not when trying to get a root login to work

I think the only reason telnet is still around is for the windows boxes - it used to be you had to install a 3rd party client to use OpenSSH. Don't know about now. I have met experienced sysadmins who've never heard of SSH. They were all Windows Certified. In the *nix world you cannot move without someone giving you a security lecture. But Windows is about convenience.

The only thing I would use telnet for is remote dubugging eg smtp as

telnet box 25

which enables you to manually send /recv mail cmds to check exactly what the server is saying. In principle any text oriented service can be tested this way.
Definitely wouldn't use it for logging into a terminal, use ssh.

AFAIK: telnet to port 25 need not actually start a telnet session (unless the smtp server also has a telnet service listening on port 25...)- you do not log in or do anything that would not normally be sniffable anyway. It does generate useful system messages. Thus it is a popular method of probing smtp services - especially on MS Exchange-based networks.

What this does is exploit telnet's clear text messages to run a very slow smtp session. In this way, the exact point of trouble can be isolated.

A security issue is that a valid email address is needed... so a throwaway account should be created for testing.

Encrypting the signal is not going to be useful, as smtpd needs to understand instructions.

Of course, I could be wrong here.

Indeed, only one service/daemon/server_sw_component can bind to a given port at a time, so normally it'd be an smtp server on port 25 (see /etc/services) eg sendmail.
The telnet client simply sends ascii text to the host+port specified.
No telnet server required.
In fact you can test your own homegrown/written server(s) if they respond in/to plain text.