Passwordless ssh login

vladoboss · Mon Feb 01, 2010 12:14 am

Is there any way to configure the Mikrotik router to accept login only with ssh key, no passwords? In Linux this option is available in /etc/ssh/sshd_config and you edit the following line like this: PasswordAuthentication no
This is the most secure way of using ssh, as brute force password attacks are useless, and there is no need to configure firewall rules for permitted source address.

DieselPower · Wed Feb 03, 2010 12:34 am

I would also like to know if this is possible.

changeip · Wed Feb 03, 2010 1:16 am

You can use certificates / ssh keys without passwords, but you cannot completely disable password authentication on the actual ssh service in RouterOS.

markus · Tue Feb 01, 2011 8:30 pm

Hi, I'm reviving this thread to ask, that why is this not possible? I can see, that using keys to login is simpler because you have to type a password once on your client machine. But to give it more security, then you should use a password longer than the key is, to actually use the security the key gives?

vladoboss · Thu Feb 03, 2011 12:35 pm

In new beta version this feature is enabled. For users that have key associated, password login is disabled.

philippetev · Sun Oct 12, 2014 2:54 pm

Sorry to revive the thread, but on my RB951G-2HnD with RouterOS 6.20 I've still got the password prompt even after I've installed the SSH keys. What am I doing wrong?

janisk · Mon Oct 13, 2014 3:09 pm

upload public part of key, import it for particular user you are going to use it with '/user ssh-keys'

when logging in, point your ssh client to the private key, or place it in default location where client can find it.

philippetev · Mon Oct 13, 2014 4:13 pm

upload public part of key, import it for particular user you are going to use it with '/user ssh-keys'

when logging in, point your ssh client to the private key, or place it in default location where client can find it.

Yeah, I'm fully aware how the public/private key handshake works, but that's not my problem. I want to disable completely the SSH password authentication, just like in Linux (when it's disabled, there is no password prompt and the remote client is being disconnected immediately, if it haven't provided the key). In RouterOS, the password authentication is disabled, when a key is imported to any user, but even so, I still get the password prompt. Is there a way to disable that prompt?

Edit: here the real example, the ssh client in debug mode. I haven't passed the private key to the client intentionally:

philip@ProBook-4340s:~$ ssh -vvv admin@192.168.0.1
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22.
debug1: Connection established.
debug1: identity file /Users/philip/.ssh/id_rsa type -1
debug1: identity file /Users/philip/.ssh/id_rsa-cert type -1
debug1: identity file /Users/philip/.ssh/id_dsa type -1
debug1: identity file /Users/philip/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version ROSSSH
debug1: no match: ROSSSH
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.0.1" from file "/Users/philip/.ssh/known_hosts"
debug3: load_hostkeys: found key type DSA in file /Users/philip/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes192-cbc,aes128-cbc,aes256-cbc,blowfish-cbc,3des-cbc,none
debug2: kex_parse_kexinit: aes192-cbc,aes128-cbc,aes256-cbc,blowfish-cbc,3des-cbc,none
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 117/256
debug2: bits set: 545/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: DSA 7f:8b:5d:4f:e2:70:a5:2e:5a:6d:ba:9b:46:5c:9f:2f
debug3: load_hostkeys: loading entries for host "192.168.0.1" from file "/Users/philip/.ssh/known_hosts"
debug3: load_hostkeys: found key type DSA in file /Users/philip/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.0.1' is known and matches the DSA host key.
debug1: Found key in /Users/philip/.ssh/known_hosts:6
debug2: bits set: 499/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/philip/MyKey09052012_private.openssh (0x7fb02ad00f10),
debug2: key: /Users/philip/.ssh/id_rsa (0x0),
debug2: key: /Users/philip/.ssh/id_dsa (0x0),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/philip/MyKey09052012_private.openssh
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/philip/.ssh/id_rsa
debug3: no such identity: /Users/philip/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /Users/philip/.ssh/id_dsa
debug3: no such identity: /Users/philip/.ssh/id_dsa: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
admin@192.168.0.1's password:
debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: password
debug3: start over, passed a different list password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
Permission denied, please try again.
admin@192.168.0.1's password:
debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: password
Permission denied, please try again.
admin@192.168.0.1's password:
debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (password).
philip@ProBook-4340s:~$

