Fetch Softworks

Changed SSH key file and cannot "Fetch" my server files (6 posts)

• Started 4 years ago by Vello Franzia
• Latest reply 4 years ago from Vello Franzia

• Vello Franzia Member

  Hi peeps, quick question I have, hoping you may have insight.

  My Mac OS X Catalina laptop worked fine with Fetch before I began throwing out my old SSH keys.

  I am trying to throw out old SSH keys to my work server (self-administered by yours truly, a programming/Linux novice).

  I can successfully shell into my server from my mac with my brand new SSH key, located in /Username/.ssh - so that's not my problem. My problem is that both Fetch and my SSHFS Mac Fuse with my Linux file server seem to be expecting the old SSH key I am trying to discard. They will work when I move the old key back to the usual place, but not when that old key is missing.

  I am trying to have Fetch and my SSHFS Fuse refer to my brand new SSH private key. Any hints as to what I'm missing?

  Here is the text from Fetch I see after removing the "known_hosts" entry for the old key.

  Fetch can not verify the identity of server “[10.8.0.1]:NONSTANDARD PORT #”.

  The host key for this server is unknown. You might be connecting to a server that is pretending to be “[10.8.0.1]:NONSTANDARD PORT #”, which could put your confidential information at risk.

  The ECDSA host key is "###HOST KEY###"

  Would you like to always trust this host key when connecting to “[10.8.0.1]:NONSTANDARD PORT #” and connect to the server now?

  Posted 4 years ago #

• Jim Matthews Administrator

  Hi,

  That message is telling you that the SSH server is offering an ECDSA host key that is not currently listed in the known_hosts file. If the ECDSA host key is valid, you should tell Fetch that you trust it, and you shouldn't see this message again.

  Note: host keys are a different sort of key from the public/private keys you use to log in. Host keys are your reassurance that you are connecting to the server you think you are connecting to. Login keys are the server's reassurance that you are the user you claim to be.

  I hope this helps,

  Jim Matthews
  Fetch Softworks

  Posted 4 years ago #

• Vello Franzia Member

  Hi Jim, unfortunately the problem is persisting. I emptied my known_hosts file, and also verified that my .ssh/config file specifies my new key and not my old one.

  I'm at a loss as to what the issue is. The error message Fetch is showing still says 'ECDSA" as opposed to my new ED25519 key. Also worth noting that my new ED25519 key works fine for terminal shelling into my server. But Fetch and MacFuse are still expecting to work off the old ECDSA key.

  'Try again, or contact the server administrator to verify that you have the correct hostname, username, password, and authentication method, and that the server is running.
  Server responded: “USER@10.8.0.1: Permission denied (publickey).'
  ”

  Any advice is appreciated.

  Posted 4 years ago #

• Vello Franzia Member

  I finally figured out my issue.

  I had to open a local terminal shell on my mac, and run:
  ssh-add /.ssh/newkeyfilename

  This solved my troubles with both Fetch and SSHFS/MacFuse and I can now authenticate with my new SSH key in all the ways I need to.

  Idea taken from near the bottom of the page at this link:
  https://help.dreamhost.com/hc/en-us/articles/216499537-How-to-configure-passwordless-login-in-Mac-OS-X-and-Linux

  Edited 4 years ago #

• Jim Matthews Administrator

  Hi,

  I'm glad to hear that you figured it out!

  Jim Matthews
  Fetch Softworks

  Edited 4 years ago #

• Vello Franzia Member

  Quick add on if it helps anyone -

  Because I run Mac OSX 10.15 Catalina - due to some kind of change implemented recently, in order to make these changes persistent across reboots, I had to follow the instructions at this page:

  https://github.com/jirsbek/SSH-keys-in-macOS-Sierra-keychain

  Solution 2 was what ended up working for me. Everything else I tried until then did not work. Perhaps there is a more elegant solution out there, but none that actually worked for me across reboots.

  Thanks again.

  Edited 4 years ago #