CODEWITHSUNDEEP
embedded-linuxopensshsshdietf-netconfdropbear
NetHead
NetHead

Reputation: 81

Starting a subsystem process with sshd on a constrained embedded system

I am trying to get the yuma123 open source implementation of a NETCONF Server running on an embedded Linux system.

The NETCONF Server uses sshd, and yuma123 appears to assume that it is the openssh implementation of sshd as it uses the /etc/ssh/sshd_config file.

In particular, the README file in yuma123 states: 

Tell sshd to listen on port 830. Add the following 2 lines to /etc/ssh/sshd_config:

Port 830
Subsystem netconf "/usr/sbin/netconf-subsystem --ncxserversockname=830@/tmp/ncxserver.sock"

However, the embedded system currently uses the dropbear cut-down implementation of sshd due to memory constraints, and I am having difficulty getting openssh (together at the same time with yuma123) installed on the embedded system due to the size of the executables, dependant libraries etc.

Can I get/amend the dropbear sshd to give me similar functionality? Can I cut-down the openssh sshd drastically to a small enough size? Any (other) suggestions on a good way forward to resolve this?

Upvotes: 0

Views: 1673

Answers (1)

Kenster
Kenster

Reputation: 25439

According to the dropbear source code, the only subsystem built into the dropbear SSH server is optional support for SFTP, which I'll describe below.

Supporting another subsystem requires making source code changes to dropbear. If that's an option, the code at issue is in the function sessioncommand() in the file svr-chansession.c:

#if DROPBEAR_SFTPSERVER
            if ((cmdlen == 4) && strncmp(chansess->cmd, "sftp", 4) == 0) {
                m_free(chansess->cmd);
                chansess->cmd = m_strdup(SFTPSERVER_PATH);
            } else 
#endif
            {
                m_free(chansess->cmd);
                return DROPBEAR_FAILURE;
            }

Basically, you'd add some code similar to the "sftp" section which checks for your subsystem name and invokes the desired command.

If you don't want to build a custom version of dropbear, then you might be able to make do with a forced command. There are two ways to do this.

If the users of this subsystem will be authenticating with an SSH key, then you could put a "command" directive in the user's authorized_keys file:

command="/usr/sbin/netconf-subsystem..." ssh-rsa AAAAB3NzaC1yc2...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When a client authenticates with the key from this line in the file, then any command, shell or subsystem request from the client will cause dropbear to invoke the listed command instead of the command requested by the client. This is an OpenSSH server feature that's also supported by dropbear.

Alternately, dropbear has a command-line option -c which lets you specify a forced command for all clients:

dropbear -p 830 ... -c '/usr/sbin/netconf-subsystem ...'

Dropbear will invoke the specified command for any client connecting to this dropbear instance. If you want to permit clients to do other things besides running that command, you'd have to run two instances of dropbear, listening on different ports or addresses.

SFTP Subsystem support:

I'll describe this because doesn't seem to be well documented. If dropbear is compiled with the option DROPBEAR_SFTPSERVER, then dropbear will invoke the command "/usr/libexec/sftp-server" for clients requesting the "sftp" subsystem. For that to work, the administrator would normally build a copy of the OpenSSH sftp-server program from the OpenSSH source code, and install the resulting program as /usr/libexec/sftp-server.

Changing dropbear to run a different command requires altering the dropbear source code and recompiling dropbear.

Upvotes: 2

Related Questions