How to keep a ssh session alive?

[sla-te]

I take it, implementing the suggestions from 2015 via #223, were still not considered?
Now due to me using this quite often, like for instance here: #701 (comment)
Now I wonder if it is a good idea to use sh as backend, because the actual chaining is not really passing through any checks anymore and are being executed "raw", what are your thoughts?

[ecederstrand]

It's not clear from the linked issues exactly what your problem is, or what you are trying to achieve?

The syntax suggested in #223 is not supported by sh.

[sla-te]

Well, when I do touch my_file && while [ -f myfile ]; do echo "myfile still exists"; sleep 1; done && sleep 1 I am, to my terms, chaining together touch my_file with while [ -f myfile ...]. - But I do see your point, the topic is not really a perfect fit for the actual question, as of course &&does nothing else but asserting the previous command was run successfully, which could also be achieved by running both commands separately and checking the exit codes.

The only reason I "have to" do this is, that I could not think of a different way to keep the session alive but chaining a while loop after a command, that I can pass to sh for execution, so it will keep the session alive until I delete myfile via separate command (using the slave).

So I am actually not really sure which topic would fit the question better, maybe "How to keep an empty ssh session alive"? :D

[amoffat]

This doesn't work?

master = sh.ssh("-o", "ControlMaster=yes", "-o", "ControlPath=~/.ssh/control-10.0.0.1_root", "-i", "priv_key", "[email protected]", _bg=True)
# ... do slave stuff ...
master.kill()

[sla-te]

Nope

master = sh.ssh(
    "-o",
    "ControlMaster=yes",
    "-o",
    f"ControlPath=~/.ssh/control-10.0.0.1_root_ses_debugging",
    "-i",
    "priv_key",
    "[email protected]",
    "-p",
    "22",
    _bg=True,
)

while True:
    print(master.is_alive())
    time.sleep(1) 

>>> True
>>> False
>>> False
>>> False
>>> False
...

This behaviour seems logical to to me though as the command does not provide any work to be done, so sh would connect to the server and disconnect right after.

[amoffat]

Take a look at the "-N" option on ssh. It is for ssh sessions to stay alive when they don't execute a remote command.

[sla-te]

Genius. :) didn't figure that option could exist in ssh!

[amoffat]

Glad you got it working.

For future discussions, please try to make an extra effort to ensure that the issue is sh-related, and not related to your specific work that you're doing. Consider this discussion title "How to keep a ssh session alive" and its answer have nothing to do with sh. By the discussions you've made so far, it seems you are building some automated ssh-based system for your job or a personal project. That's great, but we can't help with that.

Sh is pretty much feature complete (likely nothing new will be added) and pretty mature (very few bugs). If you find yourself struggling with using it, it's probably related to the nuances of the programs you are launching, and not how sh itself is working. We'd like to keep discussions here related to issues with sh itself.

If you're struggling with other problems, ChatGPT is your friend, and sh has been around long enough that it has knowledge around its usage. As mentioned in a previous discussion, stackoverflow can be helpful for general questions too.

[sla-te]

I completely agree with you, that questions should be sh-related but at the same time I believe, that the use case to run multiple commands on a remote server is one is a very common one. Using this question in combination with the context manager I provided in my other question it will could motivate other developers to use sh over other libraries.

I really did my best to consume all the docs and references provided but it would sure have been nice to have some more examples on how to actually implement in a real world scenario. I had found the neat way to use ssh via using bake but if you open one isolated session for each command it does not really get close to the real world implementation, where it is very likely, that you dont just do ip a but rather want to run a little shell script wrapped in python. - For instance you want to cd to a certain folder set a variable in the shell, such as SOME_LIB_PATH=\some\location\on\the\remote server and use that in the command you are calling, e.g. something like this: VOLTA_HOME=$HOME/.volta && PATH=$VOLTA_HOME/bin:$PATH && cd /var/www/frontend && npm run pm2:production. This was by the way one motivation for me even going down the path to try and persist the ssh session for follow up commands, which I now realized by using the above in combination with tmux (which got pretty complex) - If I would have had examples about different strategies to achieve the desired result, eventually, this complexity would not even be required.

This library is the most clean one of everything I found but it lacks real world examples, which makes it really hard to use. If we had that it would be perfect (btw the internal subprocess handling is quite impressive).