01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | # How to check sshd logs tail -f -n 50 /var/log/secure | grep sshd # Limit sessions for a particular user sudo vim /etc/security/limits .conf ### Add this line ### foo-user - maxlogins 1 # Setting max sessions globally grep MaxSessions /etc/ssh/sshd_config # Increase max session by commenting out this line sudo vim /etc/ssh/sshd_config ### Uncomment this line ### #MaxSessions 10 # Server side increase timeouts - this is important for automation as some SSH clients may not set timeouts properly and cause session timeout errors, leading to false negative results of service status monitoring via SSH sudo vim /etc/ssh/sshd_config ### Add these lines ### KeepAlive yes ClientAliveInterval 1200 ClientAliveCountMax 3 # 1200 x 3 = 3600 seconds or 1 hour # Restart sshd sudo systemctl reload sshd sudo service sshd restart |
Some common errors:
1. An established connection was aborted by the server.
2. Permission denied (password).
Although the errors above haven’t been fixed, it’s possible that busy servers such as SFTP or HTTP may drop connections if it’s being overwhelmed. Therefore, the workaround for automated agents would be to include a do-while loop to ensure the a connection is made prior to proceeding to the next lines in a program. A demonstration of this is written here.
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | # Possible Cause 0: Client connection timeout was set too low # Resolution 0: set SSH session connection timeout to a high or let server decide along with setting Operation Timeout to 'unlimited' # Example for PoSH-SSH New-SSHSession -ComputerName $linuxServer -Credential $sshCredentials -Port $sshPort -AcceptKey -ConnectionTimeout 300 -OperationTimeout 0 # this last part is important # Possible Cause 1 By default, OpenSSH uses GSSAPIAuthentication API and the underlying kerberos 5 code to provide a alternative means of authentication other than ssh_keys. However, GSSAPIStrictAcceptorCheck can sometimes delay the connections and even drops them if connection stability is also an issue. # Resolution 1 sudo vim /etc/ssh/sshd_config ### Uncomment this to skip GSSAPIStrictAcceptorCheck ### GSSAPIStrictAcceptorCheck no # Possible Cause 2 SSH would do a reverse lookup on every connection request, so it might be waiting for some high NSLookup timeouts. Connections may even be dropped if the timeout is too high. # Resolution 2 sudo vim /etc/ssh/sshd_config ### Uncomment this line ### UseDNS no # Possible Cause 3: authentication modes are too restricting sudo vim /etc/ssh/sshd_config ### Set this line ### StrictModes no # Possible cause 4: Fail2Ban interfering with ssh connections # Follow this quick guide: https://blog.kimconnect.com/install-fail2ban-on-centos-7/ to set 'ignoreip' for the source host and/or network # Optionally, for testing purposes, one may stop that apparatus to rule out possibilities of fail2ban filtering connections. sudo systemctl stop fail2ban sudo systemctl disable fail2ban |
Categories: