| Message ID | 1426066527-23021-1-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Superseded |
| Headers | show |
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: > If target has connection to the network it might be pretty useful to > have telnet connection to it instead of serial console or even in > addition to serial console. > Even though it's possible to add telnetd on target manually via: > [a] Busybox - with "make busybox-menuconfig" and in "Networking > Utilities" select "telnetd" > [b] xinetd > Still additional manual steps will be required to allow root login over > telnet. > With this change it will be possible to get telnetd built and installed > on target with only enabling BR2_SYSTEM_STANDALONE_TELNETD option in > Buildroot configuration utility or in boards defconfig. > Note that telnetd won't auto-start on boot because of securilty concerns > - until user manually starts telnetd while connected via serial console > there's no chance for unexpected root access to the target (this is > especially true if root has no password set - which is by defult). Any specific reason why you don't just configure a root password and enable dropbear instead?
Hi Peter, On Wed, 2015-03-11 at 17:22 +0100, Peter Korsgaard wrote: > >>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: > > > If target has connection to the network it might be pretty useful to > > have telnet connection to it instead of serial console or even in > > addition to serial console. > > > Even though it's possible to add telnetd on target manually via: > > [a] Busybox - with "make busybox-menuconfig" and in "Networking > > Utilities" select "telnetd" > > [b] xinetd > > > Still additional manual steps will be required to allow root login over > > telnet. > > > With this change it will be possible to get telnetd built and installed > > on target with only enabling BR2_SYSTEM_STANDALONE_TELNETD option in > > Buildroot configuration utility or in boards defconfig. > > > Note that telnetd won't auto-start on boot because of securilty concerns > > - until user manually starts telnetd while connected via serial console > > there's no chance for unexpected root access to the target (this is > > especially true if root has no password set - which is by defult). > > Any specific reason why you don't just configure a root password and > enable dropbear instead? Well I though of telnet as an essential replacement of serial console especially for development boards. So my main intention was to get the most convenient tool for wide range of developers. For example in Windows if I'm not mistaken Telnet client is available right from MS, while SSH client is always 3rd-party program like Putty. Also ability to not set password is convenient here - because people will ask "what's the password" otherwise. Still in case of devboards we have limited access to the network for foreigners so we may not care much about paranoid safety. Indeed your proposal may work if my motivation is not convincing enough. -Alexey
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: Hi, >> Any specific reason why you don't just configure a root password and >> enable dropbear instead? > Well I though of telnet as an essential replacement of serial console > especially for development boards. These days I would say ssh is much more common. > So my main intention was to get the most convenient tool for wide range > of developers. > For example in Windows if I'm not mistaken Telnet client is available > right from MS, while SSH client is always 3rd-party program like Putty. If I'm not mistaken Windows no longer comes with telnet out of the box. E.G. first Google hit: http://social.technet.microsoft.com/wiki/contents/articles/910.windows-7-enabling-telnet-client.aspx > Also ability to not set password is convenient here - because people > will ask "what's the password" otherwise. Still in case of devboards we > have limited access to the network for foreigners so we may not care > much about paranoid safety. Don't they ask the same about the serial login password? > Indeed your proposal may work if my motivation is not convincing enough. I can still be convinced, but my initial thought is that it isn't really a common enough use case / we should promote ssh instead.
Dear Alexey Brodkin, On Wed, 11 Mar 2015 12:35:27 +0300, Alexey Brodkin wrote: > +config BR2_SYSTEM_STANDALONE_TELNETD > + bool "Enable telnet daemon on target" > + depends on BR2_PACKAGE_BUSYBOX > + depends on !BR2_PACKAGE_XINETD In any case, this should not be a system/Config.in option, but a Busybox package sub-option. Or, since your system/Config.in option actually doesn't do anything about telnetd, it simply configures /etc/securetty, then the option should be named differently. Best regards, Thomas
Hi Peter, On Wed, 2015-03-11 at 17:53 +0100, Peter Korsgaard wrote: > >>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: > > Hi, > > >> Any specific reason why you don't just configure a root password and > >> enable dropbear instead? > > > Well I though of telnet as an essential replacement of serial console > > especially for development boards. > > These days I would say ssh is much more common. > > > So my main intention was to get the most convenient tool for wide range > > of developers. > > > For example in Windows if I'm not mistaken Telnet client is available > > right from MS, while SSH client is always 3rd-party program like Putty. > > If I'm not mistaken Windows no longer comes with telnet out of the box. > > E.G. first Google hit: > > http://social.technet.microsoft.com/wiki/contents/articles/910.windows-7-enabling-telnet-client.aspx Well probably it was in days of WinXP when Telnet was pre-installed. Still as you may see from the article - there's a way to install "native" Telnet client from Windows update/software sources. > > Also ability to not set password is convenient here - because people > > will ask "what's the password" otherwise. Still in case of devboards we > > have limited access to the network for foreigners so we may not care > > much about paranoid safety. > > Don't they ask the same about the serial login password? That's exactly the point for serial port as well as for Telnet we may not use password for root - which is a default case in Buildroot. > > > Indeed your proposal may work if my motivation is not convincing enough. > > I can still be convinced, but my initial thought is that it isn't > really a common enough use case / we should promote ssh instead. I tried your proposal with Dropbear but frankly with not much luck. What I did: [1] Enabled "dropbear": BR2_PACKAGE_DROPBEAR=y [2] Set root password: BR2_TARGET_GENERIC_ROOT_PASSWD="xxx" What's nice Dropbear auto-starts on boot. But... Now on attempt to ssh to the target I see: --->8--- $ ssh root@192.168.218.2 root@192.168.218.2's password: PTY allocation request failed on channel 0 shell request failed on channel 0 --->8--- Even though I see devpts is correctly mounted to /dev/pts and /dev/ptmx exists. So probably I'm missing something. Another inconvenience I discovered with SSH - every time I boot my target it gets new fingerprint and then on attempt to ssh to the target I see: --->8--- $ ssh root@192.168.218.2 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is 82:b8:c2:cf:88:d6:19:77:60:23:ff:9b:cc:3e:3d:2c. Please contact your system administrator. Add correct host key in /home/abrodkin/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/abrodkin/.ssh/known_hosts:49 ECDSA host key for 192.168.218.2 has changed and you have requested strict checking. Host key verification failed. --->8--- I may assume this is because I have filesystem built-in kernel (vmlinux) so between boots filesystem doesn't preserve any information - but in case of simulators we usually don't have any other options. -Alexey
Alexey, On Thu, Mar 12, 2015 at 4:04 AM, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > Hi Peter, > > On Wed, 2015-03-11 at 17:53 +0100, Peter Korsgaard wrote: >> >>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: >> >> Hi, >> >> >> Any specific reason why you don't just configure a root password and >> >> enable dropbear instead? >> >> > Well I though of telnet as an essential replacement of serial console >> > especially for development boards. >> >> These days I would say ssh is much more common. >> >> > So my main intention was to get the most convenient tool for wide range >> > of developers. >> >> > For example in Windows if I'm not mistaken Telnet client is available >> > right from MS, while SSH client is always 3rd-party program like Putty. >> >> If I'm not mistaken Windows no longer comes with telnet out of the box. >> >> E.G. first Google hit: >> >> http://social.technet.microsoft.com/wiki/contents/articles/910.windows-7-enabling-telnet-client.aspx > > Well probably it was in days of WinXP when Telnet was pre-installed. > Still as you may see from the article - there's a way to install > "native" Telnet client from Windows update/software sources. > >> > Also ability to not set password is convenient here - because people >> > will ask "what's the password" otherwise. Still in case of devboards we >> > have limited access to the network for foreigners so we may not care >> > much about paranoid safety. >> >> Don't they ask the same about the serial login password? > > That's exactly the point for serial port as well as for Telnet we may > not use password for root - which is a default case in Buildroot. > >> >> > Indeed your proposal may work if my motivation is not convincing enough. >> >> I can still be convinced, but my initial thought is that it isn't >> really a common enough use case / we should promote ssh instead. > > I tried your proposal with Dropbear but frankly with not much luck. > What I did: > [1] Enabled "dropbear": BR2_PACKAGE_DROPBEAR=y > [2] Set root password: BR2_TARGET_GENERIC_ROOT_PASSWD="xxx" > > What's nice Dropbear auto-starts on boot. But... > > Now on attempt to ssh to the target I see: > --->8--- > $ ssh root@192.168.218.2 > root@192.168.218.2's password: > PTY allocation request failed on channel 0 > shell request failed on channel 0 > --->8--- > > Even though I see devpts is correctly mounted to /dev/pts and /dev/ptmx > exists. > > So probably I'm missing something. > > Another inconvenience I discovered with SSH - every time I boot my > target it gets new fingerprint and then on attempt to ssh to the target > I see: > --->8--- > $ ssh root@192.168.218.2 > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle > attack)! > It is also possible that a host key has just been changed. > The fingerprint for the ECDSA key sent by the remote host is > 82:b8:c2:cf:88:d6:19:77:60:23:ff:9b:cc:3e:3d:2c. > Please contact your system administrator. > Add correct host key in /home/abrodkin/.ssh/known_hosts to get rid of > this message. > Offending ECDSA key in /home/abrodkin/.ssh/known_hosts:49 > ECDSA host key for 192.168.218.2 has changed and you have requested > strict checking. > Host key verification failed. I solved this by copying the SSH keys in /etc to the filesystem overlay. SSH won't regenerate them every boot if they already exist, so it will speed up your boot time and get rid of this warning. I'm not sure you'd want to do that for your production builds though. > --->8--- > > I may assume this is because I have filesystem built-in kernel (vmlinux) > so between boots filesystem doesn't preserve any information - but in > case of simulators we usually don't have any other options. > > -Alexey > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi Mike, On Thu, 2015-03-12 at 08:59 -0400, Mike Williams wrote: > > Another inconvenience I discovered with SSH - every time I boot my > > target it gets new fingerprint and then on attempt to ssh to the target > > I see: > > --->8--- > > $ ssh root@192.168.218.2 > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > > Someone could be eavesdropping on you right now (man-in-the-middle > > attack)! > > It is also possible that a host key has just been changed. > > The fingerprint for the ECDSA key sent by the remote host is > > 82:b8:c2:cf:88:d6:19:77:60:23:ff:9b:cc:3e:3d:2c. > > Please contact your system administrator. > > Add correct host key in /home/abrodkin/.ssh/known_hosts to get rid of > > this message. > > Offending ECDSA key in /home/abrodkin/.ssh/known_hosts:49 > > ECDSA host key for 192.168.218.2 has changed and you have requested > > strict checking. > > Host key verification failed. > > I solved this by copying the SSH keys in /etc to the filesystem > overlay. SSH won't regenerate them every boot if they already exist, > so it will speed up your boot time and get rid of this warning. I'm > not sure you'd want to do that for your production builds though. Thanks for this hint. Even though I may use this hint myself locally I'm afraid it's not the best solution if others want to use the same Buildroot configuration. Because to make their life easier I'll need to push those SSH keys in public repository - and this won't work for upstreaming the board support in Buildroot. So at least for now SSH doesn't look as an equally simple option as Telnet. Once again - this is because my particular corner-case when rootfs is built in kernel image. If there is some real non-volatile storage on target SSH might be a good option still. -Alexey
Dear Alexey Brodkin, On Thu, 12 Mar 2015 14:35:08 +0000, Alexey Brodkin wrote: > Even though I may use this hint myself locally I'm afraid it's not the > best solution if others want to use the same Buildroot configuration. > > Because to make their life easier I'll need to push those SSH keys in > public repository - and this won't work for upstreaming the board > support in Buildroot. > > So at least for now SSH doesn't look as an equally simple option as > Telnet. > > Once again - this is because my particular corner-case when rootfs is > built in kernel image. If there is some real non-volatile storage on > target SSH might be a good option still. FWIW, I also do kernel development only with an initramfs, and I still use SSH. I simply remove the key from my system using ssh-keygen -R, as suggested by modern OpenSSH versions when you connect to a host for which you have an invalid key locally. Thomas
>>>>> "Alexey" == Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes: Hi, > Well probably it was in days of WinXP when Telnet was pre-installed. > Still as you may see from the article - there's a way to install > "native" Telnet client from Windows update/software sources. Yes, but it doesn't seem significantly easier than google + pytty + "I feel lucky". >> Don't they ask the same about the serial login password? > That's exactly the point for serial port as well as for Telnet we may > not use password for root - which is a default case in Buildroot. With ssh you could use a ssh key instead. >> >> > Indeed your proposal may work if my motivation is not convincing enough. >> >> I can still be convinced, but my initial thought is that it isn't >> really a common enough use case / we should promote ssh instead. > I tried your proposal with Dropbear but frankly with not much luck. > What I did: > [1] Enabled "dropbear": BR2_PACKAGE_DROPBEAR=y > [2] Set root password: BR2_TARGET_GENERIC_ROOT_PASSWD="xxx" > What's nice Dropbear auto-starts on boot. But... > Now on attempt to ssh to the target I see: ---> 8--- > $ ssh root@192.168.218.2 > root@192.168.218.2's password: > PTY allocation request failed on channel 0 > shell request failed on channel 0 ---> 8--- Odd, I'm using it every day. Anything of interest in syslog? Perhaps you are missing a kernel config. Do you have CONFIG_UNIX98_PTYS=y? > Another inconvenience I discovered with SSH - every time I boot my > target it gets new fingerprint and then on attempt to ssh to the target > I see: Yeah, that's part of the extra security of ssh. Either drop the cached key or add pregenerated keys in your rootfs. > I may assume this is because I have filesystem built-in kernel (vmlinux) > so between boots filesystem doesn't preserve any information - but in > case of simulators we usually don't have any other options. You could always add a static set of keys in your rootfs overlay. Not really ideal from a security POV, but still better than telnet.
On 12/03/15 16:10, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Thu, 12 Mar 2015 14:35:08 +0000, Alexey Brodkin wrote: > >> Even though I may use this hint myself locally I'm afraid it's not the >> best solution if others want to use the same Buildroot configuration. >> >> Because to make their life easier I'll need to push those SSH keys in >> public repository - and this won't work for upstreaming the board >> support in Buildroot. >> >> So at least for now SSH doesn't look as an equally simple option as >> Telnet. >> >> Once again - this is because my particular corner-case when rootfs is >> built in kernel image. If there is some real non-volatile storage on >> target SSH might be a good option still. > > FWIW, I also do kernel development only with an initramfs, and I still > use SSH. I simply remove the key from my system using ssh-keygen -R, as > suggested by modern OpenSSH versions when you connect to a host for > which you have an invalid key locally. I put in my .ssh/config: Host 192.168.3.1 HostKeyAlgorithms ssh-rsa User root ForwardX11 no StrictHostKeyChecking no CheckHostIP no UserKnownHostsFile /dev/null But it wouldn't be a bad idea to add an option to dropbear to generate the keys at build time. Regards, Arnout
diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk index a3ac7e7..251de5e 100644 --- a/package/busybox/busybox.mk +++ b/package/busybox/busybox.mk @@ -166,6 +166,14 @@ define BUSYBOX_INSTALL_WATCHDOG_SCRIPT endef endif +ifeq ($(BR2_SYSTEM_STANDALONE_TELNETD),y) +define BUSYBOX_SET_STANDALONE_TELNETD + $(call KCONFIG_ENABLE_OPT,CONFIG_TELNETD,$(BUSYBOX_BUILD_CONFIG)) + $(call KCONFIG_ENABLE_OPT,CONFIG_FEATURE_TELNETD_STANDALONE,$(BUSYBOX_BUILD_CONFIG)) + $(call KCONFIG_ENABLE_OPT,CONFIG_FEATURE_TELNETD_INETD_WAIT,$(BUSYBOX_BUILD_CONFIG)) +endef +endif + # Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any # full-blown versions of apps installed by other packages with sym/hard links. define BUSYBOX_NOCLOBBER_INSTALL @@ -182,6 +190,7 @@ define BUSYBOX_KCONFIG_FIXUP_CMDS $(BUSYBOX_INTERNAL_SHADOW_PASSWORDS) $(BUSYBOX_SET_INIT) $(BUSYBOX_SET_WATCHDOG) + $(BUSYBOX_SET_STANDALONE_TELNETD) endef define BUSYBOX_CONFIGURE_CMDS diff --git a/system/Config.in b/system/Config.in index 9973cc2..aa04cf5 100644 --- a/system/Config.in +++ b/system/Config.in @@ -309,6 +309,30 @@ config BR2_TARGET_GENERIC_GETTY_OPTIONS endmenu endif +config BR2_SYSTEM_STANDALONE_TELNETD + bool "Enable telnet daemon on target" + depends on BR2_PACKAGE_BUSYBOX + depends on !BR2_PACKAGE_XINETD + default n + help + By default user may interact with target via serial port if set in + kernel's command line with "console" option or as a GENERIC_GETTY here + in Buildroot. + + Another useful option if target is connected to the network is telnet. + + For it to work telnet daemon (telnetd) must be installed and + auto-started on target during boot process. + + Note that telnetd won't auto-start on boot because of securilty + concerns - until user manually starts telnetd while connected via + serial console there's no chance for unexpected root access to the + target (this is especially true if root has no password set - + which is by defult). + + Say yes here if you would like to have an ability to telnet on target. + If unsure, say N. + config BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW bool "remount root filesystem read-write during boot" default y diff --git a/system/system.mk b/system/system.mk index 4a1eb4a..ba0ba7b 100644 --- a/system/system.mk +++ b/system/system.mk @@ -16,6 +16,23 @@ endef TARGET_FINALIZE_HOOKS += SYSTEM_SECURETTY endif +ifeq ($(BR2_SYSTEM_STANDALONE_TELNETD),y) +define SYSTEM_SECURETTY_PTS + grep -q 'pts/0' $(TARGET_DIR)/etc/securetty || \ + echo 'pts/0' >> $(TARGET_DIR)/etc/securetty + + grep -q 'pts/1' $(TARGET_DIR)/etc/securetty || \ + echo 'pts/1' >> $(TARGET_DIR)/etc/securetty + + grep -q 'pts/2' $(TARGET_DIR)/etc/securetty || \ + echo 'pts/2' >> $(TARGET_DIR)/etc/securetty + + grep -q 'pts/3' $(TARGET_DIR)/etc/securetty || \ + echo 'pts/3' >> $(TARGET_DIR)/etc/securetty +endef +TARGET_FINALIZE_HOOKS += SYSTEM_SECURETTY_PTS +endif + ifneq ($(TARGET_GENERIC_HOSTNAME),) define SYSTEM_HOSTNAME mkdir -p $(TARGET_DIR)/etc
If target has connection to the network it might be pretty useful to have telnet connection to it instead of serial console or even in addition to serial console. Even though it's possible to add telnetd on target manually via: [a] Busybox - with "make busybox-menuconfig" and in "Networking Utilities" select "telnetd" [b] xinetd Still additional manual steps will be required to allow root login over telnet. With this change it will be possible to get telnetd built and installed on target with only enabling BR2_SYSTEM_STANDALONE_TELNETD option in Buildroot configuration utility or in boards defconfig. Note that telnetd won't auto-start on boot because of securilty concerns - until user manually starts telnetd while connected via serial console there's no chance for unexpected root access to the target (this is especially true if root has no password set - which is by defult). Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- package/busybox/busybox.mk | 9 +++++++++ system/Config.in | 24 ++++++++++++++++++++++++ system/system.mk | 17 +++++++++++++++++ 3 files changed, 50 insertions(+)