We have moved to a new Sailfish OS Forum. Please start new discussions there.

Revision history [back]

click to hide/show revision 1
initial version

posted 2017-11-29 01:58:41 +0200

too gravatar image

keeping ssh connections alive

Due to various (internal and external) reason when idling over ssh connections those tend to halt or shut down.

If you're connecting to openssh server, and have enough privileges to configure the ssh server, simplest thing to do is to edit /etc/ssh/sshd_config on the server and add the following:

ClientAliveInterval nnn

(after configuring and restarting sshd, check that you can still connect to server before dropping current connection to ensure you aren't locking you out due to server misconfiguration (due to a typo...))

(if you cannot (or want to ) do configure sshd, see an alternative below)

nnn is a value small enough that the NAT mapping between your host and server doesn't timeout, but high enough to keep the "pings" at minimum (I've seen timeouts happening at 300s (just now), less than 240s (connection dropped today at work using that value), and 120s (faint memory from my past)).

The best way to get suitable value for nnn is to test it. In order to do so, ssh to the host you're using and run the following (works on bash 4.x and zsh 5.x):

$ for t in {55..5555..10}; do printf ' %d ' $t; date; sleep $t; done

and when you see no the information stops flowing, the first (number) column in like 10s before the last is suitable value for nnn.

When ClientAliveInterval is set on server, server will ping the client in those intervals. This seems to wake ssh client (running on e.g. fingerterm(*)). *ssh client has option -oServerAliveInterval=nnn -- just that when ssh is in "deep sleep"(*) set by SailfishOS it cannot send those alive messages...

If you cannot (or want to) configure sshd, one alternative is to create ssh master control socket in a screen session, run interval ping there, detach it and run another ssh (using the same control socket) for idling purposes:

On nemo terminal, execute:

$ cd ~
$ screen ssh -M -S .ssh/ms-host user@remotehost ping -D -i nnn 127.0.0.1

(-D is useful for timestamping, but some older pings don't have it -- if yours doesn't, drop it)

After connection is made (e.g. passwd given), detach from screen by pressing Ctrl-a d

Now, on the same terminal, you can execute

$ ssh -S .ssh/ms-host 0.1

to get terminal on the remotehost.

The latter uses the ~/.ssh/ms-host control socket to "connect". Idling here should be no problem. Pinging 127.0.0.1 (in background, use screen -r to reattach) has the effect of printing some output every nnn seconds, causing 2-way traffic between client and server, keeping connection alive that way.


