Currently, when a public key has been added to any user, the remote client should pass the private key to the SSH service in RouterOS, but if it doesn't, the service still asks for the user's password (regardless that it doesn't accept it after all). In my opinion, that behavior should be changed: when a public key is added to any user, the password authentication method in the SSH service should be removed from the list of the allowed SSH authentication methods or at least an option should be included in the interface to manually disable the SSH password authentication completely.

Strange, in my last tests several weeks ago I experienced exactly what you wished and was worried about not being able to login with private key and with password at the same time.

Strange, in my last tests several weeks ago I experienced exactly what you wished and was worried about not being able to login with private key and with password at the same time.

Yes, you are right. But, in my opinion, this is wrong behaviour . +1 for RSA keys and possibility to use keys and passwords at the same time.

Strange, in my last tests several weeks ago I experienced exactly what you wished and was worried about not being able to login with private key and with password at the same time.

Strange, in my last tests several weeks ago I experienced exactly what you wished and was worried about not being able to login with private key and with password at the same time.

Yes, you are right. But, in my opinion, this is wrong behaviour . +1 for RSA keys and possibility to use keys and passwords at the same time.

Guys, read the first post once again and read it carefully this time. I'm not telling that the current behavior should be completely removed, I'm telling that the user should have the choice: to use only the password, to use only the public/private key or to use both. just like in any Linux distro.

current options are:

• use password
• use key-pair
• use both

default is use password - when you set account password in RouterOS you can use that password to log in using that user via any of the services (API, winbox, webfig, telnet, SSH)

use key-pair - only available for ssh login, when key is set for the user password login via SSH is disabled. that is also part of default behaviour
use both - in '/ip ssh' you can allow to use password login if you have set key-pair for the user.

current options are:

• use password
• use key-pair
• use both

default is use password - when you set account password in RouterOS you can use that password to log in using that user via any of the services (API, winbox, webfig, telnet, SSH)

use key-pair - only available for ssh login, when key is set for the user password login via SSH is disabled. that is also part of default behaviour
use both - in '/ip ssh' you can allow to use password login if you have set key-pair for the user.

I presume you're talking about the always-allow-password-login option (set by default to no) for the second method (use key-pair).

Ok, let's assume that a key has been added to the user and that option is set to no (I've never touched it, it's still set to no). Then how would you explain this debug log, taken on one of my computers with the ssh client? I haven't provided the valid key intentionally to see if it works like is should and yet, the SSH service asks for the password not once, but whole three times. Well, why would it ask for a password, if that method (combined with the above option, set to no) is suppose to be disabled?

If you really don't understand what I'm trying to tell you, check here for reference (4. Disabling Authentication by password).

So, what am I experiencing - a feature or a bug?

if your client asks for the password prompt - it will be provided with a password prompt, you cannot log-in even if you provide a correct password. Password is never checked as it is not valid auth mechanism with the default configuration.

Well, that's exactly the problem: the normal SSH service/server behavior in such case (disabled password authentication) is to drop the connection immediately, not to prompt for a password. As I said, look at the manual, mentioned in my previous post and especially the example. I have no idea what's the SSH server software you have added to RouterOS, but for me the current SSH service behavior with disabled password authentication is not right, the behavior I've mentioned above is the right one in such cases, at least that's the way it works in all major SSH server software, incl. Dropbear, OpenSSH, TinySSH etc.

if your client asks for the password prompt - it will be provided with a password prompt, you cannot log-in even if you provide a correct password. Password is never checked as it is not valid auth mechanism with the default configuration.

Mmm... No. Guess again! It's up to the SSH server/service (and its settings) to provide or not the password prompt.