Ubuntu Manpage: kitten-ssh - kitten Documentation

Provided by: kitty_0.32.2-1ubuntu0.4_amd64

Name

       kitten-ssh - kitten Documentation

Overview

       • Automatic Shell integration on remote hosts

       • Easily clone local shell/editor config on remote hosts

       • Automatic re-use of existing connections to avoid connection setup latency

       • Make the kitten binary available in the remote host on demand

       • Easily change terminal colors when connecting to remote hosts

       • Automatically forward the kitty remote control socket to configured hosts

       New in version 0.25.0: Automatic shell integration, file transfer and reuse of connections

       New in version 0.30.0: Automatic forwarding of remote control sockets

       The  ssh kitten allows you to login easily to remote hosts, and automatically setup the environment there
       to be as comfortable as your local shell. You can specify environment variables to set on the remote host
       and files to copy there, making your remote experience just  like  your  local  shell.  Additionally,  it
       automatically sets up Shell integration on the remote host and copies the kitty terminfo database there.

       The  ssh  kitten  is  a thin wrapper around the traditional ssh command line program and supports all the
       same options and arguments and configuration.  In interactive usage scenarios it is a drop in replacement
       for ssh.  To try it out, simply run:

          kitten ssh some-hostname-to-connect-to

       You should end up at a shell prompt on the remote host, with shell integration enabled. If  you  like  it
       you can add an alias to it in your shell's rc files:

          alias s="kitten ssh"

       So now you can just type s hostname to connect.

       If you define a mapping in kitty.conf such as:

          map f1 new_window_with_cwd

       Then, pressing F1 will open a new window automatically logged into the same host using the ssh kitten, at
       the same directory.

       The  ssh  kitten  can  be  configured  using  the  ~/.config/kitty/ssh.conf  file  where  you can specify
       environment variables to set on the remote host and files to copy from the  local  to  the  remote  host.
       Let's see a quick example:

          # Copy the files and directories needed to setup some common tools
          copy .zshrc .vimrc .vim
          # Setup some environment variables
          env SOME_VAR=x
          # COPIED_VAR will have the same value on the remote host as it does locally
          env COPIED_VAR=_kitty_copy_env_var_

          # Create some per hostname settings
          hostname someserver-*
          copy env-files
          env SOMETHING=else

          hostname someuser@somehost
          copy --dest=foo/bar some-file
          copy --glob some/files.*

       See  below  for  full  details  on the syntax and options of ssh.conf.  Additionally, you can pass config
       options on the command line:

          kitten ssh --kitten interpreter=python servername

       The --kitten argument can be specified multiple times, with directives from ssh.conf. These override  the
       final  options used for the matched host, as if they had been appended to the end of the matching section
       for that host in ssh.conf. They apply only to the host being SSHed to by this invocation, so any hostname
       directives are ignored.

       WARNING:
          Due to limitations in the design of SSH, any typing you do before the  shell  prompt  appears  may  be
          lost. So ideally don't start typing till you see the shell prompt. 😇

A real world example

       Suppose  you  often SSH into a production server, and you would like to setup your shell and editor there
       using your custom settings. However, other people could SSH in as well and  you  don't  want  to  clobber
       their settings. Here is how this could be achieved using the ssh kitten with zsh and vim as the shell and
       editor, respectively:

          # Have these settings apply to servers in my organization
          hostname myserver-*

          # Setup zsh to read its files from my-conf/zsh
          env ZDOTDIR $HOME/my-conf/zsh
          copy --dest my-conf/zsh/.zshrc .zshrc
          copy --dest my-conf/zsh/.zshenv .zshenv
          # If you use other zsh init files add them in a similar manner

          # Setup vim to read its config from my-conf/vim
          env VIMINIT $HOME/my-conf/vim/vimrc
          env VIMRUNTIME $HOME/my-conf/vim
          copy --dest my-conf/vim .vim
          copy --dest my-conf/vim/vimrc .vimrc

How it works

The ssh kitten works by having SSH transmit and execute a POSIX sh (or optionally Python) bootstrap
script on the remote host using an interpreter. This script reads setup data over the TTY device, which
kitty sends as a Base64 encoded compressed tarball. The script extracts it and places the files and sets
the environment variables before finally launching the login shell with shell integration enabled. The
data is requested by the kitten over the TTY with a random one time password. kitty reads the request and
if the password matches a password pre-stored in shared memory on the localhost by the kitten, the
transmission is allowed. If your local OpenSSH version is >= 8.4 then the data is transmitted instantly
without any roundtrip delay.

