by Yilun Zhang, CTO of nkn.org (first published on Hacker Noon)

I use ssh everyday and I love it, but I have to admit that ssh is not ideal in terms of security and convenience. Here are the reasons:

The security of ssh relies on the assumption that a user knows the public key of the remote machine. This is because ssh uses an IP address for packet delivery and a public key for encryption. Since there is no intrinsic relationship between the IP address and public key, some prior knowledge or PKI (public key infrastructure) is required to prevent man in the middle (MITM) attack, otherwise a middle man is able to see and modify all communication between you and the remote machine. HTTPS faces the same problem and solves it by predefined trusted certificates. But for ssh, either you know the remote public key yourself, or you have to pray that no middle man is attacking you. This is especially true the first time you are establishing an ssh connection when ssh cannot detect remote public key changes.

SSH is pretty convenient when I want to log in to a remote machine. However, very often I want to run just one command on a few remote machines really quickly. Technically, I could use ssh xxx cmd to run just one command, but it makes the command history quite messy unless I use a separate tab for each remote machine, not to mention that I have to tolerate a tcp handshake for each command.

Another thing that makes SSH not-so-secure and not-so-convenient is that the remote machine needs to be directly accessible by IP and port. Typically it means that either the remote machine needs to have a public IP address, or you need to set up port forwarding. Given the fact that public IPv4 addresses are now becoming rare and pricey (e.g. Google Cloud will no longer provide free external IP address starting from 2020), and IPv6 still has a long way to go, this will become a more serious issue. In addition, exposing your machine to the public Internet brings up security risks, especially if ssh can be authenticated by password.

Very recently, we realized that the above issues can be solved by the NKN client in an elegant way. The NKN client enables free end to end data transmission in a purely decentralized way. Prior to NKN, if a sender client (a mobile app, for example) wants to send some data to a receiver client, the receiver needs to be publicly accessible, which is not practical for consumer applications, or both sender and receiver need to be connected to some centralized server/platform, which will introduce additional cost (to build a relay service or pay for the service) and security vulnerability (data exposed to centralized server or 3rd party service). But now with NKN client, both sender and receiver can remain private in any network condition, and they don’t need any centralized server or platform. The data will be routed and delivered in a purely decentralized way, end to end encrypted, and free. This is made possible thanks to the NKN public blockchain.

We created a simple Node.js application called nkn-shell-daemon 1. It uses nkn-multiclient-js to listen for messages that are end to end encrypted and sent from a list of authorized addresses or public keys. Then it parses the messages as shell commands, executes them, and sends back results from stdout or stderr. The above issues are naturally solved:

• NKN client address contains public key and is used for both routing and encryption, which enables end to end encryption without any PKI.
• Remote machine does not need to have a public IP address or publicly accessible. The only requirement is that it has Internet access and can establish outbound http and websocket connections.
• Any software, as long as it can use the NKN client, can run a command using nkn-shell-daemon. For example, nkn-shell-daemon is compatible with [d-chat 1](http://gitlab.com/losnappas/d-chat 1) and you can run a command on your node using d-chat Chrome/Firefox plugin or our mobile app (in dev) that supports d-chat.

The current version of nkn-shell-daemon uses a request-response model and does not support streams in order to be compatible with d-chat. However, this capability could be extended given a more suitable and specialized frontend interface.The nkn-shell-daemon started as a demo application, but we immediately realized how useful it is and have since deployed it to our own nCDN nodes. Very soon we will use nkn-shell-daemon for node management, nCDN configuration updates, status monitoring and more. We believe it has greater potential and we welcome your ideas, suggestions and discussions around new use cases for NKN shell.