Apache OpenOffice (AOO) Bugzilla – Issue 27886
Document how to use non-default ssh keyfile
Last modified: 2008-11-25 14:54:43 UTC
A public key that I wish to use to access the main CVS server is attached herein. I have already been given Content Developer rights from CJ for the specs project where I initially will be working in after this public key has been accepted. Regards, Kohei
Created attachment 14553 [details] DSA public key with password
Changing issue type from Defect to Task since this is not really a defect report.
Hi sorry for the delay reassigning to support. Support, please ask ops to upload this key. thanks Louis
I created pcn28134 to have this key installed, I will let you know when this is complete. Eric
I just got confirmation that this has been completed. Eric
Cool. I'll test it tonight at home to see if I can log in via ssh. Kohei
My first attempt to establish an ssh tunnel has failed. Here is what happened: [kohei@localhost kohei]$ ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org tunnel@openoffice.org's password: Permission denied, please try again. tunnel@openoffice.org's password: Permission denied, please try again. tunnel@openoffice.org's password: Permission denied (publickey,password,keyboard-interactive). I've also tried with the username 'kohei@openoffice.org' instead of 'tunnel@openoffice.org', but got the same result. My initial concern is that it didn't ask for my passphrase, but immediately asked for my password on the server, which, according to the on-line manual, indicates a failure. Did I do something incorrectly? If not, can someone check? Thanks, Kohei
You did nothing wrong. It looks like it is not reading your key, for any number of reasons. Can I suggest we just see if a new key works? Louis
Thanks Louis. Actually I've just figured out how to make it work. Looks like I have to explicitly specify my key file with an '-i' switch, like so [kohei@localhost .ssh]$ ssh -2 -x -i ~/.ssh/id_dsa-password -L 2401:localhost:2401 tunnel@openoffice.org Enter passphrase for key 'id_dsa-password': Tunnel established. Type ctrl-c to exit. I also noticed that using the -i switch still fails if the name of the key file is "id_dsa" i.e. it works if I name my key file "id_dsa-password", but renaming it to "id_dsa" and executing ssh -2 -x -i ~/.ssh/id_dsa -L ... fails. If this is the way it's supposed to work, I think this point should be mentioned in the on-line SSH tunneling guide so that a possible confusion by future contributors can be avoided. Anyway, now that it works, I'm happy. :) Kohei
I think it's a fairly unusual issue. I have never encountered it; but then I didn't rename my key. Man does cover this, I think, but, yes, it makes sense to add to the guide, and I'm reassigning this to me to add to the ssh2 guide. thanks louis
really reassigning.. louis
Let me provide a little more details in case my previous explanation wasn't sufficient. Initially, my key file had a default name of id_dsa located at its default location of ~/.ssh/id_dsa. I then tried to establish an ssh tunnel without the -i switch (as in the on-line guide) by executing ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org This immediately asked for my password, skipping the passphrase assciated with my key file. This indicates a failure. Not knowing what had gone wrong, I then renamed my key file from id_dsa to something else (id_dsa-password), and tried to get the tunneling going again by ssh -2 -x -i ~/.ssh/id_dsa-password -L 2401:localhost:2401 tunnel@openoffice.org Now this asked for my passphrase for my key file. After punching in the correct passphrase, it gave me the tunnel. All is good. I'm happy. I took one step further just to investigate a bit more. I renamed the key file from id_dsa-password back to id_dsa, then ran ssh -2 -x -i ~/.ssh/id_dsa -L 2401:localhost:2401 tunnel@openoffice.org thinking that the key to a success is to use the -i switch to explicitly specify the location of the key. But this failed. This has led me thinking that the CVS server refuses a request for tunneling if the name of a key file at a remote location is id_dsa (default). Whether or not this is really the case I don't really know. But my suggestions was that if this is the correct behavior, then it should be mentioned in the doc. If this is not the case, and it should work with a key file with the default name at the default location (~/.ssh/id_dsa) without the -i switch, then there is something wrong either on the server end or on my end (most likely on my end). Then it doesn't have to be mentioned in the doc. I hope you don't mind me giving some clarification on this issue. I did this because I wasn't sure if you really understood my explanation in my previous comment. Kohei
I've tried to establish an ssh-tunnel from another machine running another version of Linux. The same result ensued; no success with an identity file at the default location of ~/.ssh/id_dsa. The following file paths worked, BTW. ~/id_dsa ~/.ssh/id_dsa-openoffice ~/.ssh/id_dsa-password Now I'm convinced that it is the server that refuses to take the identity file when it's located at ~/.ssh/id_dsa, and not the fault of my work station; therefore the need to document it still stands. Kohei
hi sorry for the long neglect. Did you ever succeed in establishing a tunnel? i believe that the default behavior of OOo machine is actually to accept default-named .pub keys, btw, but will route this to support after you respond for confirmation. best louis
Thanks Louis. I had forgotten about this issue myself... Yes, I have succeeded with a tunnel, but not with the default path of $HOME/.ssh/id_dsa (I put my private key at $HOME/.ssh/id_dsa-openoffice, so it is no longer a issue for me). I have tried this from multiple environments, so this behavior is likely caused by the server. However, the server takes it if the key is located at $HOME/.ssh/id_rsa (a simple rename of 'id_dsa' to 'id_rsa' will do the trick). If you can route this info to support, I'd appreciate it. Kohei
Hi thanks, Kohei. Clearly, I find this odd but am glad it works. I'll send this to support for their information, to see if perhaps the key was misplaced, too. However, since this works for you, it works for me, and I'm closing it with worksforme. Support: would you be able to see if there are any anomalies with kohei's key in the server? The tunnel works so there is no great rush. Louis
let's close this.
Reopen for SVN key migration.
Migrated to SVN.
-> closed