ssh multiple identities -fix- “Too many authentication failures for { username }”

So; you regularly use ssh to connect to a few different hosts – using different private keys for each user/server combination.

Your  ~/.ssh/ directory already has a few named private keys in it – you add a couple, bring the total to 5 or more…

ls ~/.ssh/
dave_mars.id_dsa
sue_deimos.id_dsa
steve_deimos.id_dsa
irene_phobos.id_dsa
lee_phobos.id_dsa
sue_mars.id_dsa
red_deimos.id_dsa

….and try connecting:

ssh -i .ssh/sue_mars.id_dsa -l sue mars

You’re denied, with an error like:

Received disconnect from {mars' IP address} 2: Too many authentication failures for sue.

Which is confusing;  this may be the first time you’ve tried connecting to phobos with sue’s account.

Add the verbose switch to you ssh command:

ssh -v -i .ssh/sue_phobos.id_dsa -l sue phobos

You’ll see this at the end of the negotiation:

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/dave_mars.id_dsa
debug1: Authentications that can continue: publickey
 debug1: Offering RSA public key: .ssh/sue_deimos.id_dsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: .ssh/steve_deimos.id_dsa
debug1: Authentications that can continue: publickey
 debug1: Offering RSA public key: .ssh/irene_phobos.id_dsa
debug1: Authentications that can continue; publickey
 debug1: Offering RSA public key: .ssh/lee_phobos.id_dsa
Received disconnect from {phobos' IP address}: 2: Too many authentication failures for sue

Your local ssh agent is offering any key it can find, pre-loaded and cached from the .ssh directory (prove this caching by moving the other named keys somewhere else on your system – they’ll still be offered). The -i flag is a more of a guideline or hint to the agent.

To force the ssh client to offer only the key specified by -i, use the

-o IdentitiesOnly=yes

option:

ssh -o IdentitiesOnly=yes -i .ssh/sue_phobos.id_dsa -l sue phobos

or:

ssh -o "IdentitiesOnly yes" -i .ssh/sue_phobos.id_dsa -l sue phobos

…you’re connected.

 

Virtio paravirtualised NIC drivers for Server 2008 / Win 7 on virtualbox

On your Virtualbox host; download the ISO of generic windows paravirtualised drivers from here:

http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

Shut down your Windows VM and set your its Adapter Type to “virtio-net”.

Boot the Windows Vm and mount the downloaded driver ISO as a virtual CD drive.

Log on to the VM and check you can browse to the virtual CD’s \Win 7\[x86|amd64]\ folder; use devmgmt.msc to install the new drivers on the paravirtualised NIC hardware (“Trust software from Redhat”).

You shouldn’t need to to reboot.

 

OSX NFS Storage Repository for XenServer

Setting up an iso Storage Repository for my XenServer testbed. CIFS is an option, but after a couple of “SR_BACKEND_FAILURE_222Could not mount the directory specified in Device Configuration” errors, I decided to try NFS, telling myself that CIFS/SMB is an ugly way of connecting unix systems to each other anyway…

OSX supports NFS nicely, and there’s a good nagware GUI available from Breslink.com.

Five minutes later my CIFS share was available over NFS.

I caught the same “SR_BACKEND_FAILURE_222…” connecting from XenServer to the NFS share until I specified “Allow mounting the folder and any subfolders inside” in the share’s advanced options – which may well be where the CIFS sharing attempt failed. XenServer presumably tries to read every subfolder of a Storage Repository as it’s mounted. I’ll test later.

Incidentally, the minimum required security was “System Standard Only”. The only other non-default sharing option was limiting access rights to the local class C subnet.

 

Routing problem(?) between BeThere and Talktalk

I’m trying to ssh to an OpenSSHD-equipped host at {redacted}.{dynservice}.org (a TalkTalk consumer adsl account) from an nix laptop on a BeThere ADSL network.

I have no problem using ssh to connect to other servers on the internet from BeThere. *But* when I disconnect my laptop from the landline Wi-Fi and tether it through a Vodafone android phone, the laptop can ssh into the host at {redacted}.{dynservice}.org perfectly. The time-out problem only seems to arise when I’m trying to ssh from my BeThere ADSL account.

Truth table:

  • Vodafone to Bethere = ssh OK
  • Vodafone to BT = ssh OK
  • Bethere to BT = ssh FAIL

When I traceroute between the hosts, there seems to some kind of routing loop (repeated patterns of IP addresses in the traceroute).

Edit:

As of this morning, the ssh-gap (and the apparent routing loop) had cleared up. Still haven’t had a definitive answer from BeThere, but I”m happy that someone, somewhere has fixed something.