During an automated compile and deployment process you problaby want to copy the new file(s) to the destination server. Since the process will be running within the deployment environment (gitlab-ci in my case) you cannot supply a password every time. So you use SSH keys to authenticate against the server. I found this to be common practice and it is well documented.

Only much later I found that you can limit the command one key is allowed to run on the server. So you might have a script on the server which pulls a built package from the repo after your build pipeline put it there. You simply add a “command=” flag before the key in authorized_keys:

command="/usr/bin/pull-softare-update" ssh-rsa AAAAB123...

This way, you can run ssh user@server.example.com /usr/bin/pull-softare-update but nothing else. Supplying another command via ssh will still result in “pull-software-update” beeing run on the server.

There are cases, though, where you don’t explicitly run a command on the server but still use ssh. Those are rsync and scp. Both start a process on the other side to manage sending/receiving files so you can use the command= feature here, too.

For receiving files, there is an answer on Serverfault which gives a hint on how this might work.

scp starts a process with the hidden command line parameters -f to provide a file or directory for download and -t to specify a directory to put files into (-f: from / -t: to).

command="scp -t /srv/storage/foo" ssh-rsa AAAAB123...

To further limit the key, you can explicitly disallow other ssh features like port forwarding:

command="scp -t /srv/storage/foo",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAB123...