For personal reasons, I want to have in my firmware telnet server. How can I do this?
I'm glad you prefaced that
lede_source$ fgrep -i telnet .config # CONFIG_BUSYBOX_DEFAULT_TELNET is not set # CONFIG_BUSYBOX_DEFAULT_FEATURE_TELNET_TTYPE is not set # CONFIG_BUSYBOX_DEFAULT_FEATURE_TELNET_AUTOLOGIN is not set # CONFIG_BUSYBOX_DEFAULT_FEATURE_TELNET_WIDTH is not set # CONFIG_BUSYBOX_DEFAULT_TELNETD is not set # CONFIG_BUSYBOX_DEFAULT_FEATURE_TELNETD_STANDALONE is not set # CONFIG_BUSYBOX_DEFAULT_FEATURE_TELNETD_INETD_WAIT is not set # CONFIG_BUSYBOX_CONFIG_TELNET is not set # CONFIG_BUSYBOX_CONFIG_TELNETD is not set
Sorry.... what I need to do?
You need to build your own image, from scratch, and change the
busybox options within
make menuconfig (or the config tool of your choice). Installing a modified
busybox on the overlay is challenging to do properly and can't be done with
I removed dropbear from my image, and tried to follow this link: https://wiki.openwrt.org/inbox/howto/telnet_enable
but I have problems because some files can not be found.
It's a very, very bad idea<fullstop>
There are still uses of cenvenience for a telnet-client, but a telnet-server must never be used. Accordingly LEDE doesn't support any of the required integration anymore.
I know, but I need this feature
As I recall, you serve as an ISP. That alone would strongly suggest that you look to more secure ways to access the OpenWRT instances than telnet.
Jeff... yes I am.... I need to access the router from telnet to change some settings, like SSID, PPPoE credentials via command prompt. Via Perl using Windows the SSH don't works properly, but using telnet I have a good experience. I'm using DD-WRT, and I have telnet access, but I want to migrate to OpenWrt and I need just to finish this issue.
Then install a proper ssh client on your Windows box. No need to make your OpenWRT installs insecure.
Edit: An advantage of a "proper" ssh connection is that you would be able to install a public key on the box that would allow you the access you need to manage the box (assuming that you need to do so after deployment) without forcing your customers to maintain an insecure box on your network (telnet, root login and known password, for example). See, for example, https://www.us-cert.gov/ncas/alerts/TA18-106A for yet more reasons not to use telnet.
Reverse the configuration from push to pull, and run telnet-client on the end devices perhaps? Then you could run a properly limited telnet client in one spot instead of running a hacked in place telnet client in many spots.
Just sharing an idea.
I really need to double down on this recommendation. If shh isn't working, get a better client. Don't use telnet.
I heard you guys. I changed my system and I'm using Plink (Putty Command Line Tool) to do what I need. Many thanks to all.
Good stuff! Glad we could help.
If your question is solved, please consider marking it as [Solved].