[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-12016: ------------------------------------- Fix Version/s: 3.4.x Affects Version/s: 3.3.0.Beta3 @Burr what I dont get here is how people got so far without having a key. If you're new to openshift you have no domain and the tooling will ask you to create a domain and a key first. I assume the class created the domain in the web-ui then? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12016: --------------------------------------------- And Burr - we got info message saying the key should be added to preferences with a link to the preferences where you can create keys etc. What other kind of warning do you want to add that is not super annoying to have? Its only recently openshift separated the key from the creation time which explains why we only have ssh key upload when creating the domain. And if there already is a key, why would you want to delete the poorly created apps ? those apps works fine when you have the old or add a new key. And SSH is only a nightmare if you actually don't use JBDS to create your app with it. We can't get this in before codefreeze (a few hours), thus recommendation is: Create your openshift account online, use JBDS to set everything else up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Burr Sutter commented on JBIDE-12016: ------------------------------------- Yes - the Web UI was used for the domain name & the first application - at least that is how it appeared - lots of people scrambling around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-12016: ------------------------------------- Description: If the end-user's .ssh directory is empty - we should provide a stronger warning for them - ideally provide a URL to some documentation/video explaining how the user can use Eclipse/JBoss Tools to create their private/public keys - so they can then upload the .pub to OpenShift. At least 10 users failed this test today and had to be "handheld" through the process. What is worse, if the end-user uploads a slightly butchered pub key - the create application phase still works but the git clone fails - with a relatively poor error message - recovery normally means having to go up to the OpenShift console, deleting the poorly created apps - getting the pub key uploaded correctly (deleting the previous one) and starting again. The fact that Eclipse could create the keys was actually unknown by the instructor's of today's class. SSH is still a nightmare for the newbie trying to use OpenShift + JBDS. How to reproduce: 1. ASSERT: make sure you have an OpenShift user without a domain (create a new user or kill your users domain) 2. EXEC: launch *OpenShift Application* wizard and create a new application Result: Cloning fails, since there are no ssh-keys on the local machine and no keys were added to OpenShift. The wizard did not tell the user since the domain already existed. The domain creation dialog is currently the only place that would allow a user to create a new ssh-key. If you already have a domain, you'll never get asked to create your keys. was: If the end-user's .ssh directory is empty - we should provide a stronger warning for them - ideally provide a URL to some documentation/video explaining how the user can use Eclipse/JBoss Tools to create their private/public keys - so they can then upload the .pub to OpenShift. At least 10 users failed this test today and had to be "handheld" through the process. What is worse, if the end-user uploads a slightly butchered pub key - the create application phase still works but the git clone fails - with a relatively poor error message - recovery normally means having to go up to the OpenShift console, deleting the poorly created apps - getting the pub key uploaded correctly (deleting the previous one) and starting again. The fact that Eclipse could create the keys was actually unknown by the instructor's of today's class. SSH is still a nightmare for the newbie trying to use OpenShift + JBDS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-12016: ------------------------------------------ "Getting started with OpenShift Eclipse integration" by Grant Shipley at https://openshift.redhat.com/community/blogs/getting-started-with-openshi... actually tells the users how to create new ssh keys and add them to OpenShift via Web-UI: *Step 4: Configure your ssh keys*. We plan to improve the ssh key handling in JBIDE-11912. I guess we could add some warning in the wizard before we overhaul SSH key handling: !cloning-settings.png! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-12016: ------------------------------------------ To warn of possible issues before the cloning happens, I tried to find a way to verify keys on the local machine before the cloning happens. I was looking up code in apache mina sshd (which is an ssh daemon in java). What I found is pretty weird, it seems to only compare public keys on the server with public keys that were sent by the client: User authorisation by public key: http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o... : {code} PublickeyAuthenticator authenticator = session.getServerFactoryManager().getPublickeyAuthenticator(); ... if (!authenticator.authenticate(username, key, session)) { return false; } {code} Shelbie: http://grepcode.com/file/repo1.maven.org/maven2/org.ow2.shelbie/shelbie-s... : {code} if(username.equals(hostKey.getUser())) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { return true; } } return false; {code} or Gerrit: http://gerrit.googlecode.com/git-history/d2eaefa18a99ae4f246e86de61763755... : {code} if (PeerDaemonUser.USER_NAME.equals(username)) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { PeerDaemonUser user = peerFactory.create(sd.getRemoteAddress()); return success(username, session, sd, user); } else { sd.authenticationError(username, "no-matching-key"); return false; } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-12016 at 9/7/12 8:46 AM: ------------------------------------------------------------------ To warn of possible issues before the cloning happens, I tried to find a way to verify keys on the local machine before the cloning happens. I was looking up code in apache mina sshd (which is an ssh daemon in java). What I found is pretty weird, it seems to only compare public keys on the server with public keys that were sent by the client: User authorisation by public key: Framework code in *Mina* calls a registered PublickeyAuthenticator (interface) to authenticate with public key: http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o... : {code} PublickeyAuthenticator authenticator = session.getServerFactoryManager().getPublickeyAuthenticator(); ... if (!authenticator.authenticate(username, key, session)) { return false; } {code} PublickeyAuthenticator in *Shelbie*: http://grepcode.com/file/repo1.maven.org/maven2/org.ow2.shelbie/shelbie-s... : {code} if(username.equals(hostKey.getUser())) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { return true; } } return false; {code} or PublickeyAuthenticator in *Gerrit*: http://gerrit.googlecode.com/git-history/d2eaefa18a99ae4f246e86de61763755... : {code} if (PeerDaemonUser.USER_NAME.equals(username)) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { PeerDaemonUser user = peerFactory.create(sd.getRemoteAddress()); return success(username, session, sd, user); } else { sd.authenticationError(username, "no-matching-key"); return false; } } {code} was (Author: adietish): To warn of possible issues before the cloning happens, I tried to find a way to verify keys on the local machine before the cloning happens. I was looking up code in apache mina sshd (which is an ssh daemon in java). What I found is pretty weird, it seems to only compare public keys on the server with public keys that were sent by the client: User authorisation by public key: Mina (framework code that call a registered PublickeyAuthenticator to check against): http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o... : {code} PublickeyAuthenticator authenticator = session.getServerFactoryManager().getPublickeyAuthenticator(); ... if (!authenticator.authenticate(username, key, session)) { return false; } {code} PublickeyAuthenticator in Shelbie: http://grepcode.com/file/repo1.maven.org/maven2/org.ow2.shelbie/shelbie-s... : {code} if(username.equals(hostKey.getUser())) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { return true; } } return false; {code} or PublickeyAuthenticator in Gerrit: http://gerrit.googlecode.com/git-history/d2eaefa18a99ae4f246e86de61763755... : {code} if (PeerDaemonUser.USER_NAME.equals(username)) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { PeerDaemonUser user = peerFactory.create(sd.getRemoteAddress()); return success(username, session, sd, user); } else { sd.authenticationError(username, "no-matching-key"); return false; } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-12016 at 9/7/12 10:42 AM: ------------------------------------------------------------------- To warn of possible issues before the cloning happens, I tried to find a way to verify keys on the local machine before the cloning happens. I was looking up code in apache mina sshd (which is an ssh daemon in java). What I found is pretty weird, it seems to only compare public keys on the server with public keys that were sent by the client: User authorisation by public key: Framework code in *Mina* calls a registered PublickeyAuthenticator (interface) to authenticate with public key: http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o... : {code} PublickeyAuthenticator authenticator = session.getServerFactoryManager().getPublickeyAuthenticator(); ... if (!authenticator.authenticate(username, key, session)) { return false; } {code} PublickeyAuthenticator in *Shelbie*: http://grepcode.com/file/repo1.maven.org/maven2/org.ow2.shelbie/shelbie-s... : {code} if(username.equals(hostKey.getUser())) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { return true; } } return false; {code} or PublickeyAuthenticator in *Gerrit*: http://gerrit.googlecode.com/git-history/d2eaefa18a99ae4f246e86de61763755... : {code} if (PeerDaemonUser.USER_NAME.equals(username)) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { PeerDaemonUser user = peerFactory.create(sd.getRemoteAddress()); return success(username, session, sd, user); } else { sd.authenticationError(username, "no-matching-key"); return false; } } {code} The client side in mina shows pretty well how stuff is signed and sent to the server: http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o... : UserAuthPublicKey#next: {code} Signature verif = NamedFactory.Utils.create(session.getFactoryManager().getSignatureFactories(), (key.getPublic() instanceof RSAPublicKey) ? KeyPairProvider.SSH_RSA : verif.init(key.getPublic(), key.getPrivate()); ... bs.putBytes(verif.sign()); buffer.putBytes(bs.array(), bs.rpos(), bs.available()); session.writePacket(buffer); {code} SignatureFactories return signature providers that use java.security.Signature providers - http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o...: {code} protected java.security.Signature signature; {code} was (Author: adietish): To warn of possible issues before the cloning happens, I tried to find a way to verify keys on the local machine before the cloning happens. I was looking up code in apache mina sshd (which is an ssh daemon in java). What I found is pretty weird, it seems to only compare public keys on the server with public keys that were sent by the client: User authorisation by public key: Framework code in *Mina* calls a registered PublickeyAuthenticator (interface) to authenticate with public key: http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o... : {code} PublickeyAuthenticator authenticator = session.getServerFactoryManager().getPublickeyAuthenticator(); ... if (!authenticator.authenticate(username, key, session)) { return false; } {code} PublickeyAuthenticator in *Shelbie*: http://grepcode.com/file/repo1.maven.org/maven2/org.ow2.shelbie/shelbie-s... : {code} if(username.equals(hostKey.getUser())) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { return true; } } return false; {code} or PublickeyAuthenticator in *Gerrit*: http://gerrit.googlecode.com/git-history/d2eaefa18a99ae4f246e86de61763755... : {code} if (PeerDaemonUser.USER_NAME.equals(username)) { if (myHostKeys.contains(suppliedKey) || getPeerKeys().contains(suppliedKey)) { PeerDaemonUser user = peerFactory.create(sd.getRemoteAddress()); return success(username, session, sd, user); } else { sd.authenticationError(username, "no-matching-key"); return false; } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-12016 at 9/7/12 11:28 AM: ------------------------------------------------------------------- To warn of possible issues before the cloning happens, I tried to find a way to verify keys on the local machine before the cloning happens. The code in Apache Mina (http://mina.apache.org/) shows pretty well how the basic scheme works. The client signs a payload using the private key and sends it to the server. The server then verifies the signature with the public key: The client (UserAuthPublicKey#next (http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o...) instantiates some providers (http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o...) that internally use java.security.Signature: {code} Signature verif = NamedFactory.Utils.create(session.getFactoryManager().getSignatureFactories(), (key.getPublic() instanceof RSAPublicKey) ? KeyPairProvider.SSH_RSA : KeyPairProvider.SSH_DSS); {code} It then builds up a buffer with a payload that contains the public key: {code} Buffer bs = new Buffer(); bs.putString(session.getKex().getH()); bs.putCommand(SshConstants.Message.SSH_MSG_USERAUTH_REQUEST); bs.putString(username); bs.putString("ssh-connection"); bs.putString("publickey"); bs.putByte((byte) 1); bs.putString((key.getPublic() instanceof RSAPublicKey) ? KeyPairProvider.SSH_RSA : KeyPairProvider.SSH_DSS); bs.putPublicKey(key.getPublic()); {code} and then signs it... {code} bs.putBytes(verif.sign()); {code} ...and sends it to the server {code} buffer.putBytes(bs.array(), bs.rpos(), bs.available()); session.writePacket(buffer); {code} The server (UserAuthPublicKey#next (http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o...) initializes some signature providers... {code} Signature verif = NamedFactory.Utils.create(session.getFactoryManager().getSignatureFactories(), keyAlg); verif.init(key, null); ... {code} ...builds some payload... {code} Buffer buf = new Buffer(); buf.putString(session.getKex().getH()); buf.putCommand(SshConstants.Message.SSH_MSG_USERAUTH_REQUEST); buf.putString(username); buf.putString("ssh-connection"); buf.putString("publickey"); buf.putByte((byte) 1); buf.putString(keyAlg); buffer.rpos(oldPos); buffer.wpos(oldPos + 4 + len); buf.putBuffer(buffer); {code} ...and verifies the signature {code} if (!verif.verify(sig)) { throw new Exception("Key verification failed"); } {code} was (Author: adietish): To warn of possible issues before the cloning happens, I tried to find a way to verify keys on the local machine before the cloning happens. The client side in mina shows pretty well how stuff is signed and sent to the server. UserAuthPublicKey#next (http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o...): It instantiates some providers (http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o...) that internally use java.security.Signature: {code} Signature verif = NamedFactory.Utils.create(session.getFactoryManager().getSignatureFactories(), (key.getPublic() instanceof RSAPublicKey) ? KeyPairProvider.SSH_RSA : KeyPairProvider.SSH_DSS); {code} It then builds up a buffer with a payload that contains the public key: {code} Buffer bs = new Buffer(); bs.putString(session.getKex().getH()); bs.putCommand(SshConstants.Message.SSH_MSG_USERAUTH_REQUEST); bs.putString(username); bs.putString("ssh-connection"); bs.putString("publickey"); bs.putByte((byte) 1); bs.putString((key.getPublic() instanceof RSAPublicKey) ? KeyPairProvider.SSH_RSA : KeyPairProvider.SSH_DSS); bs.putPublicKey(key.getPublic()); {code} and then signs the payload... {code} bs.putBytes(verif.sign()); {code} ...and sends it to the server {code} buffer.putBytes(bs.array(), bs.rpos(), bs.available()); session.writePacket(buffer); {code} The server side then verifies this signature: UserAuthPublicKey#next (http://svn.apache.org/repos/asf/mina/sshd/trunk/sshd-core/src/main/java/o...): It initializes some signature providers... {code} Signature verif = NamedFactory.Utils.create(session.getFactoryManager().getSignatureFactories(), keyAlg); verif.init(key, null); ... {code} ...builds some payload... {code} Buffer buf = new Buffer(); buf.putString(session.getKex().getH()); buf.putCommand(SshConstants.Message.SSH_MSG_USERAUTH_REQUEST); buf.putString(username); buf.putString("ssh-connection"); buf.putString("publickey"); buf.putByte((byte) 1); buf.putString(keyAlg); buffer.rpos(oldPos); buffer.wpos(oldPos + 4 + len); buf.putBuffer(buffer); {code} ...and verifies the signature {code} if (!verif.verify(sig)) { throw new Exception("Key verification failed"); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-12016 at 9/7/12 11:33 AM: ------------------------------------------------------------------- We decided that we should try to provide some verification that the user would trigger by hitting some button *"Test..."*. The verification would mimic the verification process shown above, that signs some payload with the private key and verifies the signature with the public key. We would get the local private keys to sign some content. We'd then get the public keys from the server and verify the signature. was (Author: adietish): Since the above code snippets did not unveil any encryption check as I had expected I suggest we provide simple public key checks/comparisons. We could look up existing private keys on the local machine (Eclipse preferences / .ssh-directory) and guess the public keys for them by adding ".pub" to the name. We could then try to load them and compare them to the keys registered in OpenShift. Instead of guessing public key file names, we could also generate the public key for the given private keys - since there's always 1 single public key for a private key. The drawback is that we'd trigger secure storage password dialog or would have to ask the user to provide the private key passphrase(s). This seem very annoying/unexpected in a wizard whose purpose is just to import/create an OpenShift application. We could eventually do that verification only if the user hits a "Verify..." button (pretty much as you verify the credentials when defining a new SVN server). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-12016: ------------------------------------------ Even simpler than the approach with signing and verifying seems the following: Bouncy castle PEMReader is able to read a given private key file and return the key pair for it (private and public key). We could then simply compare the public key that the PEMReader created with the one on OpenShift. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-12016: ------------------------------------------ I found alternative implementations here: * ocap-ri (opencable project), GPLv2: https://community.cablelabs.com/svn/OCAPRI/trunk/ri/RI_Stack/jvm/security... * oauth (open authentication api), ASL - incomplete, only handles RSA: http://oauth.googlecode.com/svn/code/java/core/commons/src/main/java/net/... http://oauth.googlecode.com/svn/code/java/core/commons/src/main/java/net/... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-12016 at 9/13/12 8:25 AM: ------------------------------------------------------------------- I tried reading private key files with the jdk but did not succeed. According to http://stackoverflow.com/a/1580184/231357 and http://security.stackexchange.com/a/9601 OpenSSH keys are in PKCS1 format which the JDK/JCE is not able to read (they use PKCS8 by default). It looks like the only valid option for now is to use the BouncyCastle crypto provider library which is able to read those keys on behalf of their PEMReader. Nima SSHD is using Bouncycastle. JSch does not depend on Bouncycastle, it's able to load OpenSSHL private keys but it's not able to generate the public key for a given private key. Afaik JSch does not parse all bits required to use JDK/JCE to create a public key: {code:title=bouncy castle parsing A DSA PEM (the DER of a PEM in this snippet), it would extract q,p,m,x,y in PEMReader#readKeyPair http://grepcode.com/file/repository.jboss.org/maven2/bouncycastle/bcprov-... DERInteger p = (DERInteger)seq.getObjectAt(1); DERInteger q = (DERInteger)seq.getObjectAt(2); DERInteger g = (DERInteger)seq.getObjectAt(3); DERInteger y = (DERInteger)seq.getObjectAt(4); DERInteger x = (DERInteger)seq.getObjectAt(5); privSpec = new DSAPrivateKeySpec( x.getValue(), p.getValue(), q.getValue(), g.getValue()); pubSpec = new DSAPublicKeySpec( y.getValue(), p.getValue(), q.getValue(), g.getValue()); } KeyFactory fact = KeyFactory.getInstance(type, provider); return new KeyPair( fact.generatePublic(pubSpec), fact.generatePrivate(privSpec)); {code} {code:title=JSch only parses q, p and g in KeyPairDSA#parse http://grepcode.com/file/repo1.maven.org/maven2/com.jcraft/jsch/0.1.31/co... P_array=new byte[length]; System.arraycopy(plain, index, P_array, 0, length); index+=length; index++; length=plain[index++]&0xff; if((length&0x80)!=0){ int foo=length&0x7f; length=0; while(foo-->0){ length=(length<<8)+(plain[index++]&0xff); } } Q_array=new byte[length]; System.arraycopy(plain, index, Q_array, 0, length); index+=length; index++; length=plain[index++]&0xff; if((length&0x80)!=0){ int foo=length&0x7f; length=0; while(foo-->0){ length=(length<<8)+(plain[index++]&0xff); } } G_array=new byte[length]; System.arraycopy(plain, index, G_array, 0, length); index+=length; {code} was (Author: adietish): I tried reading private key files with the jdk but did not succeed. According to http://stackoverflow.com/a/1580184/231357 and http://security.stackexchange.com/a/9601 OpenSSH keys are in PKCS1 format which the JDK/JCE is not able to read (they use PKCS8 by default). It looks like the only valid option for now is to use the BouncyCastle crypto provider library which is able to read those keys on behalf of their PEMReader. Nima SSHD is using Bouncycastle. JSch does not depend on Bouncycastle, it's able to load OpenSSHL private keys but it's not able to generate the public key for a given private key. Afaik JSch does not parse all bits required to use JDK/JCE to create a public key: {code:bouncy castle parsing A DSA PEM (the DER of a PEM in this snippet), it would extract q,p,m,x,y in PEMReader#readKeyPair http://grepcode.com/file/repository.jboss.org/maven2/bouncycastle/bcprov-... DERInteger p = (DERInteger)seq.getObjectAt(1); DERInteger q = (DERInteger)seq.getObjectAt(2); DERInteger g = (DERInteger)seq.getObjectAt(3); DERInteger y = (DERInteger)seq.getObjectAt(4); DERInteger x = (DERInteger)seq.getObjectAt(5); privSpec = new DSAPrivateKeySpec( x.getValue(), p.getValue(), q.getValue(), g.getValue()); pubSpec = new DSAPublicKeySpec( y.getValue(), p.getValue(), q.getValue(), g.getValue()); } KeyFactory fact = KeyFactory.getInstance(type, provider); return new KeyPair( fact.generatePublic(pubSpec), fact.generatePrivate(privSpec)); {code} {code:title=JSch only parses q, p and g in KeyPairDSA#parse http://grepcode.com/file/repo1.maven.org/maven2/com.jcraft/jsch/0.1.31/co... P_array=new byte[length]; System.arraycopy(plain, index, P_array, 0, length); index+=length; index++; length=plain[index++]&0xff; if((length&0x80)!=0){ int foo=length&0x7f; length=0; while(foo-->0){ length=(length<<8)+(plain[index++]&0xff); } } Q_array=new byte[length]; System.arraycopy(plain, index, Q_array, 0, length); index+=length; index++; length=plain[index++]&0xff; if((length&0x80)!=0){ int foo=length&0x7f; length=0; while(foo-->0){ length=(length<<8)+(plain[index++]&0xff); } } G_array=new byte[length]; System.arraycopy(plain, index, G_array, 0, length); index+=length; {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-12016: ------------------------------------- Summary: OpenShift Wizard should warn if there are no private keys on local machine that match the public keys on OpenShift (was: OpenShift Wizard should warn if domain exists but there's no ssh key on local machine (domain was created in web ui)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-12016: ------------------------------------- Attachment: creating-domain.png manage-ssh-keys.png no-keys.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12016?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-12016: ------------------------------------- Description: How to reproduce: # ASSERT: make sure you have an account with at least 1 public key on OpenShift # ASSERT: make sure you have the private key for this private key registered to your SSH2 preferences in Eclipse # EXEC: launch *New OpenShift Application* wizard # EXEC: on the last page (git cloning settings), hit the SSH2 Preferences link and remove your private key from the list of private keys # ASSERT: back on the git cloning wizard page you're not warned that there's no private key that would match the private keys on your machine # EXEC: hit *Finish* Result: Cloning fails since you have no private key registered to the Eclipse SSH2 preferences that would allow you to clone from OpenShift. was: If the end-user's .ssh directory is empty - we should provide a stronger warning for them - ideally provide a URL to some documentation/video explaining how the user can use Eclipse/JBoss Tools to create their private/public keys - so they can then upload the .pub to OpenShift. At least 10 users failed this test today and had to be "handheld" through the process. What is worse, if the end-user uploads a slightly butchered pub key - the create application phase still works but the git clone fails - with a relatively poor error message - recovery normally means having to go up to the OpenShift console, deleting the poorly created apps - getting the pub key uploaded correctly (deleting the previous one) and starting again. The fact that Eclipse could create the keys was actually unknown by the instructor's of today's class. SSH is still a nightmare for the newbie trying to use OpenShift + JBDS. How to reproduce: 1. ASSERT: make sure you have an OpenShift user without a domain (create a new user or kill your users domain) 2. EXEC: launch *OpenShift Application* wizard and create a new application Result: Cloning fails, since there are no ssh-keys on the local machine and no keys were added to OpenShift. The wizard did not tell the user since the domain already existed. The domain creation dialog is currently the only place that would allow a user to create a new ssh-key. If you already have a domain, you'll never get asked to create your keys. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira