Fake user on SSH server restricted to using only some commands

It's common for SSH servers in Linux to integrate with the system and not to introduce another layer of users. It's not like Samba nor FTP, where such layer of Samba-specific or FTP-specific users exists. I guess it's a non-trivial task to make sshd from OpenSSH define an independent set of users (but maybe another answer will surprise me).

Maybe your intention to make a fake user stems from the fact you are not root on the SSH server and you cannot create a real user there. If so, this is what you can do anyway¹:

See man 5 authorized_keys where it describes the format. In my Debian the manual states [emphasis mine]:

AuthorizedKeysFile specifies the files containing public keys for public key authentication; if this option is not specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. Each line of the file contains one key (empty lines and lines starting with a ‘#’ are ignored as comments). Public keys consist of the following space-separated fields: options, keytype, base64-encoded key, comment. The options field is optional. […]

The options (if present) consist of comma-separated option specifications. No spaces are permitted, except within double quotes. The following option specifications are supported (note that option keywords are case-insensitive):

[…]

command="command"
Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; otherwise it is run without a tty. If an 8-bit clean channel is required, one must not request a pty or should specify no-pty. A quote may be included in the command by quoting it with a backslash.

This option might be useful to restrict certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP and/or X11 forwarding unless they are explicitly prohibited, e.g. using the restrict key option.

[…]

This way, as a regular user, you can allow somebody else (from now on: a guest) to log in as you and to run one specific command as you automatically. Simply register their public key in your ~/.ssh/authorized_keys on the server, using the command="command" option.

The command may be a custom program or a script that allows the guest to choose a task from a list, or to type a keyword to choose a task; or to type an "inner" command that will be validated and allowed or disallowed; the program will then execute something accordingly. It's up to you what the command/program/script is.

Note from the point of view of the SSH server and its admins the guest is you. It's your account that runs the command and if your custom program or script allows the guest to run an arbitrary command somehow (e.g. by spawning a shell first somehow) then it will be as if you run the command.

An example line in ~/.ssh/authorized_keys that allows the owner of a specific key to see the output of df -h looks like this:

command="df -h",no-pty ssh-rsa AAA…(public key here)…

(For the description of no-pty see man 5 authorized_keys. There are other options you may find useful.) Now whoever uses this specific key to connect to the server (using your login) will see the output of df -h and will get disconnected.

¹ Probably. The SSH server may be configured to deny various things.