behavior of ServerAliveInterval with ssh connection
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
behavior of ServerAliveInterval with ssh connection
Hi experts,
Using ssh I am logging to another system and executing scripts there that creates new machines, and do some setups. It takes around 7-8 hours. So what happened the ssh connection keeps dropping and I always get timeout with unsuccessful execution of the script.
So now I am using this argument along with ssh connection:
Code:
"ssh -o ServerAliveInterval=60 user@host ...."
This ssh is invoked multiple times. The problem is after few ssh connection, I am getting error :
Quote:
too many logins of user
and the after ssh connections are getting closed after successful logins.
So is it the behavior of the ServerAliveInterval, that keeps the ssh user login session in remote machine alive even after ssh work is over and that's why my further logins are disconnected ?
Last edited by divyashree; 10-21-2016 at 10:47 PM.
ServerAliveInterval, used with ServerAliveCountMax, send a message over the encrypted channel and then officially disconnect if the limits for lack of response are exceeded. See the manual page of ssh_config for more. It won't produce any error message other than indicating that the connection is dropped. Maybe ServerAliveCountMax needs to be increased.
Regardless, if your connection is likely to break during a long task, I'd work with a terminal multiplexer like "tmux" or "screen". When you log in the first time, start "tmux" then start your task. If you get disconnected, log in again and reconnect with "tmux a".
The error "too many logins of user" is something else that is in the way and not SSH itself, at least it's not Open SSH server. Does your server have some kind of rate limiting like "sshguard" or "fail2ban" installed?
ServerAliveInterval, used with ServerAliveCountMax, send a message over the encrypted channel and then officially disconnect if the limits for lack of response are exceeded.
So if I am not using ServerAliveCountMax along with ServerAliveInterval, will the sessions stay alive forever ?
So if I am not using ServerAliveCountMax along with ServerAliveInterval, will the sessions stay alive forever ?
If the TCP connection is broken or unreliable, the SSH connection will eventually hang in practice. If you have ServerAliveCountMax and ServerAliveInterval set, then at least you know when the connection is no longer there in practice. If you use a terminal multiplexer like "tmux" then you can recover seamlessly. You'll need to use keys and a key agent for optimal performance.
Code:
while ! ssh -i ~/.ssh/some_key_rsa -t server.example.com 'tmux a || tmux'; do sleep 2; done
A similar trick can be done with "screen" if you do not have "tmux" and cannot install it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.