100

I tried to connect to ssh server in M1 macOS terminal like this

ssh -i {myKeyFilePath/myKeyFile.pem} user@host

but it returns

sign_and_send_pubkey: no mutual signature supported
user@host: Permission denied (publickey).

I didn't modify any ssh settings, and the file permissions of {myKeyFile.pem} is 400. Also I can connect ssh server well by IntelliJ remote hosts, but when I tried this in terminal, it goes wrong.

Patrick Yoder
  • 1,065
  • 4
  • 14
  • 19
박진근
  • 1,003
  • 2
  • 6
  • 6

6 Answers6

187

When I updated my Mac system, all the ssh server can't ssh with the private key, you can add the 3 lines below in the beginning of your /etc/.ssh/config. But the best solution is create a new private key and upload the public key to each server one by one, because when you got this error, means your private key is deprecated to use.

# vim ~/.ssh/config, add the lines at the beginning
Host *
    PubkeyAcceptedKeyTypes=+ssh-rsa
    HostKeyAlgorithms=+ssh-rsa
shoaly
  • 2,130
  • 2
  • 11
  • 12
  • 4
    There is a good security reason that `ssh-rsa` was disabled. Choosing this method is not recommended and should be the **last resort**. – John Hanley Nov 05 '22 at 03:09
  • 6
    @JohnHanley I just spent 3 hours trying to figure out what is going on after update to Mac Ventura, this answer helped. What is the good reasons for the fact that it was disabled? thank you – Eugene Nov 07 '22 at 14:42
  • 7
    This worked for us after updating to macOS Ventura. Thanks! `PubkeyAcceptedKeyTypes=+ssh-rsa` by itself did NOT do the trick. The `HostKeyAlgorithms` was also necessary. – i-know-nothing Nov 07 '22 at 19:17
  • 1
    @Eugene - The reason is that SHA1 has been considered unsafe since 2016 and should not be used. https://www.computerworld.com/article/3173616/the-sha1-hash-function-is-now-completely-unsafe.html – John Hanley Nov 07 '22 at 19:31
  • 1
    It work on Mac Ventura! – Bom Wu Jan 09 '23 at 03:06
  • 1
    I'm pretty sure the config path is `/etc/ssh/config`, not `/etc/.ssh/config`. – Daniel Griscom Jan 18 '23 at 20:36
  • Looks like we all run into this issue after upgrade macOS to **Ventura**. Plus what @JohnHanley said, I guess **Ventura** has disabled the `ssh-rsa` by default. That's why we can't ssh to the most servers we were able to ssh to. Another fun fact is `PubkeyAcceptedKeyTypes` now is an alias of `PubkeyAcceptedAlgorithms`, I can't even find the former one in the man page. – Bruce Mar 08 '23 at 02:02
  • Thank you man! You saved my nerves (what was left of them). – FiftiN Jul 09 '23 at 15:40
  • 1
    Check if your server ssh version is old. My client ssh was new - 9.0 with the MacOS Ventura upgrade. Try running `ssh -V` on the server. Signature type `ssh-rsa` (sha1) has been non-supported since OpenSSH 8.8 and is replaced with `rsa-sha2-256` or `rsa-sha2-512` (added in OpenSSH 7.2 in 2016). So until the server is upgraded, the client will need the deprecated `ssh-rsa` flagged as permitted using PubkeyAcceptedKeyTypes. Sources: https://superuser.com/questions/1734086/how-to-ssh-from-macos-terminal-to-ubuntu-22-04-no-matching-host-key-type-found https://www.openssh.com/txt/release-7.2 – Curtis Yallop Jul 10 '23 at 20:47
  • Instead of * you could specify the host by IP address or domain name of the server you want to connect to in order to restrict it. – Klemens Zleptnig Sep 01 '23 at 09:08
43

Most likely your SSH client is using ssh-rsa (RSA+SHA1) and your server has that signature algorithm disabled. SHA-1 is vulnerable and OpenSSH disabled that signature algorithm in version 8.8 (2021-09-26).

The replacement for ssh-rsa is rsa-sha2-256 and rsa-sha2-512.

Try this command:

ssh -o PubkeyAcceptedKeyTypes=rsa-sha2-256 -i {myKeyFilePath/myKeyFile.pem} user@host

If that command fails with an error regarding an unsupported key exchange, then your SSH client is probably ancient.

Use one of the following solutions:

  • update the SSH client (usually a good idea)
  • use a different SSH Key Type such as Ed25519 (recommended)
  • enable rsa-sha in the SSH server (not recommended)

