in reply to Re^3: SSH daemon in Perl?
in thread SSH daemon in Perl?

Yes, one user will execute the Perl program. However, is it possible to execute the program immediately upon connection without logging in with a Unix user account?

Going back to the example of the SSH chat server written in Go (https://medium.com/swlh/ssh-how-does-it-even-9e43586e4ffc), a client can enter ssh hostname in their terminal and enter the "chat room" without logging in.

Replies are listed 'Best First'.
Re^5: SSH daemon in Perl?
by soonix (Chancellor) on Jun 23, 2016 at 08:11 UTC
    To reword the question:

    "upon connection" means there is 'something' listening on port 22. This 'something' (e.g. your server) already has to run beforehand (waiting for the actual connection and doing the authentication thing, as you yourself already stated).

    Under which user shall this 'something' run? This could be a single non-privileged user account "mycoolservice" dedicated exclusively to that ssh daemon.

      The original goal was to write an SSH daemon in Perl, but haukex suggested using the OpenSSH server instead.

      Under this model, there will be no Perl SSH daemon. Instead, there will be a simple Perl program that reads input from STDIN and sends output to STDOUT. This program will be executed by OpenSSH upon connection.

      Yes, OpenSSH will execute this program as a single non-privileged user. However, it's important that I do not have to log in as this user upon connection.

      Here's a sample of what the session output should look like:

      $ ssh abc123@localhost Hello, world! Hello, world! $ ssh asdfghjkl@localhost This is a simple echo server as an example. This is a simple echo server as an example.

      Notice that no authentication takes place. It proceeds to execute echo.pl (as the single non-privileged user) regardless of the username that was sent.

        Then you don't need no steenken' login :-) The script can run as your service user and do its thing on behalf of your other users.

        The "login" issue probably surfaced because most "SSH servers" let their users do things that are security relevant.