Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi
Whether there is any possibity to login root user using telnet.
Im looking for alternative for ssh login in case any ssh failure.i have to capture my remote server using telnet service .
Don't don't don't don't don't do this. never run telnet.
If you want to deliberately run an insecure network service that is widely discredited you can install the telnet-server package (or equivalent name) and edit the config file, which is probably /etc/xinetd.d/telnet to fine tune the settings.
You really should NEVER be able to log in remotely as root, even over SSH. Use a normal user account, and then elevate to root once logged in. Root over telnet would not be something a good sysadmin would ever willingly do.
If you really want to mitigate against SSH failure then invest in a remote management card for your server which will at least allow you "direct" console access in the event of a daemon failure or see if your hosting provider will provide some form of KVM over IP access.
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
Added to the above abut not running telnet and not logging in as root directly I like the idea of moving SSH to a high port, if you're not already -- especially if you must log in as root for some reason.
If you really want to mitigate against SSH failure then invest in a remote management card for your server which will at least allow you "direct" console access in the event of a daemon failure or see if your hosting provider will provide some form of KVM over IP access.
Exactly.
Just as you don't remove one of your living room walls (in case your front-door lock stops working), you don't enable a clear-text protocol service (in case sshd stops working).
If you cannot install a remote management device, then work with your hosting provider for a plan to address this sort of scenario. It may involve a person physically logging into your server to assist you.
Added to the above abut not running telnet and not logging in as root directly I like the idea of moving SSH to a high port, if you're not already -- especially if you must log in as root for some reason.
It's not security through obscurity in that sense at all. Try going through an auth.log from an SSH server on port 22 looking for succesful brute force attacks compared to one on port 2022. It's pretty much certain your SSH server on the standard port will get hundreds of script kiddies "testing the door handle". Yes, of course, use fail2ban or others but moving the port saves a little time when going through logs and leaves you to concentrate on the more serious attempts.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.