SSH permission denied
Posted: Thu Apr 14, 2016 12:01 am
Both I and my nephew have a VPS with the same provider, set up with Debian 7 and Vesta (the only difference is I have x86, he has 64-bit).
I can log in fine on my server with SSH every time. On his server, once he reboots, he seems to be able to log in, but shortly after (maybe half a day) it refuses everything - different users, password and public key authentication. I have tried public key and it fails and falls back to password... which still fails. I know the username and password is correct.
The only thing he's changed from the stock install is that he's bound SSH to a single IP address that is different from his main site's IP address. I have done the same thing on mine, but that works fine.
auth.log shows no activity when it rejects the login. fail2ban has not blocked the IP. We have restarted both fail2ban and sshd repeatedly, no change. SSH is listening on port 22 and it seems to initially connect before rejecting the authentication.
Like I said, rebooting seems to work, but we can't do that every day, there are customers using it.
I would like to see if there's something in the log that explains this, but I don't see it anywhere. Is there another place I can look?
Thanks.
I can log in fine on my server with SSH every time. On his server, once he reboots, he seems to be able to log in, but shortly after (maybe half a day) it refuses everything - different users, password and public key authentication. I have tried public key and it fails and falls back to password... which still fails. I know the username and password is correct.
The only thing he's changed from the stock install is that he's bound SSH to a single IP address that is different from his main site's IP address. I have done the same thing on mine, but that works fine.
auth.log shows no activity when it rejects the login. fail2ban has not blocked the IP. We have restarted both fail2ban and sshd repeatedly, no change. SSH is listening on port 22 and it seems to initially connect before rejecting the authentication.
Like I said, rebooting seems to work, but we can't do that every day, there are customers using it.
I would like to see if there's something in the log that explains this, but I don't see it anywhere. Is there another place I can look?
Thanks.