Can't SSH due to too many authentication failures, even after reboot


Recommended Posts

Where's the configuration or setting that says which IPs are blocked from connecting via SSH?  I have checked /etc/hosts.deny but I believe it won't persist between reboots anyway.

 

I can only connect if I use this:

 

ssh -o IdentitiesOnly=yes root@unraid

 

Additional info re why I'm asking:

 

- Fix Common Problems said I was possibly compromised on March 14th.  All the attempts came from the static IP of my workstation and all on a range of ports that aren't explicitly configured in unRAID

- Until this afternoon SSH was still on port 22 but that's OK because of the other stuff below (it's not on port 22 anymore, but that's made no difference)

- My ISP's router is a gateway device only and everything inside it is protected by various IDP and DPI devices (I would never use an ISP's "free" device as anything other than a gateway)

- unRAID is not exposed to the internet, is not in any sort of DMZ and there are no port forwards or pinholes that allow SSH anywhere near it from the outside

- I've rebooted

- unRAID is the latest version

- All containers and plugins are on latest versions

- There's no access to anything from the outside except via a VPN from specific approved devices, including explicit MAC filtering

- SSH keys in /boot/config/ssh are not 0 bytes in size, as per this:

 

 

 

For that reason, I don't think I've actually been compromised - it was probably something else that I'm yet to track down.  On that day I was making some changes and might've messed something up.

 

Thanks

Edited by digitalformula
Link to comment

If you are using ssh-agent (or equivalent), you should keep the number of keys loaded under 3, maybe 5 at the most.

ssh will attempt every single key in the agent, and every recognizable id_* private key file from the .ssh directory. Most ssh servers will close the connection after 3 attempts of keys or passwords

 

This is because if you don't specify a key file to use in the command line or the ssh client config, it has to try everything in order. and if you have a lot of keys... it would have try them all, looking like someone who doesn't know what the correct / valid key is to the server.

Edited by ken-ji
  • Like 1
Link to comment
10 hours ago, ken-ji said:

If you are using ssh-agent (or equivalent), you should keep the number of keys loaded under 3, maybe 5 at the most.

ssh will attempt every single key in the agent, and every recognizable id_* private key file from the .ssh directory. Most ssh servers will close the connection after 3 attempts of keys or passwords

 

This is because if you don't specify a key file to use in the command line or the ssh client config, it has to try everything in order. and if you have a lot of keys... it would have try them all, looking like someone who doesn't know what the correct / valid key is to the server.

 

I would have thought that, too, but I have various aliases setup that do specify the appropriate private key when making the connection, and on a non-standard port now.  ssh-agent shouldn't really be required after adding the key to the server's ~/.ssh/authorized_keys though (which I have done).

 

I didn't "fix" it though.  The workstation in question needed to be rebuilt and so I've just setup an unRAID-specific key pair that I'll use from now on.  The original key is only used for some other private connections so doesn't need to be used for unRAID on this network.

 

Thanks for responding, though!

Link to comment
  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.