SSH keys and SSHFS automounting via fstab

OdinEidolon · 2014-06-12 16:08:59

I have some problems understanding the details of how ssh keying and SSHFS automouting works.
I cannot get them to work. The problems may or may not be connected.

My SSH setup:
user1@notebook <--> user2@institution <--> user3@office
That is:
adriano@M735T <--> afantini@ssh.ictp.it <--> afantini@nb8-18-7.ictp.it

I can ssh to @institution without problems and from there ssh at @office, with password.
To access @office directly I edited @notebook:~/.ssh/config thusly:

                                                                                                                                                                             
ServerAliveInterval 120                                                                                                                                                            
                                                                                                                                                                                   
Host ictp                                                                                                                                                                          
Hostname ssh.ictp.it                                                                                                                                                               
User afantini                                                                                                                                                                      
                                                                                                                                                                                   
Host hp83-clima-20                                                                                                                                                                 
ProxyCommand ssh -q ictp nc -q0 nb8-18-7.ictp.it 22

And this works pretty well: I can login directly to @office, in which case I am required to input both passwords. I can also access via KDE's sftp:// without problems.

Now for what I want to do:
1) I want to be able to ssh to both computers without having to enter the password. I followed this
guide (linked from the archwiki) with no success for some reason, using id_rsa. It just keeps asking for
password.
This is the output of
ssh -v user2@institution

ssh -v afantini@ssh.ictp.it
OpenSSH_6.6.1, OpenSSL 1.0.1h 5 Jun 2014
debug1: Reading configuration data /home/adriano/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for ssh.ictp.it
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/adriano/.ssh/socket-afantini@ssh.ictp.it:22" does not exist
debug1: Connecting to ssh.ictp.it [140.105.33.200] port 22.
debug1: Connection established.
debug1: identity file /home/adriano/.ssh/id_rsa type 1
debug1: identity file /home/adriano/.ssh/id_rsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_dsa type -1
debug1: identity file /home/adriano/.ssh/id_dsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa type 3
debug1: identity file /home/adriano/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ed25519 type -1
debug1: identity file /home/adriano/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA f5:9c:82:d4:e1:8d:8d:87:e1:7e:a7:d9:0a:02:dd:ed
debug1: Host 'ssh.ictp.it' is known and matches the ECDSA host key.
debug1: Found key in /home/adriano/.ssh/known_hosts:11
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/adriano/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/adriano/.ssh/id_dsa
debug1: Offering ECDSA public key: /home/adriano/.ssh/id_ecdsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/adriano/.ssh/id_ed25519
debug1: Next authentication method: password
afantini@ssh.ictp.it's password:

And ssh -v user3@office

ssh -v afantini@hp83-clima-20
OpenSSH_6.6.1, OpenSSL 1.0.1h 5 Jun 2014
debug1: Reading configuration data /home/adriano/.ssh/config
debug1: /home/adriano/.ssh/config line 7: Applying options for hp83-clima-20
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh -q ictp nc -q0 nb8-18-7.ictp.it 22
debug1: permanently_drop_suid: 1000
debug1: identity file /home/adriano/.ssh/id_rsa type 1
debug1: identity file /home/adriano/.ssh/id_rsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_dsa type -1
debug1: identity file /home/adriano/.ssh/id_dsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa type 3
debug1: identity file /home/adriano/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ed25519 type -1
debug1: identity file /home/adriano/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
afantini@ssh.ictp.it's password:

If I login once then logout @both, all subsequent @institution logins are passwordless, but not those @office (asks only the @office passoword):

