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; they are ignored. If BORG_XXX environment
  15. variables need to 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 key pair 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 helps 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-compliant
  28. shell set as the user's login shell.
  29. This automatically blocks potentially 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. was introduced in v7.2. We recommend using
  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. Replace ``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 keepalive 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 following 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.