Tag Archives: error

Received disconnect from: Too many authentication failures for ubuntu

Short answer: Add IdentitiesOnly yes to your .ssh/config file.

Long answer:

I was receiving the error message “Received disconnect from X.X.X.X: 2: Too many authentication failures for ubuntu” while trying to login to some of my servers. Tried logging into various other servers and some worked and some didn’t. I was using public key authentication and I know the keys were correct so I tried logging into the failing servers from other machines and they all worked, same keys, so the keys were all good and the server was working just fine.

Time to ssh -vvv to see what errors were occuring. At the end of the output I was seeing a lot of this:

debug1: Offering RSA public key: wes@desktop
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: wes@desktop
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey

Ok, so it looks like my public keys are failing. I’m using my .ssh/config file to assign specific IdentityFiles to Hosts, perhaps that was failing so I tried passing the path to the IdentityFile directly via ssh -i. Still nothing, it still is passing several publickeys and failing on all of them. My servers all have the default setting in the sshd_config for MaxAuthTries set to 6, increasing that helps but that’s not the direction I want to change that value and I don’t want to do that across dozens of servers and this appears to be a client side problem.

Next up, I did a little googling around and ran ssh-add -L and see that ssh-agent has cached 6 public keys. ssh automatically tries those 6 keys first always and then tries the ones you specify on command line or in your config file. That’s not really super cool, I guess it assumes you are using the same key or it needs a default to look for and try. One option was to run ssh-add -D, that wasn’t really working and doesn’t directly solve the problem. Instead I read the manual, what a novel idea, and found the setting IdentitiesOnly and set it to yes, what this does is instead of checking ssh-agent for cached keys it will use your defined identity file only… MUCH better! So, just add IdentitiesOnly yes to your .ssh/config file and you are set. Or put this in the /etc/ssh/ssh_config file for the entire system.

sudo: unable to resolve host example.com

There was a nagging issue I had with a dev server where any user that used sudo it would produce the error:

sudo: unable to resolve host example.com

The probelm: the hostname had an incorrect line ending in the file /etc/hostname.

The solution: reset the fileformat for the file back to unix. I did this with vim.

sudo vi /etc/hostname
:set ff=unix

automysqlbackup/mysqldump of Views on a MySQL Replication/Slave machine

Today an error appeared in my inbox from automysqlbackup indicating there was an issue with the backups being run from a slave machine that is used strictly for running backups.

mysqldump: Got error: 1045: Access denied for user 'backup'@'localhost' (using password: YES) when using LOCK TABLES

Unfortunately this was not overly useful.

I tracked down the particular database that was causing problems and received a new error message that was getting a lot more useful:

mysqldump: Couldn't execute 'show create table `REPORT`': SHOW VIEW command denied to user 'backup'@'localhost' for table 'REPORT' (1142)

I’m no expert but what this is roughly saying is that the ‘backup’ user @ ‘localhost’ does not have the ‘SHOW VIEW’ privileges and because ‘REPORT’ is a view and not an actual table and my backup user typically only has ‘SELECT’ this is where we were failing. Seems simple enough assign the user the correct privileges and we should be good to go.

Not so fast. I ran into one more error attempting to access this view:

mysqldump: Got error: 1449: The user specified as a definer('root'@'%') does not exist

Once again I’m far from an export on this but my understanding is that the view was created or defined by a particular user known as the definer and because this is a slave machine the user that created the view was only on the master server (as the mysql db is not replicated over) and not on the slave machine therefore the view was inaccessible.

I created the correct user (exact same username @ hostname) on the slave machine and now our backup user with correct privileges was able to read the view and perform the backup as expected.


Today I loaded up one of my haproxy instances on amazon ec2 and I decided it was a good idea to take a quick peak at the haproxy.log to be sure it booted it correctly etc… I saw a ton of entries (several per second) being added to the log that looked something like this:

Jul 21 09:44:19 localhost haproxy[3536]: [21/Jul/2011:09:44:19.707] webserver webserver/ -1/-1/-1/-1/0 400 0 - - SC-- 1998/0/0/0/0 0/0 ""

I ran a quick check on the config file to be sure it was all good and sure enough the address for the webserver returned the error “Invalid server name: ‘webserver.example.com'”. Obviously that server no longer reponds, in this case it was a server that we no longer were using and my config on this machine was out of date, I updated the config, (re-ran the check) and restarted. Good to go.