Access RouterOS via SSH using key

RouterOS General
1

Hello, I’m trying to configure access via ssh key, but even after configuration the password is requested.

RouterOS Version: 6.49.10

Steps taken to generate and copy the key:

1. Generate key in Linux:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/mikrotik_rsa -N “”

2. Copy key to Mikrotik:

scp ~/.ssh/mikrotik_rsa.pub admin@ip:/


3. Access the router and set the key:

ssh admin@ip

/user ssh-keys import public-key-file=mikrotik_rsa.pub user=backup

4. Access:

ssh backup@ip

or

ssh -i ~/.ssh/mikrotik_rsa backup@ip

In this step the password is requested. I want ssh key access to perform the backup using a shell script.

what am I doing wrong ? I’ve looked at other posts similar to my question, but I haven’t been able to solve the problem.

2 
ssh -vvv -i ~/.ssh/mikrotik_rsa backup@ip

output please

3

are you using an x86 router ?

4

Try setting “PubkeyAcceptedAlgorithms +ssh-rsa” in ~/.ssh/config for your routeros hosts.

5

My RB is model RB3011UiAS. The architecture is ARM.

6

By following the suggested configuration, I was able to access the RB using a key. Thanks.

I tested on RB3011UiAS and VM Cloud Hosted Router. It worked on both.

Can you explain why I have to do this configuration? Is this configuration safe?

7

See https://ikarus.sg/rsa-is-not-dead/

8

Version de Openssh in Linux: OpenSSH_8.9p1 Ubuntu-3ubuntu0.4, OpenSSL 3.0.2 15 Mar 2022

I noticed that the generated public key has a signature: ssh-rsa.

Output command:

ssh -vvv -i ~/.ssh/mikrotik_rsa backup@ip

OpenSSH_8.9p1 Ubuntu-3ubuntu0.4, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname ip is address
debug3: expanded UserKnownHostsFile ‘~/.ssh/known_hosts’ → ‘/home/user/.ssh/known_hosts’
debug3: expanded UserKnownHostsFile ‘~/.ssh/known_hosts2’ → ‘/home/user/.ssh/known_hosts2’
debug3: ssh_connect_direct: entering
debug1: Connecting to ip [ip] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/user/.ssh/mikrotik_rsa type 0
debug1: identity file /home/user/.ssh/mikrotik_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.4
debug1: Remote protocol version 2.0, remote software version ROSSSH
debug1: compat_banner: no match: ROSSSH
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to ip:22 as ‘backup’
debug3: record_hostkey: found key type RSA in file /home/user/.ssh/known_hosts:23
debug3: load_hostkeys_file: loaded 1 keys from ip
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: prefer hostkeyalgs: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-dss,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc
debug2: MACs ctos: hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha1,hmac-md5
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: rsa-sha2-256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_DH_GEX_GROUP received
debug2: bits set: 1014/2048
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: receive packet: type 33
debug1: SSH2_MSG_KEX_DH_GEX_REPLY received
debug1: Server host key: ssh-rsa SHA256:iuGgKSeWyyMeWmX0CQgKQQ19tfchn4NqgIbycOmFr3A
debug3: record_hostkey: found key type RSA in file /home/user/.ssh/known_hosts:23
debug3: load_hostkeys_file: loaded 1 keys from ip
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host ‘ip’ is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:23
debug2: bits set: 1047/2048
debug3: send packet: type 21
debug2: ssh_set_newkeys: mode 1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: ssh_set_newkeys: mode 0
debug1: rekey in after 4294967296 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /home/user/.ssh/mikrotik_rsa RSA SHA256:g2WJlCjuVgLDg7Hr7fE+bAEh68b+lb74MIDThF0TM7A explicit agent
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,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 public key: /home/user/.ssh/mikrotik_rsa RSA SHA256:g2WJlCjuVgLDg7Hr7fE+bAEh68b+lb74MIDThF0TM7A explicit agent
debug1: send_pubkey_test: no mutual signature algorithm
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
backup@ip’s password:

9

In this link (https://security.stackexchange.com/questions/255074/why-are-rsa-sha2-512-and-rsa-sha2-256-supported-but-not-reported-by-ssh-q-key) I found the following explanation:

“For most key types in SSH, there is but one signature type: ecdsa-sha2-nistp384 will always use SHA-384, for example. However, an RSA key, which has type ssh-rsa, can be used with one of three signature algorithms: SHA-1, which confusingly is also called ssh-rsa; SHA-256 (rsa-sha2-256); or SHA-512 (rsa-sha2-512). The key type does not change, but the signature type does.”

On Linux, when typing the command "ssh -Q sig", I have the signatures listed below:

ssh-ed25519
sk-ssh-ed25519@openssh.com
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ecdsa-sha2-nistp256@openssh.com
webauthn-sk-ecdsa-sha2-nistp256@openssh.com

What version of Mikrotik’s SSH is causing the problem then?

10

how about routeros X86 as client when execute this command :
/system ssh address=ip-CHR port=22 user=admin

it always show password prompt, but this command no problem when i execute on ccr1036

11

It’s related to SSH client version, your version (OpenSSH_8.9p1) is higher than version 8.8 when ssh-rsa is deprecated, read article from link in my previous post, if you don’t understand all, go to Summary of the issue part, it describes your problem.

P.S.
Did you try to generate key with rsa-sha2-256 or rsa-sha2-512 and see if are working on your ROS version (I don’t have ROS 6.x device to check)? These algorithms are not deprecated and you don’t need to force them in ssh configuration or command line argument option.

12

Now I understand that the SSH client version is newer than the Mikrotik SSH server. But forcing communication using “PubkeyAcceptedKeyTypes +ssh-rsa” in the config file doesn’t seem like a good idea. Later I tried using ECDSA and ED25519 keys. However, these key types are not compatible with RouterOS.

I also tried generating an rsa-sha2-512 key (ssh-keygen -t rsa-sha2-512 -b 4096 -f ~/.ssh/mikrotik_rsa -N “”). The key was generated without any problems. However, it didn’t work either. To work you still need to define “PubkeyAcceptedKeyTypes +ssh-rsa”.

13

Since ROS v7.12, ssh keys of type ed25519 are fine.

Recent OpenSSH versions deprecated whole RSA algorithm family. And IMO enabling it is not necessarily a bad thing (if it was such a bad thing, it wouldn’t be supported any more) if one uses it only to connect specific remote hosts (i.e. use actual host name in user’s ssh client config file, not a wildcard or setting in system-wide config file).

BTW, setting “PubkeyAcceptedKeyTypes **+**ssh-rsa” doesn’t force ssh client to use this key type, it only adds it to list of supported/allowed key types (setting without + sign would actually require use of RSA keys). If ssh server doesn’t accept RSA key, it won’t be used, other types will be tried.

14

The issue lies in step 3, where you’re importing the public key using the ‘backup’ user. The public key should be imported for the ‘admin’ user, as that’s the user you’re trying to authenticate with the key. Import the public key using the following command:

/user ssh-keys import public-key-file=mikrotik_rsa.pub user=admin
After this, you should be able to access the router using SSH key authentication without being prompted for a password:

ssh backup@ip

15

I tested a CHR VM with RouterOS 7.12.1. I was able to access using the generated RSA key. There was no need to set “PubkeyAcceptedKeyTypes +ssh-rsa”. The problem is with version 6 of RouterOS. In version 7, the ssh server has already been updated.