Rereading my post I see that I proposed specific and simple changes to
the documentation which would solve the problem I encountered and which,
as far as I can tell, others did also:
You should now be able to SSH *to* the _remote_ host without being
prompted for a password.
Note the IMPORTANT
@PJO: While I see your problem, it isn't really what this bug report is
about. This report is about a potential problem with the handling of dsa
keys specifically.
If you have an issue with the dokumentation, file a bug report against
ubuntu-docs. That way the right people will (hopefully) see
We are closing this bug report because it lacks the information we need
to investigate the problem, as described in the previous comments.
Please reopen it if you can give us the missing information, and don't
hesitate to submit bug reports in the future. To reopen the bug report
you can click on
I've provided a very comprehensive report which should illustrate, if
you read it, where and why the documentation is confusing and I've
suggested that this be looked at.
It seems a bit odd to just close the bug without even a single request
for additional information.
What exactly is not clear
I agree that closing this bug seemed a bit premature.
@Kamus: Closing bugs, without solving them, is not necessarily a goal in
itself. If you think there are information missing, ask some follow up
questions.
** Changed in: openssh (Ubuntu)
Status: Invalid = Incomplete
--
openssh-server
Hi folks
I'm having issues here too.
Nov 10 11:26:20 some sshd[20326]: debug1: trying public key file
/root/.ssh/authorized_keys
Nov 10 11:26:20 some sshd[20326]: debug3: secure_filename: checking '/root/.ssh'
Nov 10 11:26:20 some sshd[20326]: debug3: secure_filename: checking '/root'
Nov 10
I thought I had the same problem, with
Server: Ubuntu server 8.04.1
and either/both of
Client1: Ubuntu-eee 8.04.1 (slimmed down version of Ubuntu for Asus EEE PC; ssh
client only installed)
Client2: Ubuntu server 8.04.1
file and directory permissions are correct ( setting StrictModes to
'no'
I tried to reproduce this on a very similar setup, and failed. Could you
please show me (by private mail if you like) the contents of the public
half of the DSA key, and the .ssh/authorized_keys file on the server? It
really looks like a simple typo, or perhaps a line-wrapped
authorized_keys file.