NOTE:
When connecting to BSD hosts, it is possible the bootstrap script will fail or run slowly, because the
default shells are crippled in various ways. Your best bet is to install Python on the remote, make
sure the login shell is something POSIX sh compliant, and use python as the interpreter in ssh.conf.

NOTE:
This may or may not work when using terminal multiplexers, depending on whether they passthrough the
escape codes and if the values of the environment variables KITTY_PID and KITTY_WINDOW_ID are correct
in the current session (they can be wrong when connecting to a tmux session running in a different
window) and the ssh kitten is run in the currently active multiplexer window.

Host bootstrap configuration

hostname

hostname *

The hostname that the following options apply to. A glob pattern to match multiple hosts can be used.
Multiple hostnames can also be specified, separated by spaces. The hostname can include an optional
username in the form user@host. When not specified options apply to all hosts, until the first hostname
specification is found. Note that matching of hostname is done against the name you specify on the
command line to connect to the remote host. If you wish to include the same basic configuration for many
different hosts, you can do so with the include directive. In version 0.28.0 the behavior of this option
was changed slightly, now, when a hostname is encountered all its config values are set to defaults
instead of being inherited from a previous matching hostname block. In particular it means hostnames dont
inherit configurations, thereby avoiding hard to understand action-at-a-distance.

interpreter

interpreter sh

The interpreter to use on the remote host. Must be either a POSIX complaint shell or a python executable.
If the default sh is not available or broken, using an alternate interpreter can be useful.

remote_dir

remote_dir .local/share/kitty-ssh-kitten

The location on the remote host where the files needed for this kitten are installed. Relative paths are
resolved with respect to $HOME.

copy

Copy files and directories from local to remote hosts. The specified files are assumed to be relative to
the HOME directory and copied to the HOME on the remote. Directories are copied recursively. If absolute
paths are used, they are copied as is. For example:

copy .vimrc .zshrc .config/some-dir

Use --dest to copy a file to some other destination on the remote host:

copy --dest some-other-name some-file

Glob patterns can be specified to copy multiple files, with --glob:

copy --glob images/*.png

Files can be excluded when copying with --exclude:

copy --glob --exclude *.jpg --exclude *.bmp images/*

Files whose remote name matches the exclude pattern will not be copied. For more details, see The copy
command.

Login shell environment

shell_integration

shell_integration inherited

Control the shell integration on the remote host. See Shell integration for details on how this setting
works. The special value inherited means use the setting from kitty.conf. This setting is useful for
overriding integration on a per-host basis.

login_shell

The login shell to execute on the remote host. By default, the remote user account's login shell is used.

env

Specify the environment variables to be set on the remote host. Using the name with an equal sign (e.g.
env VAR=) will set it to the empty string. Specifying only the name (e.g. env VAR) will remove the
variable from the remote shell environment. The special value _kitty_copy_env_var_ will cause the value
of the variable to be copied from the local environment. The definitions are processed alphabetically.
Note that environment variables are expanded recursively, for example:

env VAR1=a
env VAR2=${HOME}/${VAR1}/b

The value of VAR2 will be <path to home directory>/a/b.

cwd

The working directory on the remote host to change to. Environment variables in this value are expanded.
The default is empty so no changing is done, which usually means the HOME directory is used.

color_scheme

Specify a color scheme to use when connecting to the remote host. If this option ends with .conf, it is
assumed to be the name of a config file to load from the kitty config directory, otherwise it is assumed
to be the name of a color theme to load via the themes kitten. Note that only colors applying to the
text/background are changed, other config settings in the .conf files/themes are ignored.

remote_kitty

remote_kitty if-needed

Make kitten available on the remote host. Useful to run kittens such as the icat kitten to display images
or the transfer file kitten to transfer files. Only works if the remote host has an architecture for
which pre-compiled kitten binaries are available. Note that kitten is not actually copied to the remote
host, instead a small bootstrap script is copied which will download and run kitten when kitten is first
executed on the remote host. A value of if-needed means kitten is installed only if not already present
in the system-wide PATH. A value of yes means that kitten is installed even if already present, and the
installed kitten takes precedence. Finally, no means no kitten is installed on the remote host. The
installed kitten can be updated by running: kitten update-self on the remote host.

Ssh configuration

share_connections

share_connections yes

Within a single kitty instance, all connections to a particular server can be shared. This reduces
startup latency for subsequent connections and means that you have to enter the password only once. Under
the hood, it uses SSH ControlMasters and these are automatically cleaned up by kitty when it quits. You
can map a shortcut to close_shared_ssh_connections to disconnect all active shared connections.

askpass

askpass unless-set

Control the program SSH uses to ask for passwords or confirmation of host keys etc. The default is to use
kitty's native askpass, unless the SSH_ASKPASS environment variable is set. Set this option to ssh to not
interfere with the normal ssh askpass mechanism at all, which typically means that ssh will prompt at the
terminal. Set it to native to always use kitty's native, built-in askpass implementation. Note that not
using the kitty askpass implementation means that SSH might need to use the terminal before the
connection is established, so the kitten cannot use the terminal to send data without an extra roundtrip,
adding to initial connection latency.

delegate

Do not use the SSH kitten for this host. Instead run the command specified as the delegate. For example
using delegate ssh will run the ssh command with all arguments passed to the kitten, except kitten
specific ones. This is useful if some hosts are not capable of supporting the ssh kitten.

forward_remote_control

forward_remote_control no

Forward the kitty remote control socket to the remote host. This allows using the kitty remote control
facilities from the remote host. WARNING: This allows any software on the remote host full access to the
local computer, so only do it for trusted remote hosts. Note that this does not work with abstract UNIX
sockets such as @mykitty because of SSH limitations. This option uses SSH socket forwarding to forward
the socket pointed to by the KITTY_LISTEN_ON environment variable.

The copy command

copy [options] file-or-dir-to-copy ...

Options
--glob Interpret file arguments as glob patterns. Globbing is based on standard wildcards with the
addition that /**/ matches any number of directories. See the detailed syntax.

