Channel closed exception in pipeline

While the issue is tracked under - JENKINS-49707.
To overcome this issue ensure sufficient space is available on connected agents.
If you are already into the error state, then disconnect the agent node from Jenkins UI, check the available space in agent and again launch it using Jenkins UI.

This worked for me.

Any chance your Agent is started via SSH? We were facing this issue after migrating our Jenkins agents to a new server infrastructure.

Problem
Apparently on the new servers in /etc/ssh/sshd_config a RekeyLimit was configured:

RekeyLimit 512M 1h

This meant that after 512 MB of transferred data or 1h of connection time, the key was renegotiated. In our case, this renegotiation happened during steps like 'sshagent' oder 'withMaven' which lead to the exact exception you are describing.

It seems that this only happens for steps that run over a long-ish period of time, experience a key renegotiation and end with some sort of file operation - just like in your case.

Solution
We resolved it by setting RekeyLimit in etc/ssh/sshd_config on the agent to its default value:

RekeyLimit default none

and then restarting the sshd.service and Jenkins' remoting.jar.

Setting the RekeyLimit to default effectively leads to the cipher deciding when to reconnect:

$ man sshd_config  RekeyLimit    Specifies the maximum amount of data that may be transmitted before the session key is     renegotiated, optionally followed a maximum amount of time that may pass before the session     key is renegotiated. [...] The default is between ‘1G’ and ‘4G’, depending on the cipher.      [...] The default value for RekeyLimit is default none, which means that rekeying is     performed after the cipher's default amount of data has been sent or received and no time     based rekeying is done.

This may still lead to random exceptions when the cipher's default amount of data is reached. We somewhat mitigated this by configuring the connection between Jenkins Master and Agent to disconnect when no jobs are running so that we (almost) never reach the cipher's default amount of data within the same ssh session.