today me and a friend of mine spent several hours figuring out why ssh
still asked for a password after we set up public key authentication.
We have tried to understand the problem by reading 'ssh -vvv ...', but
unfortunately the output was not useful. In the end of the day we have
found out that sshd actually was logging this problem.... So that's
for the context.
Now, can you please add some debugging information to ssh, so that the
user is able to understand the problem by reading ssh -vvv which will
be much mor helpful in comparison to sshd logging. Is there any reason
you haven't done so already?
> Now, can you please add some debugging information to ssh, so that the
> user is able to understand the problem by reading ssh -vvv which will
> be much mor helpful in comparison to sshd logging. Is there any reason
> you haven't done so already?
the ssh client actually doesn't know what the problem is unless the
server tells it. It's generally a bad idea for the server to publish
that sort of detailed error message, especially when authentication has
failed; this would be equivalent to publishing information about the
user's home directory to anyone who asks.
If the problem is on the server side, you'll need to read the server
side logs to diagnose it, sorry!
On Fri, Nov 18, 2011 at 11:02 AM, Roman B. <rbys...@gmail.com> wrote:
> Hi,
> today me and a friend of mine spent several hours figuring out why ssh
> still asked for a password after we set up public key authentication.
> We have tried to understand the problem by reading 'ssh -vvv ...', but
> unfortunately the output was not useful. In the end of the day we have
> found out that sshd actually was logging this problem.... So that's
> for the context.
> Now, can you please add some debugging information to ssh, so that the
> user is able to understand the problem by reading ssh -vvv which will
> be much mor helpful in comparison to sshd logging. Is there any reason
> you haven't done so already?
Security mostly, also the fact that the error isn't on the client's
side anyway, it's server side. The administrator would be able to
find the error quickly, it's not user-solveable anyway. In the case
ofa personal machine, you're both, so your responsibility is to check
your logs.
If you expose server side errors to the client you also give attackers
more information. In this sort of a case the failure is ideally
identical to wrong password and user does not exist from the clients
point of view. Thus an attacker can't gain any information from this
route. Yes yes yes, sounds silly, but, every layer helps. It's only
a small part of a security model.
--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
"Roman B." <rbys...@gmail.com> writes: > If attacker has stolen valid key, then trying to log in with this key > will give him either a shell or the information that user directory or > .ssh is writable (if we assume there was no other problem),
Uh, no. The only thing the attacker knows is that public-key authentication with that particular key did not succeed. There are a number of reasons why it would fail: there might not be a valid authorized_keys file at all, there might be one but the key is not listed there, it might be listed but with restrictions (e.g. "from") which the client does not satisfy, etc.
I'm curious, when you were attempting to debug this, did you ever login
when prompted for a password? If you did and the client loglevel was set
to 'debug' or higher, you should have seen some messages which would
have indicated that it was an ownership or permissions issue with the
home directory.
As noted by others on the list, sshd does not send diagnostic messages
to an unauthenticated client which might help an attacker. However, once
you have authenticated by some other means (such as password
authentication), the server does send some diagnostic messages to the
client. These messages are not displayed by default, but are displayed
if the loglevel is set to 'debug.'
I'd also like to note that using -vvv generally is overkill. For most
problems, a single -v is sufficient. Using -vvv produces enough output
that it can sometimes make it difficult to spot the relevant messages.
On Fri, Nov 18, 2011 at 14:05:07 -0600, Dag-Erling Sm??rgrav wrote:
> "Roman B." <rbys...@gmail.com> writes:
> > If attacker has stolen valid key, then trying to log in with this key
> > will give him either a shell or the information that user directory or
> > .ssh is writable (if we assume there was no other problem),
> Uh, no. The only thing the attacker knows is that public-key
> authentication with that particular key did not succeed. There are a
> number of reasons why it would fail: there might not be a valid
> authorized_keys file at all, there might be one but the key is not
> listed there, it might be listed but with restrictions (e.g. "from")
> which the client does not satisfy, etc.
