ssh2 keys not recognised

[ahgittin]

Tectia ssh keys aren't recognised by Brooklyn. The ssh process fails to connect to remote machines, and the following appears in the log:

2013-01-18 11:56:43,666 ERROR net.schmizz.concurrent.Promise [pool-2-thread-3]: <<authenticated>> woke to: net.schmizz.sshj.userauth.UserAuthException: Problem getting private key from PKCS8KeyFile{resource=[PrivateKeyFileResource] /var/brooklyn/id_rsa_2048_a}
2013-01-18 11:56:43,667 WARN  b.util.internal.ssh.SshjTool [pool-2-thread-3]: << (brooklyn@127.0.0.1:22) error acquiring {hostAndPort=127.0.0.1:22, user=brooklyn, ssh=99999999999, password=xxxxxx, privateKeyFile=/var/brooklyn/id_rsa_2048_a, privateKey=xxxxxx, connectTimeout=0, sessionTimeout=0} (attempt 4/4, in time 2s 478ms/2m): Exhausted available authentication methods
2013-01-18 11:56:43,669 DEBUG b.util.internal.ssh.SshjTool [pool-2-thread-3]: brooklyn@127.0.0.1:22 failed to connect (rethrowing)
brooklyn.util.internal.ssh.SshException: (brooklyn@127.0.0.1:22) (brooklyn@127.0.0.1:22) error acquiring {hostAndPort=127.0.0.1:22, user=brooklyn, ssh=999999999, password=xxxxxx, privateKeyFile=/var/brooklyn/id_rsa_2048_a, privateKey=xxxxxx, connectTimeout=0, sessionTimeout=0} (attempt 4/4, in time 2s 478ms/2m); out of retries:Exhausted available authentication methods
    at brooklyn.util.internal.ssh.SshjTool.propagate(SshjTool.java:724) ~[brooklyn-core-0.5.0-SNAPSHOT.jar:na]
    at brooklyn.util.internal.ssh.SshjTool.acquire(SshjTool.java:573) ~[brooklyn-core-0.5.0-SNAPSHOT.jar:na]
    at brooklyn.util.internal.ssh.SshjTool.connect(SshjTool.java:321) ~[brooklyn-core-0.5.0-SNAPSHOT.jar:na]
    at brooklyn.location.basic.SshMachineLocation.connectSsh(SshMachineLocation.java:291) [brooklyn-core-0.5.0-SNAPSHOT.jar:na]
    ...

Tectia and other ssh2 format keys are commonly used in large organisations so it would be good to support these.

[ahgittin]

Workaround

A tectia/ssh2 private key can be converted to openssh/ssh1 format with:

ssh-keygen -i -f my_id_rsa_ssh2_a > my_id_rsa_ssh1

This can then be imported in the usual way.

Public keys can be converted with the same command for use at the server (depending which format is required there by the ssh daemon; that is independent of Brooklyn).

[ahgittin]

It still might be nice to support ssh2 natively. This isn't available in sshj or jsch, both of which Brooklyn currently supports (preferring sshj), but looks like Ganymed [1] at Google Code does. Alternatively we could contribute an ssh2 FileKeyProvider which does the ssh2->ssh1 conversion to sshj.

If you're interested in having this please comment describing use case and saying which route you'd prefer.

[1] http://code.google.com/p/ganymed-ssh-2/

[ahgittin]

Looking at it a bit more, I think implementing a FileKeyProvider might be the simplest, and we should be able to autodetect key type.

Hit a very similar issue again today in another company, using Tectia, trying to connect in to Github. Github client by default assumes OpenSSH private keys; and if you've saved it in SSH2 format it comes back as "auth denied".

PuttyGen btw will create private keys which appear to be in the same format as Tectia; that may help with experimenting.

[grkvlt]

I assume the format is the http://tools.ietf.org/html/rfc4716 one, like this:

---- BEGIN SSH2 PUBLIC KEY ----
Base64 data as usual...
---- END SSH2 PUBLIC KEY ----

In that case, I'm in favour of adding support to sshj, if possible. I will create an issue on their repo and have a look at what would be involved.

[ahgittin]

the keys I've encountered are slightly different:

---- BEGIN SSH2 ENCRYPTED PRIVATE KEY ----
Subject: brooklyn
Comment: "2048-bit rsa, brooklyn@vm-XXXX-XXXX, Mon Sep 10 2012 14:22:3\
5 -0400"
P2/56wAAbase64base64base64base64base64base64....
...
Xy9Zzqi99=
---- END SSH2 ENCRYPTED PRIVATE KEY ----

pretty sure you can generate these with PuttyGen. not sure if this is the same or different to the spec you've seen.

[ahgittin]

question: is ssh2 transport support different to ssh2 keys?

would it be the case that some users might want to support ssh2 only, not openssh? in which case the ganymed route is more useful than mere key support for ssh2 in sshj. (though both might be useful.) if doing key support, i think this could be done in brooklyn while waiting on sshj to accept it. autodetecting key type is a very useful thing.

i will investigate. appreciate any feedback.

[grkvlt]

So, as I understand it, sshj supports SSH2 (https://github.com/shikhar/sshj) as well. The problem is that RFC4716 only defines the public key file format. Vendors are free to define their own private key formats. Therefore, we would be justified in adding a key format detector and translator (within certain limits) to Brooklyn, and probably also sshj. This means I don't see any need for Ganymed.

@ahgittin @aledsage wdyt?

[ahgittin]

Good plan.

[ahgittin]

tectia is supported via an alternate CLI-based mechanism, in PR #478 . that fixes two related issues #476 and #477 which would probably bite us even if we fixed this. so closing this as won't fix. can re-open (or open new issue at apache) if there is a need.

also note https://github.com/shikhar/sshj/issues/54 .