ssh -v afantini@hp83-clima-20
OpenSSH_6.6.1, OpenSSL 1.0.1h 5 Jun 2014
debug1: Reading configuration data /home/adriano/.ssh/config
debug1: /home/adriano/.ssh/config line 7: Applying options for hp83-clima-20
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh -q ictp nc -q0 nb8-18-7.ictp.it 22
debug1: permanently_drop_suid: 1000
debug1: identity file /home/adriano/.ssh/id_rsa type 1
debug1: identity file /home/adriano/.ssh/id_rsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_dsa type -1
debug1: identity file /home/adriano/.ssh/id_dsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ed25519 type -1
debug1: identity file /home/adriano/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: multiplexing control connection
debug1: channel 1: new [mux-control]
debug1: channel 2: new [client-session]
debug1: Sending command: nc -q0 nb8-18-7.ictp.it 22
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA fa:62:77:87:27:4d:cc:22:bd:f2:3f:81:0b:69:4d:a1
debug1: Host 'hp83-clima-20' is known and matches the ECDSA host key.
debug1: Found key in /home/adriano/.ssh/known_hosts:14
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/adriano/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/adriano/.ssh/id_dsa
debug1: Trying private key: /home/adriano/.ssh/id_ecdsa
debug1: Trying private key: /home/adriano/.ssh/id_ed25519
debug1: Next authentication method: password
afantini@hp83-clima-20's password:

2) I want to mount automatically at boot or (even better) on demand, if network is up:
@institution:/home/user2 to /mnt/institution_folder
@office:/folder to /mnt/office_folder

I can manually mount the SSHFS using:

sshfs afantini@ssh.ictp.it:/afs/ictp.it/home/a/afantini/ /mnt/SSHFS_ictp_home
sshfs afantini@hp83-clima-20:/home/clima-archive3/afantini/tesi/ /mnt/SSHFS_ictp_tesi/

without problems. It asks for passwords (just one each) the first time I mount. If I unmount and remount, it asks for password only for @office (@hp83-clima-20).

According to the wiki the automounting is accomplished by fstab lines like the following:

###SSHFS ICTP
#try one of the following
##on-demand
#afantini@ssh.ictp.it:/afs/ictp.it/home/a/afantini/ /mnt/SSHFS_ictp_home fuse.sshfs
noauto,x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/adriano/.ssh/id_rsa,allow_other,reconnect 0 0
#afantini@hp83-clima-20:/home/clima-archive3/afantini/tesi/ /mnt/SSHFS_ictp_tesi fuse.sshfs
noauto,x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/adriano/.ssh/id_rsa,allow_other,reconnect 0 0
##at boot
#afantini@ssh.ictp.it:/afs/ictp.it/home/a/afantini/ /mnt/SSHFS_ictp_home fuse.sshfs defaults,_netdev,allow_other 0 0
#afantini@hp83-clima-20:/home/clima-archive3/afantini/tesi/ /mnt/SSHFS_ictp_tesi fuse.sshfs defaults,_netdev,allow_other 0 0

Tests performed:

* If I uncomment the upper on-demand lines then run sudo mount -a form a freshly rebooted system:

sudo mount -a

No output, but they are NOT mounted even if I try to access /mnt/SSHFS_ictp_{home,tesi} (they are empty)

* If I uncomment the upper on-demand lines then run sudo mount -a form a system which already manually mounted then unmounted the SSHFS:

sudo mount -a
afantini@ssh.ictp.it's password:
read: Connection reset by peer

No output, but they are NOT mounted even if I try to access /mnt/SSHFS_ictp_{home,tesi} (they are empty)

* If I uncomment the lower 2 lines then run sudo mount -a form a freshly rebooted system:

sudo mount -a
afantini@ssh.ictp.it's password:
read: Connection reset by peer

@institution is mounted, @office is not

* If I uncomment the lower 2 lines then run sudo mount -a form a system which already manually mounted then unmounted the SSHFS:

sudo mount -a
afantini@ssh.ictp.it's password:
read: Connection reset by peer

@institution is mounted, @office is not

* If I uncomment the upper on-demand lines then reboot:

cd /mnt/SSHFS_ictp_tesi
bash: cd: /mnt/SSHFS_ictp_tesi: No such device
cd /mnt/SSHFS_ictp_home
bash: cd: /mnt/SSHFS_ictp_home: No such device

And of course manual mounting fails with the same error.

* If I uncomment the lower 2 lines then reboot:
they are NOT mounted even if I try to access /mnt/SSHFS_ictp_{home,tesi} (they are empty). Journalctl reports as error, after automount request:

read: Connection reset by peer

and both SSHFS are manually mountable. @institution with password only the first time; @office with password always. If I try:

sudo mount -a
afantini@ssh.ictp.it's password:
read: Connection reset by peer

Only @institution is mounted. Manually mounting @office works with password.

Sorry for the wall of text, I tried to describe the problem in full details. Any hints or suggestions (maybe new tests to run)?
Thanks in advance

samiam · 2014-06-14 11:46:09

Check permissions on your ~/.ssh directories (should be 0700) and the files under them (0600). You should be able to log into either host without a password using keys and the proxy command.

And use autofs. It is made precisely for what you're trying to do.

https://wiki.archlinux.org/index.php/Autofs

EDIT: And the ~/.ssh directories should be `chown -R` to whatever user you're logging in as. I know that's stating the obvious, but when keys don't work, it's almost always ownership or permissions problems.

Last edited by samiam (2014-06-14 11:48:12)

OdinEidolon · 2014-06-14 16:58:06

samiam wrote:

Check permissions on your ~/.ssh directories (should be 0700) and the files under them (0600). You should be able to log into either host without a password using keys and the proxy command.
And use autofs. It is made precisely for what you're trying to do.
https://wiki.archlinux.org/index.php/Autofs
EDIT: And the ~/.ssh directories should be `chown -R` to whatever user you're logging in as. I know that's stating the obvious, but when keys don't work, it's almost always ownership or permissions problems.

Hello and thanks for your suggestions.
I tried setting all the permissions to 644 and 744 without success. Also 700 and 600. Both on the remote hosts and on local, of course.

So this is what I did:
- Completely purged all 3 .ssh directory, except for the .ssh/config file on the local laptop.
- Created a new key with ssh-keygen
- ssh-copy-id. This does not work, I think because of this bug. The remote servers probably use a different shell. So I did this:

cat ~/.ssh/id_rsa.pub | ssh user@HOST 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

- Checked all 3 .ssh dirs were 700 and contents were 600 or 744 and 644
- Remove the socket file:

rm .ssh/socket*

- For the intermediate server:

└──>  ssh -v afantini@ictp
OpenSSH_6.6.1, OpenSSL 1.0.1h 5 Jun 2014
debug1: Reading configuration data /home/adriano/.ssh/config
debug1: /home/adriano/.ssh/config line 3: Applying options for ictp
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/adriano/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for ssh.ictp.it
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/adriano/.ssh/socket-afantini@ssh.ictp.it:22" does not exist
debug1: Connecting to ssh.ictp.it [140.105.33.200] port 22.
debug1: Connection established.
debug1: identity file /home/adriano/.ssh/id_rsa type 1
debug1: identity file /home/adriano/.ssh/id_rsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_dsa type -1
debug1: identity file /home/adriano/.ssh/id_dsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ed25519 type -1
debug1: identity file /home/adriano/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA f5:9c:82:d4:e1:8d:8d:87:e1:7e:a7:d9:0a:02:dd:ed
debug1: Host 'ssh.ictp.it' is known and matches the ECDSA host key.
debug1: Found key in /home/adriano/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/adriano/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/adriano/.ssh/id_dsa
debug1: Trying private key: /home/adriano/.ssh/id_ecdsa
debug1: Trying private key: /home/adriano/.ssh/id_ed25519
debug1: Next authentication method: password
afantini@ssh.ictp.it's password:

And for the office computer:

└──>  ssh -v afantini@hp83-clima-20
OpenSSH_6.6.1, OpenSSL 1.0.1h 5 Jun 2014
debug1: Reading configuration data /home/adriano/.ssh/config
debug1: /home/adriano/.ssh/config line 7: Applying options for hp83-clima-20
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh -q ictp nc -q0 nb8-18-7.ictp.it 22
debug1: permanently_drop_suid: 1000
debug1: identity file /home/adriano/.ssh/id_rsa type 1
debug1: identity file /home/adriano/.ssh/id_rsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_dsa type -1
debug1: identity file /home/adriano/.ssh/id_dsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa type -1
debug1: identity file /home/adriano/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/adriano/.ssh/id_ed25519 type -1
debug1: identity file /home/adriano/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
afantini@ssh.ictp.it's password:
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA fa:62:77:87:27:4d:cc:22:bd:f2:3f:81:0b:69:4d:a1
debug1: Host 'hp83-clima-20' is known and matches the ECDSA host key.
debug1: Found key in /home/adriano/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/adriano/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/adriano/.ssh/id_dsa
debug1: Trying private key: /home/adriano/.ssh/id_ecdsa
debug1: Trying private key: /home/adriano/.ssh/id_ed25519
debug1: Next authentication method: password
afantini@hp83-clima-20's password:

