I'm running macOS Sonoma 14.6.1 on a couple machines. I originally purchased the AppStore version of CoreShell and have used it for several years, purchased premium. I have just transitioned to the Codinn Store version, though I believe the occurrence of this issue came about recently, before I switched to the Codinn Store version.
I am primarily interacting with Ubuntu 22.04 LTS machines. I have recently provisioned some new servers from a provider's 22.04 LTS image and fully updated it after provisioning. I like to use CoreShell to manage my servers, and have been doing so without issues for several years. A recent occurrence (within the past couple of weeks) is that I am getting the "Permission denied (publickey)" error message when trying to connect. Following the troubleshooting steps in the support forum, I added +ssh-rsa to PubkeyAcceptedAlgorithms in the settings for one of the servers to test. It did not change behavior.
Attached is my depersonalized log from the session. Hoping you can determine what I am doing wrong. coreshell_log.txt (13.5 KB)
16:20:40 debug1: Authentications that can continue: publickey
But it seemed you do not have private key in ~/.ssh/ nor in ssh-agent:
16:20:40 debug3: ssh_get_authentication_socket_path: path '/private/tmp/com.apple.launchd.YP4zZL2uGJ/Listeners'
16:20:40 debug1: get_agent_identities: bound agent to hostkey
16:20:40 debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
16:20:40 debug1: Will attempt key: /Users/myrealusername/.ssh/id_rsa
16:20:40 debug1: Will attempt key: /Users/myrealusername/.ssh/id_ecdsa
16:20:40 debug1: Will attempt key: /Users/myrealusername/.ssh/id_ecdsa_sk
16:20:40 debug1: Will attempt key: /Users/myrealusername/.ssh/id_ed25519
16:20:40 debug1: Will attempt key: /Users/myrealusername/.ssh/id_ed25519_sk
16:20:40 debug1: Will attempt key: /Users/myrealusername/.ssh/id_xmss
16:20:40 debug1: Will attempt key: /Users/myrealusername/.ssh/id_dsa
16:20:40 debug2: pubkey_prepare: done
16:20:40 debug1: Trying private key: /Users/myrealusername/.ssh/id_rsa
16:20:40 debug3: no such identity: /Users/myrealusername/.ssh/id_rsa: No such file or directory
16:20:40 debug1: Trying private key: /Users/myrealusername/.ssh/id_ecdsa
16:20:40 debug3: no such identity: /Users/myrealusername/.ssh/id_ecdsa: No such file or directory
16:20:40 debug1: Trying private key: /Users/myrealusername/.ssh/id_ecdsa_sk
16:20:40 debug3: no such identity: /Users/myrealusername/.ssh/id_ecdsa_sk: No such file or directory
16:20:40 debug1: Trying private key: /Users/myrealusername/.ssh/id_ed25519
16:20:40 debug3: no such identity: /Users/myrealusername/.ssh/id_ed25519: No such file or directory
16:20:40 debug1: Trying private key: /Users/myrealusername/.ssh/id_ed25519_sk
16:20:40 debug3: no such identity: /Users/myrealusername/.ssh/id_ed25519_sk: No such file or directory
16:20:40 debug1: Trying private key: /Users/myrealusername/.ssh/id_xmss
16:20:40 debug3: no such identity: /Users/myrealusername/.ssh/id_xmss: No such file or directory
16:20:40 debug1: Trying private key: /Users/myrealusername/.ssh/id_dsa
16:20:40 debug3: no such identity: /Users/myrealusername/.ssh/id_dsa: No such file or directory
16:20:40 debug2: we did not send a packet, disable method
16:20:40 debug1: No more authentication methods to try.
I'm not using SSH keys.... for these servers, I have a root login and password. The same setup I've been using for years. For some reason it is now not working. Perhaps I am not using the best method for doing this, but why are some servers (new ones) no longer working this way?
It is the server configured to require publickey authentication, do you have permission to change server config? BTW, you can try equivalent command in a local shell to verify whether it works in vanilla openssh:
I'm unsure...running your code (with my real IP) yields the attached results in the Mac terminal. I guess it's possible something has changed with my server provisioning process (I use runcloud.io). I can check with them as well... terminal_log_2.txt (12.1 KB)
Runcloud support has helped me solve this...in this case it was changing
KbdInteractiveAuthentication to yes in sshd_config on the servers in question.
I'm awaiting a final answer on this from Runcloud, but I suspect that they changed a default in their provisioning script that caused this change. I'll consider this solved. Thanks for your help!
Please check KbdInteractiveAuthentication and AuthenticationMethods directives, make sure KbdInteractiveAuthentication set to yes and AuthenticationMethods contains keyboard-interactive, for example:
NOTE: though keyboard-interactive auth method is fine for most cases, it is still recommend to use publickey or multiple methods combination to protect your server from attack.