by Yilun Zhang, CTO of NKN.org 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 is the reasons: The security of ssh relies on the assumption that user knows the public key of remote machine. This is because ssh uses 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, especially the first time you are establishing a ssh connection when ssh cannot detect remote public key changes. SSH is pretty convenient when I want to log in to a remote machine and do a bunch of stuff. However, very often I want to run just one command on a few remote machines really quickly. Technically I can 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 IPv4 address is becoming rare and pricy (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 is bring up security risks, especially if ssh can be authenticated by password. Very recently we realized that the above issues can be solved by NKN client in an elegant way. 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 they have to be both 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 and stay 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 . It uses 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-shell-daemon nkn-multiclient-js 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 (can establish outbound http and websocket connections). Any software, as long as it has NKN client, can run command using nkn-shell-daemon. Specifically, nkn-shell-daemon is compatible to and you can run command on your node using d-chat Chrome/Firefox plugin or our mobile app (in dev) that supports d-chat.  d-chat nkn-shell-daemon is started as a demo application, but we immediately realized how useful it is and has planned to deploy it to our own 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 for any ideas, suggestions and discussions.
