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