--dest <DEST>
The destination on the remote host to copy to. Relative paths are resolved relative to HOME on the
remote host. When this option is not specified, the local file path is used as the remote
destination (with the HOME directory getting automatically replaced by the remote HOME). Note that
environment variables and ~ are not expanded.

--exclude <EXCLUDE>
A glob pattern. Files with names matching this pattern are excluded from being transferred. Only
used when copying directories. Can be specified multiple times, if any of the patterns match the
file will be excluded. If the pattern includes a / then it will match against the full path, not
just the filename. In such patterns you can use /**/ to match zero or more directories. For
example, to exclude a directory and everything under it use **/directory_name. See the detailed
syntax for how wildcards match.

--symlink-strategy <SYMLINK_STRATEGY>
Control what happens if the specified path is a symlink. The default is to preserve the symlink,
re-creating it on the remote machine. Setting this to resolve will cause the symlink to be
followed and its target used as the file/directory to copy. The value of keep-path is the same as
resolve except that the remote file path is derived from the symlink's path instead of the path of
the symlink's target. Note that this option does not apply to symlinks encountered while
recursively copying directories, those are always preserved. Default: preserve Choices:
keep-path, preserve, resolve

Copying terminfo files manually

       Sometimes,  the  ssh kitten can fail, or maybe you dont like to use it. In such cases, the terminfo files
       can be copied over manually to a server with the following one liner:

          infocmp -a xterm-kitty | ssh myserver tic -x -o \~/.terminfo /dev/stdin

       If you are behind a proxy (like Balabit) that prevents this, or you are SSHing into macOS where  the  tic
       does  not  support  reading  from  STDIN, you must redirect the first command to a file, copy that to the
       server and run tic manually. If you connect to a server, embedded, or Android system  that  doesn't  have
       tic, copy over your local file terminfo to the other system as ~/.terminfo/x/xterm-kitty.

       If the server is running a relatively modern Linux distribution and you have root access to it, you could
       simply install the kitty-terminfo package on the server to make the terminfo files available.

       Really,  the  correct  solution  for  this  is  to  convince  the OpenSSH maintainers to have ssh do this
       automatically, if possible, when connecting to a server, so that all terminals work transparently.

       If the server is running FreeBSD, or another system that relies on termcap rather than terminfo, you will
       need to convert the terminfo file on your local machine by running (on local machine with kitty):

          infocmp -CrT0 xterm-kitty

       The  output  of  this   command   is   the   termcap   description,   which   should   be   appended   to
       /usr/share/misc/termcap on the remote server. Then run the following command to apply your change (on the
       server):

          cap_mkdb /usr/share/misc/termcap

Author

       Kovid Goyal

Copyright

       2025, Kovid Goyal

0.32.2                                            Jun 25, 2025                                     kitten-ssh(1)