Telnet

Telnet is insecure, just so you know, but..

Install telnetd via apt or rpm, then edit /etc/xinet.d/telnet(d) and change disabled=yes to disabled=no, then restart xinetd.

That should do it…

-Chris

just for a tip.. for debian you have install telnetd and then it will automatically put the line for telnet into the /etc/xinet.d file.

EDIT: actually not the /etc/xinet.d file but the /etc/inetd.conf file for debian.

@sec39:

just for a tip.. for debian you have install telnetd and then it will automatically put the line for telnet into the /etc/xinet.d file.

EDIT: actually not the /etc/xinet.d file but the /etc/inetd.conf file for debian.

I understand telnet is insecure but sometimes that is all that is available. I installed telnet and I can perform

telnet localhost and it works

from my home network when I telnet to my linode this is what happens.

YM9007DC:~# telnet xxx.org

Trying 72.14.xxx.xxx…

Connected to xxxx.members.linode.com.

Escape character is '^]'.

Connection closed by foreign host.

YM9007DC:~#

If telnet localhost works but telnet externalipaddress fails then it's probably a restriction in /etc/hosts.allow or /etc/hosts.deny

/me shudders.

Use ssh, man. Carry PuTTY around on a thumbdrive. If that doesn't work, you can always use the ajaxterm from LPM.

@sweh:

If telnet localhost works but telnet externalipaddress fails then it's probably a restriction in /etc/hosts.allow or /etc/hosts.deny

I don't know what distro you are running. You probably have to modify /etc/securetty and add virtual terminals to log in remotely.

Probably something like:

pts/0

pts/1

pts/2

pts/3

pts/4

pts/5

pts/6

pts/7

Then restart inetd or xinetd.

I too would not recomment using telnet on a remote server.

You can use linode's remote console terminal if you can't use putty.

@flb:

I too would not recomment using telnet on a remote server.
Let's do more than just recommend. Let's scream "for the sake of all that's holy don't do it". If anyone, anywhere along the route to your Linode is ever sniffing packets, your box is pwned.

@flb:

I don't know what distro you are running. You probably have to modify /etc/securetty and add virtual terminals to log in remotely.

That's only needed if you want to login as root, which is a REALLY bad idea via telnet!

@pclissold:

Let's do more than just recommend. Let's scream "for the sake of all that's holy don't do it". If anyone, anywhere along the route to your Linode is ever sniffing packets, your box is pwned.

Unless you're smart enough to work out how to use S/Key :-)

I'm with pclissold on this one. Don't log in with telnet! telnet is only good for manually testing other kinds of servers, and telnetd should not be used for any reason.

telnet…… DON'T DO IT

Even go so far as removing/renaming telnetd. The ONLY thing telnet should be used for is as a client to troubleshoot, it's suicide to have the telnet daemon running.

Use ssh, create your main user, put them in the "wheel" group, disable root access and use ssh only to access your box. Then when you need to do root functions just "su - root".

@marcus0263:

Use ssh, create your main user, put them in the "wheel" group, disable root access and use ssh only to access your box. Then when you need to do root functions just "su - root".

Ah, nice to see an old-school unix head. :-)

The more modern version would be "Use ssh, create your main user, and add them to /etc/sudoers, using 'visudo', after reading the sudo and sudoers man pages." Some advantages (IMO) of sudo over su: better control of environment, you enter your password, not roots, the password is cached for a little while, and less flakiness in the syntax for invoking commands.

@SteveG:

@marcus0263:

Use ssh, create your main user, put them in the "wheel" group, disable root access and use ssh only to access your box. Then when you need to do root functions just "su - root".

Ah, nice to see an old-school unix head. :-)

The more modern version would be "Use ssh, create your main user, and add them to /etc/sudoers, using 'visudo', after reading the sudo and sudoers man pages." Some advantages (IMO) of sudo over su: better control of environment, you enter your password, not roots, the password is cached for a little while, and less flakiness in the syntax for invoking commands.
Personally I prefer not using sudo. If you need to conduct root functions just do it as root in root's environment, why add another layer to worry about ya know ;)

I know sudo is popular and a lot of people use it on their desktop. But this also let's people us the GUI for root functions :(

Anyway, yeah I'm old school hell I at work on my corp workstation I use vi as my text editor ;)

@marcus0263:

Personally I prefer not using sudo. If you need to conduct root functions just do it as root in root's environment, why add another layer to worry about ya know ;)

'Cause sudo will log each command you run. That's very nice to have. Even if you're the only admin on the box, sudo logging has saved my butt several times when trying to remember the exact syntax of some obscure command - all it takes is a quick grep through the logs…

@anderiv:

@marcus0263:

Personally I prefer not using sudo. If you need to conduct root functions just do it as root in root's environment, why add another layer to worry about ya know ;)

'Cause sudo will log each command you run. That's very nice to have. Even if you're the only admin on the box, sudo logging has saved my butt several times when trying to remember the exact syntax of some obscure command - all it takes is a quick grep through the logs…
true if you can't find it in "history" ;)

@marcus0263:

true if you can't find it in "history" ;)

Heh. True - well in my case, the syslogs have a lot longer "memory" than .bash_history does.