[erlang-questions] detecting ssh auth failures

[Niclas Eklund]

Hello!

Oh sorry, I was probably a little bit vague. The #ssh_msg_disconnect{} 
record I just included to show how the SSH internally construct a 
disconnect message and passes it to the other side. I.e. that it can 
contain other than a fixed description.

I guess that this tuple would break less code:

{error, {ssh_disconnect_protocol_version_not_supported, Description}}

than this one:

{error, ssh_disconnect_protocol_version_not_supported, Description}

Best Regards,

Niclas @ Erlang/OTP



On Fri, 27 May 2011, Daniel Goertzen wrote:

>> I guess that you would prefer to get, for example, an integer or atom as
>> error reason. Correct?
>
>
> That's right.
>
> I like the tuple solution because then I wouldn't have to include the record
> definition.  Furthermore, I would prefer an atom instead of a macro for the
> same reason.
>
>
>
>> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED,
>>                    description = "Protocol version " ++  StrVsn
>>                                  ++ " not supported",
>>                    language = "en"},
>
>
>
> This still has some limitations.  What if I'm making a GUI app in Spanish
> and I wanted to display the unsupported version in a dialog box?  Something
> like the following would be more flexible...
>
> {error, {ssh_disconnect_protocol_version_not_supported, StrVsn}}
>
> ... and more consistent with the way other parts of OTP work (tcp, ssl).
>
>
> But I'm making a mountain out of a molehill. :)   I really only need to
> separate auth errors from other kinds of errors.  Any of your ideas would
> help.
>
> Dan.
>
>
>
> On Thu, May 26, 2011 at 10:09 AM, Niclas Eklund <nick@REDACTED>wrote:
>
>>
>> Hi!
>>
>> I guess that you would prefer to get, for example, an integer or atom as
>> error reason. Correct? I.e. so you could match on the case when you get
>> "Unable to connect using the available authentication methods". In this case
>> the generated message is (the macro represents an integer):
>>
>> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE,
>>                    description = "Unable to connect using the available"
>>                                  " authentication methods",
>>                    language = "en"},
>>
>> But in some cases it contain additional information. E.g.
>>
>> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED,
>>                    description = "Protocol version " ++  StrVsn
>>                                  ++ " not supported",
>>                    language = "en"},
>>
>> In the latter the description reveals more details. Perhaps the error
>> messages could have been a 3 tuple:
>>
>>  {error, Code, Description}
>>
>> instead of what's normally used {error, Reason}. Changing the return value
>> would break existing code (applications using SSH), which wouldn't be very
>> popular ;-) Perhaps a configuration parameter could be used to control this
>> (the default behaviour should as it is) ....
>>
>> Best Regards,
>>
>> Niclas @ Erlang/OTP
>>
>>
>> On Tue, 10 May 2011, Daniel Goertzen wrote:
>>
>>  I am using ssh to automatically connect and operate a remote device.  I'd
>>> like to distinguish authentication failures from other kinds of failures.
>>> Currently I will get this as an auth failure from ssh:connect():
>>>
>>> {error,"Unable to connect using the available authentication methods"}
>>>
>>> Now I could include that error string in a pattern to detect an auth
>>> failure, but it feels rather brittle (ie, what if someone changes the
>>> wording).  Is there a better way to do it?  Is this an API design bug?
>>>
>>> Regards,
>>> Dan.
>>>
>>>
>>
>>
>
>
> -- 
> Daniel Goertzen
> -----------------
> dang@REDACTED (work)
> daniel.goertzen@REDACTED (home)
> -----------------
> 1 204 272 6149 (home/office)
> 1 204 470 8360 (mobile)
> -----------------
>