As you can see it STILL does not work!

EDIT: as per wiki, I'm running ssh-keygen without using a passphrase.

Last edited by OdinEidolon (2014-06-14 17:01:00)

ralvez · 2014-06-14 19:31:05

Edit /etc/ssh/sshd_config and uncomment HostbasedAuthentication

#HostbasedAuthentication no <-- line to change

and set it to yes

R.

Edit: On second thought, it looks like those are not your servers... I do not think this will help you. Sorry

Last edited by ralvez (2014-06-14 19:33:31)

rune0077 · 2014-06-14 19:49:23

But do read and possibly post here the auth logs from the servers, as they will have far more useful info than the error messages from the client side. And if they don't give you anything useful, try running sshd in debug mode for more log output.

OdinEidolon · 2014-06-14 19:59:01

ralvez wrote:

Edit /etc/ssh/sshd_config and uncomment HostbasedAuthentication
#HostbasedAuthentication no <-- line to change 
and set it to yes
R.
Edit: On second thought, it looks like those are not your servers... I do not think this will help you. Sorry

No problem. Thank you for trying to help.

rune0077 wrote:

But do read and possibly post here the auth logs from the servers, as they will have far more useful info than the error messages from the client side. And if they don't give you anything useful, try running sshd in debug mode for more log output.

Could you please clarify this?
I am not an admin on those servers and do not have read permissions on /var/log/auth*

rune0077 · 2014-06-14 20:04:02

Ah, then you can't post the logs. But authentication errors with sshd are usually logged on the server side. Maybe you could have the admin look through the logs, if that's an option?

OdinEidolon · 2014-06-14 20:14:02

rune0077 wrote:

Ah, then you can't post the logs. But authentication errors with sshd are usually logged on the server side. Maybe you could have the admin look through the logs, if that's an option?

I could try (in about a week time), but I doubt I'll get any kind of help.
What could the issue be? Could it be that the hosts are just configured to accept password authentication only?

rune0077 · 2014-06-14 21:41:36

OdinEidolon wrote:

rune0077 wrote:
Ah, then you can't post the logs. But authentication errors with sshd are usually logged on the server side. Maybe you could have the admin look through the logs, if that's an option?
I could try (in about a week time), but I doubt I'll get any kind of help.
What could the issue be? Could it be that the hosts are just configured to accept password authentication only?

That is certainly possible, though I don't see why anyone would want to disable key authentication. They could also have changed the location sshd look for authorized keys to something other than the default (~/.ssh/authorized_keys). Again, I don't see why, but without having access to configs, logs or an admin, it is impossible to tell.

samiam · 2014-06-15 02:09:04

OdinEidolon wrote:

- Checked all 3 .ssh dirs were 700 and contents were 600 or 744 and 644

744 and 644 is not good enough. From http://www.openssh.com/faq.html#3.14

3.14 - I copied my public key to authorized_keys but public-key authentication still doesn't work.
Typically this is caused by the file permissions on $HOME, $HOME/.ssh or $HOME/.ssh/authorized_keys being more permissive than sshd allows by default.
In this case, it can be solved by executing the following on the server.
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys
If this is not possible for some reason, an alternative is to set StrictModes no in sshd_config, however this is not recommended.

I'll bet you a dollar that if you had access to the logs on the server side you would see this message:

Authentication refused: bad ownership or modes for (something)

I should have mentioned before that your home directory should be 755 or less as well.