Well, if the password authorization really should be disabled, if a public DSA key has been added to any user, why the server still asks for password, when the private key hasn't been passed to the server, and when I enter it, it doesn't even accept it.
I smell bad SSH server implementation or a bug or both here.

P.S. Ignore the lines, containig MyKey09052012_private.openssh, that's another (RSA) key for another location.

AnRkey · Wed Apr 01, 2015 3:14 pm

@philippetev I know I'm a bit late with this answer, but for everyone else's benefit too, this is what you're looking for: http://wiki.mikrotik.com/wiki/Use_SSH_t ... key_login)

Have just tested it from Debian to my test MT and it's working. I'm going to automate some stuff via SSH with python this way.

brunoeco · Tue Aug 22, 2017 8:19 pm

So, any updates to this bug ?

I'm on latest v6.41rc16 and it still asks for password if no public key is sent.

How to completely disable password for SSH login ?

This is the problem

16:59:56 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:00 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:03 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:07 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:11 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:14 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:18 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:21 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:25 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:28 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:32 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:35 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:39 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:43 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:46 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:00:50 system,error,critical login failure for user fss_sait from 120.237.101.134 via ssh 
17:00:53 system,error,critical login failure for user fazan from 120.237.101.134 via ssh 
17:00:57 system,error,critical login failure for user fazan from 120.237.101.134 via ssh 
17:01:00 system,error,critical login failure for user butter from 120.237.101.134 via ssh 
17:01:04 system,error,critical login failure for user nologin from 120.237.101.134 via ssh 
17:01:08 system,error,critical login failure for user nologin from 120.237.101.134 via ssh 
17:01:11 system,error,critical login failure for user tamadou from 120.237.101.134 via ssh 
17:01:15 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:18 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:22 system,error,critical login failure for user lijia from 120.237.101.134 via ssh 
17:01:25 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:29 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:33 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:37 system,error,critical login failure for user informix from 120.237.101.134 via ssh 
17:01:41 system,error,critical login failure for user informix from 120.237.101.134 via ssh 
17:01:45 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:48 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:53 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:01:57 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:01 system,error,critical login failure for user informix from 120.237.101.134 via ssh 
17:02:04 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:08 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:11 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:15 system,error,critical login failure for user oracle from 120.237.101.134 via ssh 
17:02:19 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:23 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:27 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:30 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:34 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:37 system,error,critical login failure for user root from 120.237.101.134 via ssh 
17:02:41 system,error,critical login failure for user root from 120.237.101.134 via ssh

Sob · Wed Aug 23, 2017 2:40 am

Nope, no change since last time, even with last RC version, RouterOS SSH always offers password authentication to clients. I don't see any option to disable it globally. Such options would be nice.

And it still also asks for users who have assigned public key and thus password login disabled. If you don't send a key, it asks for password anyway. It got me a little worried at first, but fortunately it can't succeed when you have always-allow-password-login=no (default). Such attemp is not even logged (that's ok, but asking for password is completely useless in this case and should not be done).

AnRkey · Wed Aug 23, 2017 3:48 pm

This isn't a bug. Even on a Linux server the result is the same. You set SSHd to reject root logins with passwords but the prompt is still there for accounts that may login with passwords. Its no less secure this way. You can set the SSH service to only permit logins from certain subnets by going to IP > Services and setting the service to only permit 192.168.0.0/16 for example. That will make it behave more like what you expect.

brunoeco · Wed Aug 23, 2017 6:06 pm

This isn't a bug. Even on a Linux server the result is the same. You set SSHd to reject root logins with passwords but the prompt is still there for accounts that may login with passwords. Its no less secure this way. You can set the SSH service to only permit logins from certain subnets by going to IP > Services and setting the service to only permit 192.168.0.0/16 for example. That will make it behave more like what you expect.

It's ok if there were another password enabled accounts, but that's not the case...

This is the result i expected

ssh ubuntu@myserver.com
Warning: Permanently added 'myserver.com,34.207.xxx.xxx' (ECDSA) to the list of known hosts.
Permission denied (publickey).

It doesn't even ask for password.

Sob · Thu Aug 24, 2017 4:23 am

Well, there are two cases:

1) When you have only accounts with keys, password authentication is still offered for unknown ones (for existing ones too, but that case 2). That's not a bug. It would be nice if you could disable it, but it simply isn't implemented (yet).

