vshell none for user rejected because it is unavailable

[AbhishekJ]

hi ,

i am newbee here....

I have a requirement where we need to transfer few files from SerevrA to ServerB.We had configured and files t/f are working fine but I could see some errors in logs as:

vshell none for user rejected because it is unavailable

I want to know what is "NONE" in errror.

As per some investigation: is vhsell is trying to authenticate using Public key first but since we are providing password so its assuming none for "Passphrase key" ??

Below is the complete log snippet--
** due to security concerns IPs and crucial details are coded!!

2014-02-14 13:30:13 conn 32 IP-server1 54256 - - - 0 0 0 0 IP-server2 22 "00032: Connection accepted from IP-server1:54256"
2014-02-14 13:30:13 auth 32 - - Server2\User - - 0 0 0 0 - - "00032: Client specified user name User, resolved as Server2\User"
2014-02-14 13:30:13 auth 32 X.X.X.X 54256 server2\User - - 0 0 0 0 - - "00032: none for user Server2\User rejected because it is unavailable"
2014-02-14 13:30:13 auth 32 X.X.X.X 54256 Server2\User - - 0 0 0 0 - - "00032: password for user Server2\User accepted"
2014-02-14 13:30:13 conn 32 X.X.X.X 54256 server2\User - - 0 0 0 0 - - "00032: Session channel open request accepted"
2014-02-14 13:30:13 conn 32 X.X.X.X 54256 server2\User - - 0 0 0 0 - - "00032: Received request to start subsystem sftp (Built-in Subsystem)"

Please help...

ciao
AbhishekJ

[rtb]

Hi AbhishekJ,

Thanks for the question. The error you are seeing is not an error that something has gone wrong. A client requesting the none authentication method is the traditional way to ask the server what authentication methods are available since it is on rare occasion that a server will actually support the none authentication method. When the server receives the request, it will reject it, and respond with the supported authentication methods. The client will then choose the method to try in order of its preference.

Does this help to explain the line in the log file?

[AbhishekJ]

thanks for the answer..

So you means client initially will try to establish connection without authentication which is rejected by server despite the fact that in code we are providing the user/password.

Also is there any way to suppress these message or making to client to go for password authentication on first attempt rather then "none" authentication.


Ciao
AbhishekJ

[rtb]

Hi AbhishekJ,

You are welcome.

So you means client initially will try to establish connection without authentication which is rejected by server despite the fact that in code we are providing the user/password.

You are correct. I don't think I have ever seen a client not do this.

Also is there any way to suppress these message

VShell will not log this information if you disable Authentication logging in the Common / Logging category.

Can you help me understand what problem this is causing?

making to client to go for password authentication on first attempt rather then "none" authentication.

You would have to consult the client vendor on this, or the client documentation.

[rtb]

Hi AbhishekJ,

I just wanted to post a follow-up. I am not recommending that you disable the Authentication logging option. This information is typically desired to see legitimate failures, and possibly brute force attacks.

The none authentication type is not something to be seen as suspicious. Here is a snippet from the protocol definition:

Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be granted access without any authentication, in which case, the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server.

What problem are you trying to solve?

[AbhishekJ]

Thanks for the explanation.

we are using hp-ux provided ssh and i checked the ssh config file in client but could not fine any property to change this behavior...

So to conclude there is no harm with the message and its a default behavior.

Thanks,
AbhishekJ