Last edited by samiam (2014-06-15 02:10:26)

OdinEidolon · 2014-06-15 08:57:26

samiam wrote:

OdinEidolon wrote:
- Checked all 3 .ssh dirs were 700 and contents were 600 or 744 and 644
744 and 644 is not good enough. From http://www.openssh.com/faq.html#3.14
3.14 - I copied my public key to authorized_keys but public-key authentication still doesn't work.
Typically this is caused by the file permissions on $HOME, $HOME/.ssh or $HOME/.ssh/authorized_keys being more permissive than sshd allows by default.
In this case, it can be solved by executing the following on the server.
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys
If this is not possible for some reason, an alternative is to set StrictModes no in sshd_config, however this is not recommended.
I'll bet you a dollar that if you had access to the logs on the server side you would see this message:
Authentication refused: bad ownership or modes for (something)
I should have mentioned before that your home directory should be 755 or less as well.

Thanks again for your input. The 644/744 info came from a page linked from the ArchWiki. Anyhow, I had tried both x44 and x00.

However, I executed the 3 commands above on all three computers and tried again with no success. Password is still required.

I am pretty stuck. Is there anything else I could try except contacting the admins for help?
I'll try later with another PC to see if the problem is some hidden config on my laptop that I changed years ago then forgot.

OdinEidolon · 2014-06-15 09:23:18

Just tried with another computer (a Chakra desktop connected to the internet through my laptop's wifi, via a shared wired connection) and the problem is the same. Of course I triple checked permissions and such.
With one small, probably negligible difference: the chakra computer does NOT keep the socket open and so keeps asking the password every time I try to ssh, while my laptop creates a socket file under ~/.ssh and thus permits passwordless login within short time after the first login. This was probably some option I set years ago, however it should not change anything in my login problem.

techmunk · 2014-06-25 09:33:53

I had the exact same problem. Does your key perchance require a password to unlock? If you run the sshfs command as root, you'll see that it asks for the passphrase to unlock the key.

I was able to solve this with the following systemd.mount and systemd.automount files (Adjusted for your setup).

/etc/systemd/system/mnt-SSHFS_ictp_home.automount

[Automount]
Where=/mnt/SSHFS_ictp_home
DirectoryMode=0775

[Install]
WantedBy=multi-user.target

/etc/systemd/system/mnt-SSHFS_ictp_home.mount

[Unit]
After=remote-fs-pre.target
Wants=remote-fs-pre.target
Conflicts=umount.target
Before=umount.target

[Mount]
What=afantini@ssh.ictp.it:/afs/ictp.it/home/a/afantini
Where=/mnt/SSHFS_ictp_home
Type=fuse.sshfs
Options=users,noatime,async,defaults,idmap=user,IdentityFile=/home/adriano/.ssh/id_rsa,uid=1000,gid=100,umask=2,allow_other,follow_symlinks,reconnect,default_permissions
DirectoryMode=775
Environment="SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass" "SSH_AUTH_SOCK=/run/user/1000/keyring/ssh"

[Install]
WantedBy=remote-fs.target

The secret is the "Environment" line in the .mount file. These might be different depending on what agents you're using. Adjust accordingly.

To get it to work, systemctl enable mnt-SSHFS_ictp_home.automount and systemctl start mnt-SSHFS_ictp_home.automount.

You might also be able to do this with your existing fstab using systemd dropins, creating /etc/systemd/system/mnt-SSHFS_ictp_home.mount.d/01-env.conf, and putting the following in it:

[Mount]
Environment="SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass" "SSH_AUTH_SOCK=/run/user/1000/keyring/ssh"

I have not tested to see if this will work however.

Last edited by techmunk (2014-06-25 11:28:01)

OdinEidolon · 2014-06-25 09:55:09

Thank you A LOT for your input.
I will try that later. Shoul I put as options also x-systemd.automount?

techmunk · 2014-06-25 10:11:44

If you're using the fstab method with the dropin, then yes, you will still need the x-systemd.automount so the systemd .mount and .automount files are made by systemd in /run/systemd/generator.

If you just use pure systemd, and don't have the fstab entry as I'm currently runing, then I don't think it's needed. I haven't needed it, and the directories automount when I first try to access them. Given these are systemd files, I don't think the "users" option is needed either, but it doesn't hurt having it there. You could also put in _netdev if you wanted to keep the same options as your fstab, but the systemd [Unit] and [Install] sections handle this. (I missed the [Unit] section in the .mount file in my last post, I've updated that post with the missing info).