2) When you have an account with key and always-allow-password-login=no, so password authentication is not possible for it, it's still offered. And that I'd say is bug. Harmless one, because password is not accepted, but still bug.

tuxb0xrf · Wed Mar 14, 2018 10:25 pm

This longtime gnu/linux, openwrt and ssh user agrees wwith guru Sob on this one. Definitely a bug.

This is why opensource software is better (ie openwrt). MikroTik and openwrt should get together to rule the router firmware world once and for all,
Not gonna happen though due to ego and pride.
This stagnates technology evolution. Someine should reverse engineer all propietary MT stuff like nv2 and nnstream and do something better on OpenWRT Linux.

I'm trying to setup ssh forwarding on my mikrotik
RBSXTG-5HPnD-SAr2 right now. I can't find the setting un the webui to disable password nor the"always-allow-password-login=no" mentioned here or in the tutorial. So I'm looking on command line.
It's the wifi tower's network gateway with it's wireles WAN connected to an Ubi NBM5. I had to activate watchdog because it would disconnect suddenly sometimes. That nb is connected to the isp router.

I wish I could use PPPoE over the wireless bridge, discover the PPPoE packet through the nb, from my isp router (after putting it in transparent bridge mode) in order to eliminate the double NAT and assign public IP to my Mikrotik gateway. Is it possible?
I could put my dual core, 512MB RAM openwrt router as my edge router which is the ideal way or lay 3280 meters of heavy-duty phone line to my tower and put my isp modem there.

For ssh'ing from WAN, I always disable password logins and change the default port to a vague higher one as well as change the default root user from root to a vague hard-to-bruteforce one and disable root logins altogether. You can also use a port-knocker (Hint: routeros feature request)

I also disable webif logins. I wonder if it's safe to use https logins from the Internet.

hsd75 · Sun Jul 29, 2018 11:59 pm

Hi all,

Whenever I tried to login via the keys, he would ask me for the password.
I generated a new RSA key and not DSA and it works.
# ssh-keygen -t rsa

tm3558 · Fri Sep 28, 2018 2:01 am

I generated a new RSA key and not DSA and it works.
# ssh-keygen -t rsa

Thank you!
I also tried to ssh commands with this script 'github com /gitpel /letsencrypt-routeros', for installing/updating certificates for www-ssl service, SSTP.
With DSA key router asked for a password and after I typed the password access was denied.
With RSA key this script works OK.

itcoop · Thu Nov 01, 2018 8:48 pm

I have password-less ssh working for quite some time now

I discovered today that the user linked to the key will authenticate with no password if management transports other than ssh are allowed.

Test:

/user add group=full name=keytestuser
/user ssh-keys import public-key-file=key.pub user=keytestuser
/ip service print
Flags: X - disabled, I - invalid 
 #   NAME      PORT ADDRESS                                        CERTIFICATE   
 0 XI telnet      23
 1 XI ftp         21
 2 XI www         80
 3   ssh         22 10.0.0.0/8                                    
 4 XI www-ssl    443                                                none          
 5 XI api       8728
 6   winbox    8291 10.0.0.0/8                                    
 7 XI api-ssl   8729                                                none

Logging in using ssh will work fine with key; without key, password will not matter (or even show up in the log).
Logging in using winbox will work with username and NO PASSWORD if one is not set.

Note: Adding a password to keytestuser will not require ssh password authentication when a key is used.

gregsowell · Mon Mar 09, 2020 10:21 pm

Thanks for the tips guys, it looks like creating the key type as RSA works just fine for me.

Passwordless ssh login

Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Passwordless ssh login

Re: Password-less ssh login

Re: Passwordless ssh login

Who is online