After adding ssh-keys for user, this user is no more allowed to login via ssh by password. Tested from another RouterOS (simply ask for password again) and from Linux box (“Permission denied, please try again.”). Confirmed in v5.4 too.
Another type of login looks working (console and mac-telnet tested).
Don’t think it is so bad behaviour, but if this is “feature”, users should be noticed somewhere (manual ?) and should have control over it.
It is confirmed as a “feature”.
it’s a BUG!
all openssh system handle it correctly.
What is considered “correct handling”?
And what exactly that “feature” is doing?
making login via ssh worst and harder than any other openssh system ?
user should be able to configure whatever he wants only key or key/password logins - the default should be both
“correct handling” - means default behavior implemented in any other openssh system and considered by users as correct
I’m using 5.6 and noticed similar ssh problems.
Setting up a rb750GL which comes with 5.2ish, I can not use SCP to update the firmware. Have to use FTP. This is regardless of wheter admin has a password assigned yet.
Updated to 5.6 and see the SSH problems discussed here. I don’t use the older version, so I can’t know for 5.5 or 5.2.
I also put it on a 433ah and see similar.
ssh with keys works and disables ssh access from that host. This isn’t a feature. It should only disable access from a user at that host if it were a feature. All users at the remote host can’t get in with a password after setting up a key on the MT. keys are for individual accounts on a host, not for the whole host and not for other hosts connecting to admin.
Here’s an example where I setup a key on the MT to accept passwordless admin connections from my jp@huehuetenango account. After setting this up, I can not ssh in as admin from anywhere except that username on that host. Other accounts on the same machine also can not connect. Telnet, winbox, ftp, are not affected.
ptyler@huehuetenango:~> ssh admin@69.39.112.241
admin@69.39.112.241's password:
Permission denied, please try again.
admin@69.39.112.241's password:
Permission denied, please try again.
admin@69.39.112.241's password:
Permission denied (password).
ptyler@huehuetenango:~> exit
logout
huehuetenango:~ # exit
logout
jp@huehuetenango:~> ssh admin@69.39.112.241
MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK
MikroTik RouterOS 5.6 (c) 1999-2011 http://www.mikrotik.com/
Property of Midcoast Internet Solutions 2075948277 or www.midcoast.com
Unauthorized access will be prosecuted.
All Access is logged.
[admin@squirrelap] > quit
interrupted
Connection to 69.39.112.241 closed.
jp@huehuetenango:~> exit
logout
Connection to 10.0.0.7 closed.
jp@travelmug:~> ssh admin@69.39.112.241
admin@69.39.112.241's password:
Permission denied, please try again.
admin@69.39.112.241's password:
Permission denied, please try again.
admin@69.39.112.241's password:
Permission denied (password).
jp@travelmug:~>
It is also worth mentioning as others have that using keys should not prevent password access; thats the way the old 4.x and 3.x routerOS works.
I use keys for automated access (backups locking and unlocking customers, things you can’t do with snmp, etc…) and password access ssh is used for interactive staff use.
Also a bug related to this is that it does not log these failed ssh access attempts. This last problem inclines my mind to think it’s not a feature.
Is there a way to disable this feature?
Nope.
change was made in 5.0rc2. Where changelog message explained - if ssh-key is set, logins using password are disabled. Feature is there, that if you feel like having keys for router login less secure option is not used. That is security measure.
We are considering different options for this, but currently it will stay as it is.
It is already added in the manual as a warning
http://wiki.mikrotik.com/wiki/Manual:Router_AAA#SSH_Keys
I second that as a feature request.
yes we are considering that and assessing consequences. At the moment you can add several certificates for each account, aslo, it is possible to add private key to log through ssh from one router to another with the key.
IMHO - password authentication alone is bad thing, should use key with authorisation.
It’s kinda foolish to block password ssh login (when keys are used), but still allow telnet and ftp access out-of-the-box if better-than-password security is indeed the goal. Since I can’t scp a file, I’ll ftp it instead.
It’s a worthwhile option, but shouldn’t replace the way it’s been done.
I use the firewall to block ssh, telnet, and ftp from everywhere but my own networks. It’s only a couple of lines to setup.
I agree but I have over 30 locations with Mikrotik routers and if I happen to somehow be without my laptop or home workstation, I don’t have my DSA key handy to ssh in to fix problems. It limits my travel 
Hi,
I can’t understand why this limitation is included. I agree to have available the option to “disable passwords when ssh-keys”, but as an option.
So, please can you add the option for enable/disable this functionality?
What RouterOS version are you using?
In contemporary ones
/ip ssh set always-allow-password-login=yes
Hi Teamer,
Thanks a lot! This is that I need… and referenced at http://wiki.mikrotik.com/wiki/Manual:IP/SSH
The problem is that isn’t in Winbox, and it’s poorly described.
Regards.
I find this behavior extremely strange. You should have some on/off switch for this feature you call it, or at least comply with the SSH protocol and not offering password authentication it this case.
Here is the output of debug openssh client session:
debug1: Authentications that can continue: publickey,password
Regards.
This “feature” does not really make sense.
At least webfig works with the password.
The workaround is to have an ssh user with keys set, and another ssh user with a password and no keys to be used with ssh.
.. Weird …