SSH kitten asks for password when splitting from a keybinding

[crater2150]

I'm trying to get keybindings for splitting a window working in an ssh session.

I have the following key binding in my config:

map kitty_mod+v     launch --copy-env --cwd=current --location=vsplit

Using this binding while in an ssh session opens a vertical split, which only contains a password prompt (hostname, newline, > ). After entering a password the vsplit just closes (no matter if I enter the SSH account password or something else). What is this password used for? The previously opened ssh session uses public key authentication via ssh-agent.

With remote control enabled, running the same command from the command line inside the SSH session instead of via keybinding works, opening a split with another shell on the ssh remote:

kitty @ launch --copy-env --cwd=current --location=vsplit

I'm assuming the kitty process started inside the ssh session is required for getting environment and current cwd, so it works with that but not the keybinding. If I remove --copy-env and --cwd from the command, both variants work the same, but open a split with a local shell.

Is it possible to get the behaviour from the remote command via a keybinding, preferrably a single one that works for both local and ssh?

[kovidgoyal]

Assuming you ran the ssh kitten in window 1 and then ran your mapping, the newly created window should automatically be logged in and at the cwd of 1 regardless. It doesnt matter if you do it via remote control or mapping. If that's not working for you then make sure you are running up-to-date kitty.

[mtalexan]

I'm getting a similar issue, though it presents slightly differently and I'm not sure what's happening.
I also have a key combo for splitting but keeping the current context

map kitty_mod+enter>h  launch --type=window --cwd=current --copy-cmdline --copy-env --location=vsplit

But instead of a password prompt, I'm getting an error, where the only thing I can do is press Enter and it closes the window.

{ Distributed under terms of the GPLv3 license.dgoyal.net>
  unalias command; 
        printf "/stderr ]; thenm -rf "$tdir"ho" 2> /dev/null < /dev/tty
                033[31m%s
                         033[m
                              n
        printf "ev/fd/2 ]; thenr" "$*" > /dev/stderr;
                033[31m%s
                         033[m
                              n
        printf "               r" "$*" > /dev/fd/2;
                033[31m%s
                         033[m
                              n
    base64_encode() { command base64 | command tr -d turn 1; fi 1; fi

                                                     n

    base64_encode() { command b64encode - | command sed  }
                                                        1d;$d
                                                              | command tr -d 

                                                                              n

    pybase64() { command "$python" -c "import sys, base64; getattr(sys.stdout, r; }
                                                                               buffer
                                                                                     , sys.stdout).write(base64.standard_b64$1(getattr(sys.stdin, 
                                        buffer
    base64_encode() { command "$perl" -MMIME::Base64 -0777 -ne ()))"; }
                                                               print encode_base64($_)
    base64_decode() { command "$perl" -MMIME::Base64 -ne                              ; }
                                                         print decode_base64($_)
dcs_to_kitty() { printf "e not present on remote host, ssh kitten cannot function."
                         033P@kitty-$1|%s
                                         033
    command -v tar > /dev/null 2> /dev/null || die "tar is not available on this server. The ssh kitten re'xec_login_shellstspassed to SSH execute it here"thenoot" ""ad SSH data from tty" /dev/nulle in the future
> 

I am running the latest kitty version already (0.31.0).
With a bit of trial and error, it appears using the --copy-env or --copy-cmdline will trigger this error every time on every server. A remote Ubuntu 22.04 server using zsh as the login shell, and a remote OpenSuse MicroOS that's fully up to date and using a bash shell are both getting identical errors when using a launch command that includes either of these options.

[kovidgoyal]

There is no point using either --copy-env or --copy-cmdline with ssh sessions. In both cases the env and cmdline that will be copied refer to the env in which the session was launched not the env inside the session. Use the clone-in-kitty command to clone a shell running on a remote server.

That means at your remote shell, type the following command:

clone-in-kitty --location=vsplit

[mtalexan]

In response to OP's question then: Is there any way to have a keybinding that will simply duplicate the current window regardless of whether the current session is local or remote?

Or to be less picky, a single keybinding that will just give me a new window at the same location (regardless of whether or not I'm currently SSH'd in with the kitten or just local)?

[kovidgoyal]

On Fri, Jan 05, 2024 at 10:30:18PM -0800, Mike wrote: In response to OP's question then: Is there any way to have a keybinding that will simply duplicate the current window regardless of whether the current session is local or remote? Or to be less picky, a single keybinding that will just give me a new window at the same location (regardless of whether or not I'm currently SSH'd in with the kitten or just local)?

map f1 launch --cwd=current

[kovidgoyal]

Again,

map f1 launch --cwd=current

[kovidgoyal]

And send_text will work for both local and remote shell sessions but not arbitrary windows.

[mtalexan]

Again,

map f1 launch --cwd=current

Oh, my mistake. I thought we determined previously that didn't work on remote sessions, but I just verified I was mixed up and it does work on remote systems. It does print a warning about a local folder issue on window load, and (caveat) it can't duplicate the CWD of the SSH session since that's part of the post-startup env.
Sorry, I thought you were citing a local-only keybinding based what I thought my testing showed, but I was mistaken. This covers it.

[mtalexan]

And send_text will work for both local and remote shell sessions but not arbitrary windows.

Is there a command that could be run with send_text that would work on both a local and remote system? clone-in-kitty doesn't seem to be available on a remote system.

[kovidgoyal]

it is available ona remote system, provided you are connecting with the ssh kitten and you havent disabled shele integration. clone-in-kitty is provided by shell integration and sheel integration is enabled by the ssh kitten on remote computers automatically.

[kovidgoyal]

cwd is special cased, it will work even for remote sessions because shell integration reports it. Again, you need to have functioning shell integration on the remote system, which is automatically setup by the ssh kitten. So all you need to do is

kitten ssh server