serve.rst 4.3 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677
  1. .. include:: serve.rst.inc
  2. Examples
  3. ~~~~~~~~
  4. ``borg serve`` has special support for ssh forced commands (see ``authorized_keys``
  5. example below): if the environment variable SSH_ORIGINAL_COMMAND is set it will
  6. ignore some options given on the command line and use the values from the
  7. variable instead. This only applies to a carefully controlled allowlist of safe
  8. options. This list currently contains:
  9. - Options that control the log level and debug topics printed
  10. such as ``--verbose``, ``--info``, ``--debug``, ``--debug-topic``, etc.
  11. - ``--lock-wait`` to allow the client to control how long to wait before
  12. giving up and aborting the operation when another process is holding a lock.
  13. Environment variables (such as BORG_XXX) contained in the original
  14. command sent by the client are *not* interpreted, but ignored. If BORG_XXX environment
  15. variables should be set on the ``borg serve`` side, then these must be set in system-specific
  16. locations like ``/etc/environment`` or in the forced command itself (example below).
  17. ::
  18. # Allow an SSH keypair to only run borg, and only have access to /path/to/repo.
  19. # Use key options to disable unneeded and potentially dangerous SSH functionality.
  20. # This will help to secure an automated remote backup system.
  21. $ cat ~/.ssh/authorized_keys
  22. command="borg serve --restrict-to-path /path/to/repo",restrict ssh-rsa AAAAB3[...]
  23. # Set a BORG_XXX environment variable on the "borg serve" side
  24. $ cat ~/.ssh/authorized_keys
  25. command="BORG_XXX=value borg serve [...]",restrict ssh-rsa [...]
  26. .. note::
  27. The examples above use the ``restrict`` directive and assume a POSIX
  28. compliant shell set as the user's login shell.
  29. This does automatically block potential dangerous ssh features, even when
  30. they are added in a future update. Thus, this option should be preferred.
  31. If you're using openssh-server < 7.2, however, you have to explicitly specify
  32. the ssh features to restrict and cannot simply use the restrict option as it
  33. has been introduced in v7.2. We recommend to use
  34. ``no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding,no-user-rc``
  35. in this case.
  36. Details about sshd usage: `sshd(8) <https://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sshd.8>`_
  37. .. _ssh_configuration:
  38. SSH Configuration
  39. ~~~~~~~~~~~~~~~~~
  40. ``borg serve``'s pipes (``stdin``/``stdout``/``stderr``) are connected to the ``sshd`` process on the server side. In the event that the SSH connection between ``borg serve`` and the client is disconnected or stuck abnormally (for example, due to a network outage), it can take a long time for ``sshd`` to notice the client is disconnected. In the meantime, ``sshd`` continues running, and as a result so does the ``borg serve`` process holding the lock on the repository. This can cause subsequent ``borg`` operations on the remote repository to fail with the error: ``Failed to create/acquire the lock``.
  41. In order to avoid this, it is recommended to perform the following additional SSH configuration:
  42. Either in the client side's ``~/.ssh/config`` file, or in the client's ``/etc/ssh/ssh_config`` file:
  43. ::
  44. Host backupserver
  45. ServerAliveInterval 10
  46. ServerAliveCountMax 30
  47. Replacing ``backupserver`` with the hostname, FQDN or IP address of the borg server.
  48. This will cause the client to send a keepalive to the server every 10 seconds. If 30 consecutive keepalives are sent without a response (a time of 300 seconds), the ssh client process will be terminated, causing the borg process to terminate gracefully.
  49. On the server side's ``sshd`` configuration file (typically ``/etc/ssh/sshd_config``):
  50. ::
  51. ClientAliveInterval 10
  52. ClientAliveCountMax 30
  53. This will cause the server to send a keep alive to the client every 10 seconds. If 30 consecutive keepalives are sent without a response (a time of 300 seconds), the server's sshd process will be terminated, causing the ``borg serve`` process to terminate gracefully and release the lock on the repository.
  54. If you then run borg commands with ``--lock-wait 600``, this gives sufficient time for the borg serve processes to terminate after the SSH connection is torn down after the 300 second wait for the keepalives to fail.
  55. You may, of course, modify the timeout values demonstrated above to values that suit your environment and use case.