SSH with No Open Ports - Secure Open Source Remote Access 

TCP Connectivity does indeed go through a rendezvous/relay point. But each connection is on a new TCP port and authenticated using standard PKI. But importantly the traffic itself is then encrypted with an AES256 key that only the client machine and the remote device have. The AES key is derived on the client machine and sent (again end to end encrypted) to the remote device. Bottom line yes the proxy server could be attacked but it itself has only random ports open and every connection is cryptographically challenged. But even then it never has anything of value, by which I mean it never sees anything in the clear and never has the encryption keys for the TCP connection or SSH keys.

Agreed, and you can use an IP whitelist at the cloud provider level instead of making port 22 open to the internet.

The whole of SSH No Ports is open source so no proprietary code, you can read on the Atsign website blog why in a post just this week. We take many precautions to ensure that there is no surface for intervention in SSH No Ports. Before an SSH session is started, all 3 entities (client, server and relay), must perform a signature verification proof to verify them. We then take the precaution of cutting a new AES stream encryption key, and ephemeral SSH key pair on the local machine. These are transmitted to the SSH server entirely edge-to-edge encrypted (the encryption keys are stored at each edge, we couldn't decrypt the data even if we tried). Then both sides proceed to authenticate to the relay, which doesn't have the stream encryption key (so it also cannot decrypt the data stream from either end, preventing the intervention of a MitM or preauth attack). Then we proceed with an ephemeral SSH tunnel to port 22 which your client can connect to over the loopback interface. So yes we are security and privacy advocates and write everything in the open

The whole of SSH No Ports is open source so no proprietary code, you can read on the Atsign website blog why in a post just this week. We take many precautions to ensure that there is no surface for intervention in SSH No Ports. Before an SSH session is started, all 3 entities (client, server and relay), must perform a signature verification proof to verify them. We then take the precaution of cutting a new AES stream encryption key, and ephemeral SSH key pair on the local machine. These are transmitted to the SSH server entirely edge-to-edge encrypted (the encryption keys are stored at each edge, we couldn't decrypt the data even if we tried). Then both sides proceed to authenticate to the relay, which doesn't have the stream encryption key (so it also cannot decrypt the data stream from either end, preventing the intervention of a MitM or preauth attack). Then we proceed with an ephemeral SSH tunnel to port 22 which your client can connect to over the loopback interface. So yes we are security and privacy advocates and write everything in the open You can also look and Audit the code yourself: github.com/atsign-foundation/noports\ Read more on Why we choose Open Source: atsign.com/resources/articles/why-open-source/

This is a good point, however, port knocking is susceptible to man in the middle attacks. The knocking sequences can be intercepted (and potentially modified to the attacker's liking). Not to mention an attacker can impersonate the server itself. With No Ports, the atSigns communicating are the only ones that can send and receive data through the use of keys. It's interesting stuff, you can learn more about it on their website: www.noports.com/sshnp-how-it-works

That is correct if you know the IP addresses you will being accessing the SSH server from. But if you are on the road or coming from a mobile device you will not know the IP address you will be coming from hence it really has to be as open as this in most cases.

You should check out the rest of the videos on the channel ;) for example: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-HSthe7wVGao.html