Has anyone had any luck with SSH in V7.3 or V7.4?
I’ve not had any luck with /system ssh address= user=
I watch the logs on my remote SSH server and nothing even tries to connect.
Works great on V6.49.6
I just tried from 7.4 to a machine on the same subnet and it worked fine, even prompted for, and accepted, the totp code the SSH server wanted. Possibly not very helpful in resolving your issue, but yes, it works for me.
Works from RB760iGS with v7.3.1
Are you able to ping the device you are attempting to ssh to? More importantly, can you connect to tcp port 22 on the system you are attempting to connect to?
yes, can ping the server.
and can SSH from another Tik in the office. But its on V6.
Which MikroTik device is it? (device that works with v6 but not v7)
Do you have strong-crypto=yes enabled on the router? I’m not certain that this affects the SSH client as well, but let’s get that established, just in case.
RouterOS 7.3 removes DSA authentication. If your remote server requires it, there’s your problem. This is a long-obsolete algorithm.
As for the advice about ECDSA and ED25519 above, that would be nice, but RouterOS doesn’t support that for SSH yet. This limits you to RSA variants.
If the server is OpenSSH, would you mind posting its configuration file? (Typically /etc/ssh/sshd_config) Feel free to sanitize it, though in all likelihood it will be an OS default file, so not secret.
Here is the sshd_config file. Keep in mind this works perfectly with V6 boxes.
I generated the key files with -PEM option
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# This system is following system-wide crypto policy. The changes to
# crypto properties (Ciphers, MACs, ...) will not have any effect here.
# They will be overridden by command-line options passed to the server
# on command line.
# Please, check manual pages for update-crypto-policies(8) and sshd_config(5).
# Logging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel INFO
#LogLevel DEBUG3
# Authentication:
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 10
#MaxSessions 10
PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedKeysFile .ssh/authorized_keys/rd_rsa
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication yes
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes
# GSSAPI options
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Fedora and may cause several
# problems.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
# It is recommended to use pam_motd in /etc/pam.d/sshd instead of PrintMotd,
# as it is more configurable and versatile than the built-in version.
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
#Subsystem sftp internal-sftp
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
#Match Group sftpusers
#ChrootDirectory /data/%u
#ForceCommand internal-sftp
No, turned off strong-crypto=yes.
They need to contain an RSA key pair, not DSA, and not anything involving EC crypto.
ok. I moved the MT to a different network segment and its at least now talking to the server and I can login using password.
Now I have a V6 and V7 side by side.
I can login into the server with the V6 using the cert but not the V7.
In the V6 when I goto /user ssh-keys private import. I have to load both the Public and Private key files along with the Passphrase used when creating the key files on the remote server.
that works just fine.
In the V7 there is only a private-key-file option. And I cannot import the id_rsa private key due to an error. “Couldn’t perform action-unable to load key file (wrong format or bad passphrase)”
I can import the public key just fine but that does not help. Still being prompted for password when I SSH to server.
So the Keyfile mechanism is problematic.
Check your client’s ssh configuration or try with some other client without any configuration. One of the parameter which may prevent you to log in: PubkeyAcceptedKeyTypes +ssh-dss
The client is the MT router(V6 or V7), the server is a RockyLinux server in the cloud.
No one else having this issue?
The ssh-exe command requires key file loads to the user on the MT.
/system ssh-exe address=[:resolve $Servername] user=$Username command=“”
ssh server in ROS is known not to support newer key exchange algirithms, key types and encryption algorithms. Newer OS variants (e.g. “cutting edge” linux distributions) obsoleted older algorithms and key types and it’s now necessary to explicitly enable those if modern ssh client is used to connect to RIS device.
I’ve no reason not to believe that ssh servers on modern OS variants are configured not to accept connections from clients using obsolete algorithms and key types … and ssh client in ROS might fall in that category.
But I’m not using the SSH server in RouterOS.
I’m just using the client connecting to an external server.
Works great in V6.
Something is wrong with the key imports on V7. Or the key requirements have changed and its not documented anywhere.
The principle @mkx laid out applies inversely as well: every SSH server — not just RouterOS’s — is allowed to say which crypto it’s willing to support, and newer implementations tend to drop older crypto. SSH login involves a set-arithmetic negotiation: take the overlapping subset of auth methods supported by both sides, then iterate over them in some predefined order, presumably from better to worse, until something works.
If RouterOS’s SSH implementation had the equivalent of OpenSSH’s -vvv flag, you could see this happening in realtime.
You’ll be happy to know that there is a compatible mutual subset of auth methods that does work between RouterOS 7.4 as a client and CentOS Stream 9 as the server. (Close enough to Rocky 9 as to not matter.) The only surprise to me was the ongoing requirement for PEM format keys. (Bleah!)
- Run “ssh-keygen -m PEM -t rsa -f ~/.ssh/id_myswitch” on the EL9 box. Doing it here ensures its definition of “RSA” matches what it’s willing to accept. Don’t apply a passphrase; that will break the purpose behind ssh-exec.
- Add the public half to that host’s authorized key file: “cat ~/.ssh/id_myswitch.pub >> ~/.ssh/authorized_keys”
- Copy both halves to the switch: “scp ~/.ssh/id_myswitch* admin@myswitch:”
- Import them for a given user on the switch: “/user/ssh-keys/private/import private-key-file=id_myswitch user=admin” When it prompts for a passphrase, hit Enter.
If you did this dance properly, “/system/ssh*” will use the key when logging into that box. It does here.
If MikroTik’s docs people are reading this, they’re free to steal the text. Also, you’re still documenting a “public-key-file=” parameter that no longer exists. Apparently it infers the “.pub” half now.
Yeah, the keys I’m using with v6 are generated with -m PEM and are rsa
But I cannot import the private key in the V7 unit. get an error “Couldn’t perform action - unable to load key file (wrong format or bad passphrase)”
This is what the log looks like on the Mikrotik side
Jul/23/2022 16:40:21 ssh,debug transport state: 0 → 1
Jul/23/2022 16:40:21 ssh,debug transport state: 1 → 2
Jul/23/2022 16:40:21 ssh,debug client version: SSH-2.0-OpenSSH_8.0
Jul/23/2022 16:40:21 ssh,debug transport state: 2 → 3
Jul/23/2022 16:40:22 ssh,debug packet process: kex init
Jul/23/2022 16:40:22 ssh,debug host key algo: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
Jul/23/2022 16:40:22 ssh,debug kex algo: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
Jul/23/2022 16:40:22 ssh,debug enc algo CS: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
Jul/23/2022 16:40:22 ssh,debug mac algo CS: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
Jul/23/2022 16:40:22 ssh,debug comp algo CS: none,zlib@openssh.com
Jul/23/2022 16:40:22 ssh,debug packet follows: 0
Jul/23/2022 16:40:22 ssh,debug agreed on: diffie-hellman-group-exchange-sha256,ssh-rsa,aes128-ctr,aes128-ctr,hmac-sha1,hmac-sha1,none,none,
Jul/23/2022 16:40:22 ssh,debug packet process: hexdh gex group
Jul/23/2022 16:40:22 ssh,debug packet process: hex dh gex reply
Jul/23/2022 16:40:22 ssh,debug pki algorithm: ssh-rsa
Jul/23/2022 16:40:22 ssh,debug packet process: kex new keys
Jul/23/2022 16:40:22 ssh,debug transport state: 3 → 4
Jul/23/2022 16:40:22 ssh,debug in enc key: 3315e19e 737557ba 93555f7f 53389380
Jul/23/2022 16:40:22 ssh,debug in enc iv: b7173302 b944643a eb4dedd7 480e84d9
Jul/23/2022 16:40:22 ssh,debug out enc key: 0af6abac 8fa8b6fe 2b3ad646 5b191bec
Jul/23/2022 16:40:22 ssh,debug out enc iv: 87e23bad 36f7797d bba6b3a6 4abe5cf0
Jul/23/2022 16:40:22 ssh,debug in mac key: 66301a48 ee52b009 783bce8d 89f9a150 88d433b6
Jul/23/2022 16:40:22 ssh,debug out mac key: e1266f22 772b33f2 edd4fedb 735f7fd7 7fbb21ed
Jul/23/2022 16:40:22 ssh,debug packet process: ext info
Jul/23/2022 16:40:22 ssh,debug ext info: server-sig-algs
Jul/23/2022 16:40:22 ssh,debug packet process: service accept
Jul/23/2022 16:40:22 ssh,debug requesting auth methods
Jul/23/2022 16:40:25 ssh,debug packet process: userauth failure
Jul/23/2022 16:40:25 ssh,debug available auth methods: publickey,password
Jul/23/2022 16:40:25 ssh,debug selected auth: publickey
Jul/23/2022 16:40:25 ssh,debug selected auth: password
I always get prompted for a password if I run interactive. Which means that /system ssh-exec fill fail and time out.
Are you still trying to reuse the old v6 keys?
I repeat: generate new ones on the Rocky Linux SSH server, and use those instead.
You can have as many SSH keys as you want, on both the client and the server. Nothing says the keys for your v7 boxes have to be the same as your v6 keys.
ok. I regenerated a set of keys for V7 using ssh-keygen -m PEM -t rsa -f ~/.ssh/v7_id_rsa
same problem, cannot import the private key using
/user ssh-keys private import private-key-file= user=
can also import the pub key just fine using
/user ssh-keys import public-key-file= user=
I tried importing the pub key only. no help.
and then the pub key into the private key location. It imports but does not fix the problem.
Its also very annoying how the key file gets deleted after its imported. (new feature in v7 apparently)
Same happens in 6.49.6 … probably happened earlier as well (I’m not sure about since when though). I guess this is considered a security feature - private key should really be kept private, not laying readable on some God forsaken device.