The term SSHLA (Secure Shell Layer Application) loosely refers to programs that make use of the SSH system for their secure network operations. There are some really popular SSHLA programs out there.
What's interesting about these programs is that they usually work locally. If you need to use them over the local network, or even the internet, the usage is nearly the same. The only prerequisites are that you can successfully authenticate using SSH, and the program is installed on the remote computer. In the case of VS Code, it can install a local headless (no GUI) copy of itself automatically! Places where you normally specify a file path have a special notation to include the server name, such as "user@remote_host:path/to/a/file.txt" instead of just "path/to/a/file.txt" for the local file.
So, how exactly do SSHLA application work? What's the magic sauce? As it turns out, it's not very complex. First, a program invokes the ssh program (or equivalent client library) to connect to the remote_host.
sshla_program ---runs---> ssh user@remote_host ...
Without any extra arguments this will usually start an interactive shell (bash, zsh, or similar) on the remote_host, which isn't very useful to the program. But, if we give ssh a program to run on the remote server then it will run it to completion. If we run our program on the server then that program will probably have an idea of what we want to do and how to run the remote portion.
ssh user@remote_host sshla_program ...
How does the sshla_program know if it's being run locally or remotely? This is an important question because it will determine whether the program should be handling user interactions, such as bringing up a GUI, prompting for certain questions, or pretty printing the output. Otherwise, it is just acting as a proxy for the local instance's requests. There's a couple of established patterns for this. If we use the approach used by scp then there's a couple of reserved command-line flags that you are not expected to use directly.
scp user@remote_host:path/to/a/file.txt . ----runs----> ssh user@remote_host scp -f path/to/a/file.txt scp file.txt user@remote_host:path/to/a ----runs----> ssh user@remote_host scp -t path/to/a
Git calls internal programs called git-upload-pack and git-recv-pack that are installed with the git client.
git push user@remote_host:git/some_repo ----runs----> ssh user@remote_host git-recv-pack git/some_repo git pull user@remote_host:git/some_repo ----runs----> ssh user@remote_host git-upload-pack git/some_repo
In either case, the remote instance of the program is run in a mode that is prepared to communicate with the local one. Where does this communication happen? Well, it works a bit like a Unix pipe except bidirectionally. The local program sends commands, such as "begin transfer" to the stdin (Standard Input) of the remote instance just like a pipe. SSH makes this largely transparent, like running a local instance. Data is then sent from the remote instance via stdout (Standard Output) back to the local instance. The precise protocol and direction of the bulk of the data transfer is decided by the program itself to communicate with ... itself.
So far we haven't talked about how SSH interacts with the user in this workflow. For example, SSH will prompt for things like adding a new host to the list of known hosts, shown an alert if the host key has changes, or even prompt for the user's password. For command-line programs SSH will run an askpass program on the terminal to ask for these. If there's a GUI program involved then there is an SSH_ASKPASS environment variable that can be set to a graphical prompter program to dialog with the user.
You'll notice that in the above examples with scp and git, the relevant paths are sent to the remote along with distinctive flags/command names for read/write. The remainder of the protocol is done through the bidirectional pipe, which is not easily visible to system administrators. The relevant path and the send/receive variants give system administrators some level of control over the types of operations that they will permit with their server. For example, allowing only the git-upload-pack command and the "scp -f" variant will allow people to read data from the server, but deny writing. Inspecting the paths can block access to certain locations for read, and/or write.
In summary, SSHLA programs aren't all that complicated in how they communicate across a network, which makes it easy to adapt existing programs so that they are network aware. They basically run themselves on the remote computer using SSH, use some internals to set up a bidirectional pipe, and set up their own protocol for remote and local communications. For aspects of an program's protocol that are relevant for system administrative access control, such as the "path" or read/write these should be reflected in the remote command and its arguments.
Conceptually speaking, SSHLA protocols use SSH to run themselves as a program on the remote machine with command name, arguments, and file paths. The file paths are thought of as files that are on the remote filesystem. In reality, the implementation can be much more abstract. Git may not be aware that the server that it connects may be using a complex distributed storage framework employing message buses with caching made possible using libraries, such as libssh and libgit to create the protocol abstractions.
Early web servers were often serving static content directly from files on the server's file system. We now know that web servers can serve up dynamic content based on computation, database, or other complex infrastructure. Not every we "resource" on a website supports every (GET/PUT/POST) verb. The interactions with a resource can be determined using both web server specific and sometimes protocol specific conventions.
The current state of SSH is very similar. Historically, there was an expectation that one could run ssh to get a command-prompt on a remote server. That may still be the case on your own home network with your own infrastructure. In the world of cloud computing there may be only certain commands and workflows that are permitted. Take for instance this SSH server, which doesn't (hopefully) permit a user to get access to a shell, but it does permit running "cat" to read this file. Also, there are other permitted usages described in the MOTD, such as a built-in search function. Try running "ssh supertxt.net" to see for yourself. Not all files on the server can be viewed by anonymous users on the internet.
With enough support for different SSHLA protocols an SSH server could provide a typical internet site experience. The difference is that the user can work with the purpose specific tools that complement the site's purpose.
HAVE SOME FEEDBACK ON THIS DOCUMENT?
You can provide a conventional comment on this document.
ssh nobody@supertxt.net ccmnt whats-sshla.s.txt <<EOF suggestion: Here's my actionable suggestion. EOF