OdinEidolon · 2014-06-25 11:19:43

ls: cannot open directory /mnt/SSHFS_ictp_home: No such device

(PS: you also forgot an IdentityFile=)

sudo journalctl -b | grep SSHFS
gives nothing

techmunk · 2014-06-25 11:27:43

Not sure. I had a similar issue when trying to get it to work. You can try unmounting it, that fixed the error for me, then attempt to re-mount again. I think when the mount fails, it's half mounted, which causes issues.

I did forget the IdentityFile. Must've happened when I updated with your key. I'll edit and fix that.

Did you comment out the lines in fstab?

Did you also either a) reboot, or b) delete the appropriate .mount and .automount files from /run/systemd/generator, and run systemctl daemon-reload?

OdinEidolon · 2014-06-25 11:50:41

I did comment out fstab (it was not working anyway) and rebooted.

I now rebooted again, unmounted and remounted (using systemctl restart), but:

ls: cannot access /mnt/SSHFS_ictp_home: Transport endpoint is not connected
d????????? ?    ?            ? SSHFS_ictp_home

And

sudo systemctl status mnt-SSHFS_ictp_home.mount

mnt-SSHFS_ictp_home.mount - /mnt/SSHFS_ictp_home
   Loaded: loaded (/etc/systemd/system/mnt-SSHFS_ictp_home.mount; disabled)
   Active: failed (Result: exit-code) since mer 2014-06-25 13:44:21 CEST; 11s ago
    Where: /mnt/SSHFS_ictp_home
     What: afantini@ssh.ictp.it:/afs/ictp.it/home/a/afantini
  Process: 5519 ExecMount=/bin/mount afantini@ssh.ictp.it:/afs/ictp.it/home/a/afantini /mnt/SSHFS_ictp_home -t fuse.sshfs -o users,noatime,async,defaults,idmap=user,IdentityFile=/home/adriano/.ssh/id_rsa,uid=1000,gid=100,umask=2,allow_other,follow_symlinks,reconnect,default_permissions,x-systemd.automount (code=exited, status=1/FAILURE)

giu 25 13:44:21 M735T mount[5519]: read: Connection reset by peer

In the meantime, I asked one of the sysadmins. He said RSA should have been working fine, he used it. He checked my setup and it looked fine. He said he'll look into it... but I bet he already forgot. It's not really a great deal. I can run a script asking for the password and automatically mounting the 4 SSHFS I need, which is what I do now. It's not extremely safe, but this data is not sensible.

techmunk · 2014-06-25 11:56:47

The only other thing I can suggest to look into this further, is to try running the ExecMount command from systemctl status above as root. The system automounts all run as root, which was the main cause of my particular issues. You might get some more helpful information back.

OdinEidolon · 2014-06-25 12:04:26

The command works but it asks the password which I believe is the problem... the fact that the RSA auth does not seem to work

techmunk · 2014-06-25 12:07:03

That's what the environment line in the .mount file intended to fix.

Environment="SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass" "SSH_AUTH_SOCK=/run/user/1000/keyring/ssh"

That's the real key. Now, this is likely going to be different on your setup. You can find what these are by running as your user

set | grep SSH

OdinEidolon · 2014-06-29 09:46:08

techmunk wrote:

That's what the environment line in the .mount file intended to fix.
Environment="SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass" "SSH_AUTH_SOCK=/run/user/1000/keyring/ssh"
That's the real key. Now, this is likely going to be different on your setup. You can find what these are by running as your user
set | grep SSH

Thank you again.
Sorry but for some reason I missed your post.

I don't have the /run/user/1000/keyring folder and the set command returns nothing. sshd.service is running. What's wrong?

