1

I'm having issues with a series of GNU/Linux industrial devices that I connect to via SSH. The configuration is very basic, as I haven't made any changes to the server, and on the client side, I only have the following configuration in .ssh/config:

Host <hostname>
    User <username>
    Port <port>

The problem I'm facing is that whenever I execute commands that generate a large amount of output, such as ls with a long result, apt upgrade, or cat on a large file, the SSH connection becomes unresponsive and doesn't do anything. It seems to get stuck or freeze.

I'm not sure what could be causing this issue. Could it be related to the SSH configuration or some other factor? Any help or suggestions would be greatly appreciated.

It seems to be a problem with the network where the SSH server is located since other devices, with the same configuration, don't have any issues. However, I don't have access or permission to modify the network; I only have control over my own server. Is there a way to limit the server's resources in order to improve accessibility and performance while working with it?

Fco Javier Balón
  • 1,173
  • You might want to take a look into trickle - it allows limiting bandwidth within the userspace. A possible application cna be found in this answer. trickle may be run as a deamon. – FelixJN May 26 '23 at 11:08
  • Perhaps you can add/uncomment in sshd_config the UseDNS no whichdoesn't delay ssh. – admstg May 26 '23 at 13:18

2 Answers2

0

It looks like a CPU issue more, since ls or cat also cause the issue. Is the device the same than the other? You could try to confirm this with top while running a big ls. If it's this, you could try to prepend your commands with nice -n 10 like this: nice -n 10 ls so all your commands will be deprioritized.

If you want to explore the network part, and if your devices doesn't have a minimal kernel, you could try to use bbr to prevent the saturation of network buffers, and fq_codel for a better cohabitation between the flows:

cat << EOF > /etc/sysctl.d/99-network.conf
net.core.default_qdisc=fq_codel
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl --system

If you are sure it is the network, and bbr / fq_codel doesn't do the job, and you have a kernel with tc, you could setup traffic-shaping with bandwidth reservation for ssh with tc and htb.

setenforce 1
  • 535
0

I have finally resolved it by adding the following line to the OpenVPN configuration file:

mssfix 1410

This means that OpenVPN is configured to set the maximum segment size (MSS) to 1410 bytes. MSS is important in network connections because it determines the maximum size of packets that can be sent over the connection. A lower MSS value can be useful in situations where large packets might experience fragmentation on the network or have performance issues. Setting a lower MSS value can help avoid these problems.

Fco Javier Balón
  • 1,173