Edit:

If that works, you can permanently add it to your ~/.ssh/config file, and eliminate it from the command line use. However, there is a valid security reason that rsa-sha1 was disabled. Only do this as a last resort because SHA1 has been broken. Do not enable rsa-sha1 if your servers are audited for security or exposed to the public Internet.

Host *
    PubkeyAcceptedKeyTypes +ssh-rsa

Replace * with a specific host or IP address to limit the use of this configuration.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • 3
    I'd tried PubkeyAcceptedKeyTypes=+ssh-rsa and it worked! Thank you for your answer – 박진근 Sep 29 '22 at 09:08
  • You can also add this to `~/.ssh/config`. I'll edit the answer to show that part. – Tim Shadel Nov 14 '22 at 23:18
  • @TimShadel - If the SSH server has `rsa-sha1` disabled, adding something to `~/ssh/config` will accomplish nothing. In that case, the client must support `rsa-sha2`, which can be configured in `~/.shh/config`. – John Hanley Nov 14 '22 at 23:41
  • @JohnHanley this accepted answer involves adding parameters at the command line. Anything that you can add at the command line can go into SSH config. I think your contention is probably with the answer itself. The thing is, the answer actually works. This is especially important for individuals using macOS. There’s a version of SSH client that has a bug that doesn’t offer this option to the server, and that’s the one that got shipped with macOS. – Tim Shadel Nov 16 '22 at 17:12
  • Oops. I see that your question is about the _content_ of the confit (ssh-rsa vs rsa-sha2-256). My reasoning still stands, though. macOS shipped with a bug that has been fixed in a recent version, but that has not been picked up by macOS 13.0.1, so until then we need to use this method to connect to servers that haven’t changed at all. – Tim Shadel Nov 16 '22 at 17:19
  • With my Godaddy server running`OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013` it seems like my Mac OS 10.16's old `OpenSSH_8.1p1,` continues to be passwordless with rsa, but my new Ubuntu 22's `OpenSSH_8.9p1` doesn't allow me to get away with it. I don't have a solution for passwordless login sadly. – Sridhar Sarnobat Jan 21 '23 at 04:13
38

I spent a few hours until I came to this question and answers. Here is a quick try to ssh into the server and then deal with the stuff later:

ssh -o PubkeyAcceptedKeyTypes=ssh-rsa -i {yourfile} user@host

This combines the previous answers by shoaly and John Hanley which contain more details and suggestions worth to follow to.

Mr.Key
  • 506
  • 4
  • 3
5

I had this message for a lot of time on AWS EC2 trying to connect with ssh:

sign_and_send_pubkey: no mutual signature supported

the code above save me:

# vim ~/.ssh/config, add the lines at the beginning
Host *
    PubkeyAcceptedKeyTypes=+ssh-rsa
    HostKeyAlgorithms=+ssh-rsa
LinFelix
  • 1,026
  • 1
  • 13
  • 23
Yann
  • 51
  • 1
  • 1
1

After the Mac system is upgraded to Ventura 13.1, I encounter the problem that SSH is configured with passwordless login, but the password is still required, my solution is to upgrade and encrypt the server's key to ed25519:

// 1. server: check HostKey in /etc/ssh/sshd_config
...
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

// 2. client: ssh-keygen -t ed25519
ssh-keygen -t ed25519

// 3. client: vim ~/.ssh/ssh_config
Host *
    IdentityFile ~/.ssh/id_ed25519

// 4. client: ssh-copy-id 
ssh-copy-id -i ~/.ssh/id_ed25519.pub

// 5. test ssh using identity file
ssh -v username@hostname

more about see man sshd_config, search keywords HostKey and HostKeyAlgorithms

 HostKey
    Specifies a file containing a private host key used by SSH.  The defaults are /etc/ssh/ssh_host_ecdsa_key,
    /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key.

    Note that sshd(8) will refuse to use a file if it is group/world-accessible and that the HostKeyAlgorithms
    option restricts which of the keys are actually used by sshd(8).
HostKeyAlgorithms
    Specifies the host key signature algorithms that the server offers.
lupguo
  • 1,525
  • 13
  • 13
1

This is an updated security setting intended to push you toward a more secure algorithm. If you can upload a new key to your target host, you might as well make a new key using current best practices:

ssh-keygen -t ed25519 -a 100

You'll then want to upload the public key ~/.ssh/id_ed25519.pub to the server.

tomelin5
  • 55
  • 7
jtpereyda
  • 6,987
  • 10
  • 51
  • 80