(*) That "deep sleep" is interesting phenomenon happening on the device. It probably also affects WhatsApp; all this is byproduct of trying to get whatsapp web working w/o interruptions. My best guess is that WhatsApp client should be active (towards servers) but this "deep sleep" affects it too (and keeping network alive doesn't help keeping other processes awake).

While trying to do that, I found the following commands most useful:

$ ping -D -i 10 9.9.9.9 ;: -D works on SailfishX terminal
$ date +%s ;: usually on separate {linux} box
$ HISTTIMEFORMAT='%d/%H:%M:%S: ' history 
$ perl -le 'print scalar localtime 1511551151' ;: definitely outside {default} SailfishOS environment

With that pingrunning I left XperiaX untouched many times over various time intervals, occasionally checking screen from time to time, pressing enter (for marker lines), counting lines, comparing timestamps and so on...

(*) Tried to escape "deep sleep" by doing $ setsid nohup ping -D -i 10 9.9.9.9 -- *nohup.out stops getting output when screen goes blank (or soon after) anyway...

keeping ssh connections alive

Due to various (internal and external) reason when idling over ssh connections those tend to halt or shut down.

If you're connecting to openssh server, and have enough privileges to configure the ssh server, simplest thing to do is to edit /etc/ssh/sshd_config on the server and add the following:

ClientAliveInterval nnn

(after configuring and restarting sshd, check that you can still connect to server before dropping current connection to ensure you aren't locking you out due to server misconfiguration (due to a typo...))

(if you cannot (or want to ) do configure sshd, see an alternative below)

nnn is a value small enough that the NAT mapping between your host and server doesn't timeout, but high enough to keep the "pings" at minimum (I've seen timeouts happening at 300s (just now), less than 240s (connection dropped today at work using that value), and 120s (faint memory from my past)).

The best way to get suitable value for nnn is to test it. In order to do so, ssh to the host you're using and run the following (works on bash 4.x and zsh 5.x):

$ for t in {55..5555..10}; do printf ' %d ' $t; date; sleep $t; done

and when you see no the information stops flowing, the first (number) column in like 10s before the last is suitable value for nnn.

When ClientAliveInterval is set on server, server will ping the client in those intervals. This seems to wake ssh client (running on e.g. fingerterm(*)). *ssh client has option -oServerAliveInterval=nnn -- just that when ssh is in "deep sleep"(*) set by SailfishOS it cannot send those alive messages...

If you cannot (or want to) configure sshd, one alternative is to create ssh master control socket in a screen session, run interval ping there, detach it and run another ssh (using the same control socket) for idling purposes:

On nemo terminal, execute:

$ cd ~
$ screen ssh -M -S .ssh/ms-host user@remotehost ping -D -i nnn 127.0.0.1

(-D is useful for timestamping, but some older pings don't have it -- if yours doesn't, drop it)

After connection is made (e.g. passwd given), detach from screen by pressing Ctrl-a d

Now, on the same terminal, you can execute

$ ssh -S .ssh/ms-host 0.1

to get terminal on the remotehost.

The latter uses the ~/.ssh/ms-host control socket to "connect". Idling here should be no problem. Pinging 127.0.0.1 (in background, use screen -r to reattach) has the effect of printing some output every nnn seconds, causing 2-way traffic between client and server, keeping connection alive that way.

By the way: I did not see battery draining any faster while having ssh connection live overnight...


(*) That "deep sleep" is interesting phenomenon happening on the device. It probably also affects WhatsApp; all this is byproduct of trying to get whatsapp web working w/o interruptions. My best guess is that WhatsApp client should be active (towards servers) but this "deep sleep" affects it too (and keeping network alive doesn't help keeping other processes awake).

While trying to do that, I found the following commands most useful:

$ ping -D -i 10 9.9.9.9 ;: -D works on SailfishX terminal
$ date +%s ;: usually on separate {linux} box
$ HISTTIMEFORMAT='%d/%H:%M:%S: ' history 
$ perl -le 'print scalar localtime 1511551151' ;: definitely outside {default} SailfishOS environment

With that pingrunning I left XperiaX untouched many times over various time intervals, occasionally checking screen from time to time, pressing enter (for marker lines), counting lines, comparing timestamps and so on...

(*) Tried to escape "deep sleep" by doing $ setsid nohup ping -D -i 10 9.9.9.9 -- *nohup.out stops getting output when screen goes blank (or soon after) anyway...

keeping ssh connections alive

Due to various (internal and external) reason when idling over ssh connections those tend to halt or shut down.

EDIT: Probably the most simplest way is to try:

$ keepalive-tool ssh -oServerAliveInterval=nnn user@remotehost

If keepalive-tool is not installed, do:

$ devel-su
# pkcon install libkeepalive-glib-tools
# exit
$ keepalive-tool -- ssh -oServerAliveInterval=nnn user@remotehost

For determining how to resolve the value of nnn crawl further in this text for now (Now just a quick update, I'll refactor this later).


If you're connecting to openssh server, and have enough privileges to configure the ssh server, simplest thing to do is to edit /etc/ssh/sshd_config on the server and add the following:

ClientAliveInterval nnn

(after configuring and restarting sshd, check that you can still connect to server before dropping current connection to ensure you aren't locking you out due to server misconfiguration (due to a typo...))

(if you cannot (or want to ) do configure sshd, see an alternative below)

nnn is a value small enough that the NAT mapping between your host and server doesn't timeout, but high enough to keep the "pings" at minimum (I've seen timeouts happening at 300s (just now), less than 240s (connection dropped today at work using that value), and 120s (faint memory from my past)).

The best way to get suitable value for nnn is to test it. In order to do so, ssh to the host you're using and run the following (works on bash 4.x and zsh 5.x):

$ for t in {55..5555..10}; do printf ' %d ' $t; date; sleep $t; done

and when you see no the information stops flowing, the first (number) column in like 10s before the last is suitable value for nnn.

When ClientAliveInterval is set on server, server will ping the client in those intervals. This seems to wake ssh client (running on e.g. fingerterm(*)). *ssh client has option -oServerAliveInterval=nnn -- just that when ssh is in "deep sleep"(*) set by SailfishOS it cannot send those alive messages...

If you cannot (or want to) configure sshd, one alternative is to create ssh master control socket in a screen session, run interval ping there, detach it and run another ssh (using the same control socket) for idling purposes:

On nemo terminal, execute:

$ cd ~
$ screen ssh -M -S .ssh/ms-host user@remotehost ping -D -i nnn 127.0.0.1

(-D is useful for timestamping, but some older pings don't have it -- if yours doesn't, drop it)

After connection is made (e.g. passwd given), detach from screen by pressing Ctrl-a d

Now, on the same terminal, you can execute

$ ssh -S .ssh/ms-host 0.1

to get terminal on the remotehost.

The latter uses the ~/.ssh/ms-host control socket to "connect". Idling here should be no problem. Pinging 127.0.0.1 (in background, use screen -r to reattach) has the effect of printing some output every nnn seconds, causing 2-way traffic between client and server, keeping connection alive that way.

By the way: I did not see battery draining any faster while having ssh connection live overnight...


(*) That "deep sleep" is interesting phenomenon happening on the device. It probably also affects WhatsApp; all this is byproduct of trying to get whatsapp web working w/o interruptions. My best guess is that WhatsApp client should be active (towards servers) but this "deep sleep" affects it too (and keeping network alive doesn't help keeping other processes awake).

While trying to do that, I found the following commands most useful:

$ ping -D -i 10 9.9.9.9 ;: -D works on SailfishX terminal
$ date +%s ;: usually on separate {linux} box
$ HISTTIMEFORMAT='%d/%H:%M:%S: ' history 
$ perl -le 'print scalar localtime 1511551151' ;: definitely outside {default} SailfishOS environment

With that pingrunning I left XperiaX untouched many times over various time intervals, occasionally checking screen from time to time, pressing enter (for marker lines), counting lines, comparing timestamps and so on...

(*) Tried to escape "deep sleep" by doing $ setsid nohup ping -D -i 10 9.9.9.9 -- *nohup.out stops getting output when screen goes blank (or soon after) anyway...

keeping ssh connections alive

Due to various (internal and external) reason when idling over ssh connections those tend to halt or shut down.

EDIT: Probably the most simplest way is to try:

$ keepalive-tool ssh -oServerAliveInterval=nnn user@remotehost

If keepalive-tool is not installed, do:

$ devel-su
# pkcon install libkeepalive-glib-tools
# exit
$ keepalive-tool -- ssh -oServerAliveInterval=nnn user@remotehost

(based on overnight idle I did not see any (noticeable) difference in battery consumption)

For determining how to resolve the value of nnn crawl further in this text for now (Now just a quick update, I'll refactor this later).


If you're connecting to openssh server, and have enough privileges to configure the ssh server, simplest thing to do is to edit /etc/ssh/sshd_config on the server and add the following:

ClientAliveInterval nnn

(after configuring and restarting sshd, check that you can still connect to server before dropping current connection to ensure you aren't locking you out due to server misconfiguration (due to a typo...))

(if you cannot (or want to ) do configure sshd, see an alternative below)

nnn is a value small enough that the NAT mapping between your host and server doesn't timeout, but high enough to keep the "pings" at minimum (I've seen timeouts happening at 300s (just now), less than 240s (connection dropped today at work using that value), and 120s (faint memory from my past)).

The best way to get suitable value for nnn is to test it. In order to do so, ssh to the host you're using and run the following (works on bash 4.x and zsh 5.x):

$ for t in {55..5555..10}; do printf ' %d ' $t; date; sleep $t; done

and when you see no the information stops flowing, the first (number) column in like 10s before the last is suitable value for nnn.

When ClientAliveInterval is set on server, server will ping the client in those intervals. This seems to wake ssh client (running on e.g. fingerterm(*)). *ssh client has option -oServerAliveInterval=nnn -- just that when ssh is in "deep sleep"(*) set by SailfishOS it cannot send those alive messages...

If you cannot (or want to) configure sshd, one alternative is to create ssh master control socket in a screen session, run interval ping there, detach it and run another ssh (using the same control socket) for idling purposes:

On nemo terminal, execute:

$ cd ~
$ screen ssh -M -S .ssh/ms-host user@remotehost ping -D -i nnn 127.0.0.1

(-D is useful for timestamping, but some older pings don't have it -- if yours doesn't, drop it)

After connection is made (e.g. passwd given), detach from screen by pressing Ctrl-a d

Now, on the same terminal, you can execute

$ ssh -S .ssh/ms-host 0.1

to get terminal on the remotehost.

The latter uses the ~/.ssh/ms-host control socket to "connect". Idling here should be no problem. Pinging 127.0.0.1 (in background, use screen -r to reattach) has the effect of printing some output every nnn seconds, causing 2-way traffic between client and server, keeping connection alive that way.

By the way: I did not see battery draining any faster while having ssh connection live overnight...


(*) That "deep sleep" is interesting phenomenon happening on the device. It probably also affects WhatsApp; all this is byproduct of trying to get whatsapp web working w/o interruptions. My best guess is that WhatsApp client should be active (towards servers) but this "deep sleep" affects it too (and keeping network alive doesn't help keeping other processes awake).

While trying to do that, I found the following commands most useful:

$ ping -D -i 10 9.9.9.9 ;: -D works on SailfishX terminal
$ date +%s ;: usually on separate {linux} box
$ HISTTIMEFORMAT='%d/%H:%M:%S: ' history 
$ perl -le 'print scalar localtime 1511551151' ;: definitely outside {default} SailfishOS environment

With that pingrunning I left XperiaX untouched many times over various time intervals, occasionally checking screen from time to time, pressing enter (for marker lines), counting lines, comparing timestamps and so on...

(*) Tried to escape "deep sleep" by doing $ setsid nohup ping -D -i 10 9.9.9.9 -- *nohup.out stops getting output when screen goes blank (or soon after) anyway...

keeping ssh connections alive

Due to various (internal and external) reason when idling over ssh connections those tend to halt or shut down.

EDIT: Probably the most simplest way is to try:

$ keepalive-tool -- ssh -oServerAliveInterval=nnn user@remotehost

If keepalive-tool is not installed, do:

$ devel-su
# pkcon install libkeepalive-glib-tools
# exit
$ keepalive-tool -- ssh -oServerAliveInterval=nnn user@remotehost

(based on overnight idle I did not see any (noticeable) difference in battery consumption)

For determining how to resolve the value of nnn crawl further in this text for now (Now just a quick update, I'll refactor this later).


If you're connecting to openssh server, and have enough privileges to configure the ssh server, simplest thing to do is to edit /etc/ssh/sshd_config on the server and add the following:

ClientAliveInterval nnn

(after configuring and restarting sshd, check that you can still connect to server before dropping current connection to ensure you aren't locking you out due to server misconfiguration (due to a typo...))

(if you cannot (or want to ) do configure sshd, see an alternative below)

nnn is a value small enough that the NAT mapping between your host and server doesn't timeout, but high enough to keep the "pings" at minimum (I've seen timeouts happening at 300s (just now), less than 240s (connection dropped today at work using that value), and 120s (faint memory from my past)).

The best way to get suitable value for nnn is to test it. In order to do so, ssh to the host you're using and run the following (works on bash 4.x and zsh 5.x):

$ for t in {55..5555..10}; do printf ' %d ' $t; date; sleep $t; done

and when you see no the information stops flowing, the first (number) column in like 10s before the last is suitable value for nnn.

When ClientAliveInterval is set on server, server will ping the client in those intervals. This seems to wake ssh client (running on e.g. fingerterm(*)). *ssh client has option -oServerAliveInterval=nnn -- just that when ssh is in "deep sleep"(*) set by SailfishOS it cannot send those alive messages...

If you cannot (or want to) configure sshd, one alternative is to create ssh master control socket in a screen session, run interval ping there, detach it and run another ssh (using the same control socket) for idling purposes:

On nemo terminal, execute:

$ cd ~
$ screen ssh -M -S .ssh/ms-host user@remotehost ping -D -i nnn 127.0.0.1

(-D is useful for timestamping, but some older pings don't have it -- if yours doesn't, drop it)

After connection is made (e.g. passwd given), detach from screen by pressing Ctrl-a d

Now, on the same terminal, you can execute

$ ssh -S .ssh/ms-host 0.1

to get terminal on the remotehost.

The latter uses the ~/.ssh/ms-host control socket to "connect". Idling here should be no problem. Pinging 127.0.0.1 (in background, use screen -r to reattach) has the effect of printing some output every nnn seconds, causing 2-way traffic between client and server, keeping connection alive that way.

By the way: I did not see battery draining any faster while having ssh connection live overnight...


(*) That "deep sleep" is interesting phenomenon happening on the device. It probably also affects WhatsApp; all this is byproduct of trying to get whatsapp web working w/o interruptions. My best guess is that WhatsApp client should be active (towards servers) but this "deep sleep" affects it too (and keeping network alive doesn't help keeping other processes awake).

While trying to do that, I found the following commands most useful:

$ ping -D -i 10 9.9.9.9 ;: -D works on SailfishX terminal
$ date +%s ;: usually on separate {linux} box
$ HISTTIMEFORMAT='%d/%H:%M:%S: ' history 
$ perl -le 'print scalar localtime 1511551151' ;: definitely outside {default} SailfishOS environment

With that pingrunning I left XperiaX untouched many times over various time intervals, occasionally checking screen from time to time, pressing enter (for marker lines), counting lines, comparing timestamps and so on...

(*) Tried to escape "deep sleep" by doing $ setsid nohup ping -D -i 10 9.9.9.9 -- *nohup.out stops getting output when screen goes blank (or soon after) anyway...

keeping ssh connections alive

Due to various (internal and external) reason when idling over ssh connections those tend to halt or shut down.

EDIT: Probably the most simplest way is to try:

$ keepalive-tool -- ssh -oServerAliveInterval=nnn user@remotehost

If keepalive-tool is not installed, do:

$ devel-su
# pkcon install libkeepalive-glib-tools
# exit
$ keepalive-tool -- ssh -oServerAliveInterval=nnn user@remotehost

(based on overnight idle I did not see any (noticeable) difference in battery consumption)

For determining how to resolve the value of nnn crawl further in this text for now (Now just a quick update, I'll refactor this later).


If you're connecting to openssh server, and have enough privileges to configure the ssh server, simplest thing to do is to edit /etc/ssh/sshd_config on the server and add the following:

ClientAliveInterval nnn

(after configuring and restarting sshd, check that you can still connect to server before dropping current connection to ensure you aren't locking you out due to server misconfiguration (due to a typo...))

(if you cannot (or want to ) do configure sshd, see an alternative below)

nnn is a value small enough that the NAT mapping between your host and server doesn't timeout, but high enough to keep the "pings" at minimum (I've seen timeouts happening at 300s (just now), less than 240s (connection dropped today at work using that value), and 120s (faint memory from my past)).

The best way to get suitable value for nnn is to test it. In order to do so, ssh to the host you're using and run the following (works on bash 4.x and zsh 5.x):

$ for t in {55..5555..10}; do printf ' %d ' $t; date; sleep $t; done

and when you see no the information stops flowing, the first (number) column in like 10s before the last is suitable value for nnn.

When ClientAliveInterval is set on server, server will ping the client in those intervals. This seems to wake ssh client (running on e.g. fingerterm(*)). *ssh client has option -oServerAliveInterval=nnn -- just that when ssh is in "deep sleep"(*) set by SailfishOS it cannot send those alive messages...

If you cannot (or want to) configure sshd, one alternative is to create ssh master control socket in a screen session, run interval ping there, detach it and run another ssh (using the same control socket) for idling purposes:

On nemo terminal, execute:

$ cd ~
$ screen ssh -M -S .ssh/ms-host user@remotehost ping -D -i nnn 127.0.0.1

(-D is useful for timestamping, but some older pings don't have it -- if yours doesn't, drop it)

After connection is made (e.g. passwd given), detach from screen by pressing Ctrl-a d

Now, on the same terminal, you can execute

$ ssh -S .ssh/ms-host 0.1

to get terminal on the remotehost.

The latter uses the ~/.ssh/ms-host control socket to "connect". Idling here should be no problem. Pinging 127.0.0.1 (in background, use screen -r to reattach) has the effect of printing some output every nnn seconds, causing 2-way traffic between client and server, keeping connection alive that way.

By the way: I did not see battery draining any faster while having ssh connection live overnight...


(*) That "deep sleep" is interesting phenomenon happening on the device. It probably also affects WhatsApp; all this is byproduct of trying to get whatsapp web working w/o interruptions. My best guess is that WhatsApp client should be active (towards servers) but this "deep sleep" affects it too (and keeping network alive doesn't help keeping other processes awake).

While trying to do that, I found the following commands most useful:

$ ping -D -i 10 9.9.9.9 ;: -D works on SailfishX terminal
$ date +%s ;: usually on separate {linux} box
$ HISTTIMEFORMAT='%d/%H:%M:%S: ' history 
$ perl -le 'print scalar localtime 1511551151' ;: definitely outside {default} SailfishOS environment

With that pingrunning I left XperiaX untouched many times over various time intervals, occasionally checking screen from time to time, pressing enter (for marker lines), counting lines, comparing timestamps and so on...

(*) Tried to escape "deep sleep" by doing $ setsid nohup ping -D -i 10 9.9.9.9 -- *nohup.out stops getting output when screen goes blank (or soon after) anyway...