Changeset - a9e71e61cedf
[Not reviewed]
stable
0 1 0
Mads Kiilerich - 6 years ago 2020-04-29 15:00:59
mads@kiilerich.com
ssh: mention in docs how to use multiple authorized_keys files
1 file changed with 10 insertions and 0 deletions:
0 comments (0 inline, 0 general)
docs/setup.rst
Show inline comments
 
@@ -108,96 +108,106 @@ This means:
 
- users and admins can manage SSH public keys in the web UI
 

	
 
- in their SSH client configuration, users can configure how the client should
 
  control access to their SSH key - without passphrase, with passphrase, and
 
  optionally with passphrase caching in the local shell session (``ssh-agent``).
 
  This is standard SSH functionality, not something Kallithea provides or
 
  interferes with.
 

	
 
- network communication between client and server happens in a bidirectional
 
  stateful stream, and will in some cases be faster than HTTP/HTTPS with several
 
  stateless round-trips.
 

	
 
.. note:: At this moment, repository access via SSH has been tested on Unix
 
    only. Windows users that care about SSH are invited to test it and report
 
    problems, ideally contributing patches that solve these problems.
 

	
 
Users and admins can upload SSH public keys (e.g. ``.ssh/id_rsa.pub``) through
 
the web interface. The server's ``.ssh/authorized_keys`` file is automatically
 
maintained with an entry for each SSH key. Each entry will tell ``sshd`` to run
 
``kallithea-cli`` with the ``ssh-serve`` sub-command and the right Kallithea user ID
 
when encountering the corresponding SSH key.
 

	
 
To enable SSH repository access, Kallithea must be configured with the path to
 
the ``.ssh/authorized_keys`` file for the Kallithea user, and the path to the
 
``kallithea-cli`` command. Put something like this in the ``.ini`` file::
 

	
 
    ssh_enabled = true
 
    ssh_authorized_keys = /home/kallithea/.ssh/authorized_keys
 
    kallithea_cli_path = /srv/kallithea/venv/bin/kallithea-cli
 

	
 
The SSH service must be running, and the Kallithea user account must be active
 
(not necessarily with password access, but public key access must be enabled),
 
all file permissions must be set as sshd wants it, and ``authorized_keys`` must
 
be writeable by the Kallithea user.
 

	
 
.. note:: The ``authorized_keys`` file will be rewritten from scratch on
 
    each update. If it already exists with other data, Kallithea will not
 
    overwrite the existing ``authorized_keys``, and the server process will
 
    instead throw an exception. The system administrator thus cannot ssh
 
    directly to the Kallithea user but must use su/sudo from another account.
 

	
 
    If ``/home/kallithea/.ssh/`` (the directory of the path specified in the
 
    ``ssh_authorized_keys`` setting of the ``.ini`` file) does not exist as a
 
    directory, Kallithea will attempt to create it. If that path exists but is
 
    *not* a directory, or is not readable-writable-executable by the server
 
    process, the server process will raise an exception each time it attempts to
 
    write the ``authorized_keys`` file.
 

	
 
.. note:: It is possible to configure the SSH server to look for authorized
 
   keys in multiple files, for example reserving ``ssh/authorized_keys`` to be
 
   used for normal SSH and with Kallithea using
 
   ``.ssh/authorized_keys_kallithea``. In ``/etc/ssh/sshd_config`` set
 
   ``AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys_kallithea``
 
   and restart sshd, and in ``my.ini`` set ``ssh_authorized_keys =
 
   /home/kallithea/.ssh/authorized_keys_kallithea``. Note that this new
 
   location will apply to all system users, and that multiple entries for the
 
   same SSH key will shadow each other.
 

	
 
.. warning:: The handling of SSH access is steered directly by the command
 
    specified in the ``authorized_keys`` file. There is no interaction with the
 
    web UI.  Once SSH access is correctly configured and enabled, it will work
 
    regardless of whether the Kallithea web process is actually running. Hence,
 
    if you want to perform repository or server maintenance and want to fully
 
    disable all access to the repositories, disable SSH access by setting
 
    ``ssh_enabled = false`` in the correct ``.ini`` file (i.e. the ``.ini`` file
 
    specified in the ``authorized_keys`` file.)
 

	
 
The ``authorized_keys`` file can be updated manually with ``kallithea-cli
 
ssh-update-authorized-keys -c my.ini``. This command is not needed in normal
 
operation but is for example useful after changing SSH-related settings in the
 
``.ini`` file or renaming that file. (The path to the ``.ini`` file is used in
 
the generated ``authorized_keys`` file).
 

	
 

	
 
Setting up Whoosh full text search
 
----------------------------------
 

	
 
Kallithea provides full text search of repositories using `Whoosh`__.
 

	
 
.. __: https://whoosh.readthedocs.io/en/latest/
 

	
 
For an incremental index build, run::
 

	
 
    kallithea-cli index-create -c my.ini
 

	
 
For a full index rebuild, run::
 

	
 
    kallithea-cli index-create -c my.ini --full
 

	
 
The ``--repo-location`` option allows the location of the repositories to be overridden;
 
usually, the location is retrieved from the Kallithea database.
 

	
 
The ``--index-only`` option can be used to limit the indexed repositories to a comma-separated list::
 

	
 
    kallithea-cli index-create -c my.ini --index-only=vcs,kallithea
 

	
 
To keep your index up-to-date it is necessary to do periodic index builds;
 
for this, it is recommended to use a crontab entry. Example::
 

	
 
    0  3  *  *  *  /path/to/virtualenv/bin/kallithea-cli index-create -c /path/to/kallithea/my.ini
 

	
 
When using incremental mode (the default), Whoosh will check the last
 
modification date of each file and add it to be reindexed if a newer file is
 
available. The indexing daemon checks for any removed files and removes them
 
from index.
 

	
0 comments (0 inline, 0 general)