0

I created SSH key and transferred it to my target device using ssh-copy-id and now I can ssh targetUsername@targetHost -p 8798 without providing RSA key nor password for targetUsername@targetHost however when I try to mount SSHFS share in fstab (ending is for debug purposes)

sshfs#targetUsername@targetHost:/mnt /media/omnia2 fuse.sshfs _netdev,defaults,IdentityFile=/home/localUsername/.ssh/id_rsa,idmap=user,port=8798,ssh_command=ssh\040-vv,sshfs_debug,debug 0 0

the password for targetUsername@targetHost is demanded and rejected Permission denied, please try again even though I provide a good one. What surprises me is how the RSA key authentication is dropped:

debug2: pubkey_prepare: done
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/localUsername/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
sshfs#targetUsername@targetHost's password:

I think I have all local permissions clear. My other attempt was to use /root/.ssh/id_rsa for key storage yet that did not change a thing.

Etua
  • 15
  • 4
  • Check the logs on the server to find out why. – Michael Hampton Sep 25 '20 at 18:10
  • Thank you, `we did not send a packet` was so unclear to me that I wouldn't have thought that there actually was an authentication attempt and I will find anything useful in the target's logs. – Etua Sep 25 '20 at 18:46

1 Answers1

1

By checking journalctl -u ssh.service at the target machine I realised that target host recognised sshfs#targetUsername from fstab entry as a username while my intention was to log into targetUsername. Removing sshfs# from fstab entry resolved the problem.

Etua
  • 15
  • 4