Last edited by OdinEidolon (2014-06-29 09:46:27)

techmunk · 2014-06-29 13:00:52

SSH_AUTH_SOCK is generated by an SSH agent, which holds information about SSH keys used to authenticate. You can find information about them on the arch wiki at https://wiki.archlinux.org/index.php/SS … SSH_agents.

OdinEidolon · 2014-06-29 13:39:11

techmunk wrote:

SSH_AUTH_SOCK is generated by an SSH agent, which holds information about SSH keys used to authenticate. You can find information about them on the arch wiki at https://wiki.archlinux.org/index.php/SS … SSH_agents.

Sorry to bother, but this is not clear at all to me. You use both x11-ssh-askpass and keychain?
My RSA key does NOT have a password. So in theory I should not have to use any ssh agent, as per wiki:
"If your private key is encrypted with a passphrase"
mine is not. It just should NOT ask for any password at all!

anatolik · 2014-06-29 15:58:55

OdinEidolon wrote:

My RSA key does NOT have a password. So in theory I should not have to use any ssh agent, as per wiki:
"If your private key is encrypted with a passphrase"
mine is not. It just should NOT ask for any password at all!

Correct, ssh-agent (or gnome-keyring-daemon) is needed for keys encrypted with a passphrase. The idea that the user does not have access to unencripted key, only the agent keeps this information in a guarded memory area. If you don't use passphrase then you don't need the agent.

But make sure that if your systemd unit has SSH_AUTH_SOCK set then corresponding agent should exist and alive. Otherwise sshfs will fail trying to connect to the agent, even if your key does not have the passphrase.

Last edited by anatolik (2014-06-29 16:02:53)

Arch Linux

#1 2014-06-12 16:08:59

SSH keys and SSHFS automounting via fstab

#2 2014-06-14 11:46:09

Re: SSH keys and SSHFS automounting via fstab

#3 2014-06-14 16:58:06

Re: SSH keys and SSHFS automounting via fstab

#4 2014-06-14 19:31:05

Re: SSH keys and SSHFS automounting via fstab

#5 2014-06-14 19:49:23

Re: SSH keys and SSHFS automounting via fstab

#6 2014-06-14 19:59:01

Re: SSH keys and SSHFS automounting via fstab

#7 2014-06-14 20:04:02

Re: SSH keys and SSHFS automounting via fstab

#8 2014-06-14 20:14:02

Re: SSH keys and SSHFS automounting via fstab

#9 2014-06-14 21:41:36

Re: SSH keys and SSHFS automounting via fstab

#10 2014-06-15 02:09:04

Re: SSH keys and SSHFS automounting via fstab

#11 2014-06-15 08:57:26

Re: SSH keys and SSHFS automounting via fstab

#12 2014-06-15 09:23:18

Re: SSH keys and SSHFS automounting via fstab

#13 2014-06-25 09:33:53

Re: SSH keys and SSHFS automounting via fstab

#14 2014-06-25 09:55:09

Re: SSH keys and SSHFS automounting via fstab

#15 2014-06-25 10:11:44

Re: SSH keys and SSHFS automounting via fstab

#16 2014-06-25 11:19:43

Re: SSH keys and SSHFS automounting via fstab

#17 2014-06-25 11:27:43

Re: SSH keys and SSHFS automounting via fstab

#18 2014-06-25 11:50:41

Re: SSH keys and SSHFS automounting via fstab

#19 2014-06-25 11:56:47

Re: SSH keys and SSHFS automounting via fstab

#20 2014-06-25 12:04:26

Re: SSH keys and SSHFS automounting via fstab

#21 2014-06-25 12:07:03

Re: SSH keys and SSHFS automounting via fstab

#22 2014-06-29 09:46:08

Re: SSH keys and SSHFS automounting via fstab

#23 2014-06-29 13:00:52

Re: SSH keys and SSHFS automounting via fstab

#24 2014-06-29 13:39:11

Re: SSH keys and SSHFS automounting via fstab

#25 2014-06-29 15:58:55

Re: SSH keys and SSHFS automounting via fstab

Board footer