A few weeks back, I was working on a project that had the Husky pre-push hook configured. After working on it for a few days, I noticed that sometimes code is not getting pushed to the remote repository. After a headache of trial and error, I realized that the pre-push hook was taking so much time to finish. And when it did, there was no message of code being pushed to the remote repo in the terminal. Something was odd. I learned that the SSH connection between the terminal and GitHub initiates when we execute and terminates when the code is pushed successfully. However, if the connection is inactive for a certain period of time, it terminates itself due to timeout. git push Since Husky pre-push was taking so long time to finish its job, the SSH connection with the GitHub server was timing out. The dead connection resulted in the code not getting pushed at all. I needed a way to keep the connection alive for a few more minutes. Luckily, we can do this in the terminal itself. Prerequisites Your terminal must be connected to your GitHub account via SSH. You can find more information . here Solution As I said, the solution is to keep the connective alive until the husky finish its task. It's easier than I thought. In your terminal, go to the directory that stores SSH information. Usually, it's folder in the home directory. Execute this command in the terminal: /.ssh cd ~/.ssh The tilde symbol(~) represents directory. Since our desired destination folder is in the home directory itself, this command will change the current working directory to . /home /home/.ssh Create a file named without any extension. Add the following text to the file: config Host *
  ServerAliveInterval 60
  ServerAliveCountMax 30 Connect to the host once again and you'd see the success. If not, increase the duration by a few minutes until you find your sweet spots. The way to understand this setting is explained in the next section. Explanation But what and actually do? ServerAliveInterval ServerAliveCountMax According to the SSH manual: Sets a timeout interval in seconds after which if no data has been received from the server, ssh will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server. This option applies to protocol version 2 only. ServerAliveInterval: The default value is 3. If, for example, is set to 15 and is left at the default, if the server becomes unresponsive, SSH will disconnect after approximately 45 seconds. This option applies to protocol version 2 only. ServerAliveCountMax: ServerAliveInterval ServerAliveCountMax So to summarize: The client will wait as idle for 60 seconds i.e. time. ServerAliveInterval Then, it will send a to the server and expect a response. no-op null packet If no response comes, then it will keep trying the above process till 30 times, defined with . So it will wait for 1800 seconds, which is half an hour. ServerAliveCountMax If the server still doesn't respond, then the client disconnects the SSH connection. Things to Know Who waits for the response In our case, the client is waiting for the server's response. Because the GitHub server sends a response back when the code is pushed. If you want the client to send a response, you should use and . ClientAliveInterval ClientAliveCountMax Different config settings for different hosts The asterisk symbol (*) sets this configuration for every connected host. If you want to set this for a particular host, or only one host, you can do it in following way: Host hostname1
    SSH_OPTION value
    SSH_OPTION value

Host hostname2
    SSH_OPTION value

Host *
    SSH_OPTION value The list of available connected hosts can be found in the file, which is located in the same directory. known_hosts Wrapping Up Server alive messages are useful when an SSH server has been configured to close connections after a period of time with no traffic. Setting these two options keeps the session alive by sending a packet every *ServerAliveInterval *seconds for a maximum of times. ServerAliveCountMax As a developer, we come across new problems every single day. Some of those problems challenge our skills; others challenge our patience. For me, this problem falls into the latter category. Hence I decided to write an article about it. I hope you found this article helpful. If you want to say hi, my DMs are always open. I am most active on , and . Twitter LinkedIn Showwcase Happy coding! 👨‍💻 Also published . here

Twitter

2022 - HackerNoon Contributor of the Year - Git

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - How To

2022 - HackerNoon Contributor of the Year - Rest Api

Read My Stories

Let's Connect!

Nominated for 2022 - HackerNoon Contributor of the Year - Rest Api

Nominated for 2022 - HackerNoon Contributor of the Year - How To

Nominated for 2022 - HackerNoon Contributor of the Year - Git

Nominated for 2022 - HackerNoon Contributor of the Year - Github

SWE Intern @ Hackernoon 😎

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Keeping SSH Connection Alive for Longer Durations

Keeping SSH Connection Alive for Longer Durations

Too Long; Didn't Read

Company Mentioned

Kaushal Joshi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Keeping SSH Connection Alive for Longer Durations

Too Long; Didn't Read

Company Mentioned

Kaushal Joshi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES