5

I connect to a server via sshfs using private/public key pairs. My local key needs a passphrase to use. NOTE: The public key has already been copied to the remote server. I'm looking for a method to cache the credentials for this key!

I want to auto-mount this share at login (to a MATE session), and need a secure way of storing the password for the key (as opposed to the SSH password, since the server does not accept passwords).

Right now the command is:

$ sshfs [email protected]:/ /home/me/MyMountPoint

But I am prompted for a password to unlock the key. I could make the key not require a password, but if it's safer to use a password protected key and store the password somewhere else, I would favour that over a non-password key.

What would be the recommended way of doing this? If the password file has permissions of 600, then only my user could see it. But then again, the key should already be 600 and only my user could get at it in the first place.

Is there a best practice for storing the key password for auto-mounting SSHFS?

Improve this question
3
  • @sim: The remote key is installed and working. I can login manually be entering my local key's password. This question is about a safe way to store the password for the local key for automatic use. Commented Jan 11, 2014 at 21:00
  • Thank you for clarifying. I've added a note to your Q so that this is more explicitly obvious. Do you have these packages installed? mate-keyring and mate-keyring-pam? Commented Jan 11, 2014 at 21:11
  • If you say "password" you talk about the passhrase - right? Commented Jan 12, 2014 at 21:27

3 Answers 3

Reset to default
4

Use ssh-agent to store the key, then sshfs can use the key from the agent without asking for the passphrase. - Of course you now need to supply the passphrase to add the key to the agent. - mate-keyring might help you with this.

Improve this answer
12
  • 1
    I would recommend something like gnome-keyring-daemon over mate-keyring. gnome-keyring-daemon is a very common utility, often installed and running by default. It even provides a pam module to unlock the keyring using the login password. Commented Jan 11, 2014 at 20:41
  • @Patrick - do you know off hand if that is out of the box wrt to the pam mod or do you have to set that up custom? Commented Jan 11, 2014 at 20:45
  • @slm From my experience, on ubuntu & gentoo, if gnome-keyring-daemon is installed, the pam module is installed and configured. But it's entirely up to the distro/package. Commented Jan 11, 2014 at 20:47
  • @Patrick - that's the biggest issue with this/these types of Q's they're very distro specific, I'd like to see us develop a more general purpose A to these questions so that we can refer to it. He tagged the Q as mate, but as you've indicated you can mix and match using gnome-keyring-daemon which compounds to the confusion/complexity. Commented Jan 11, 2014 at 20:48
  • @slm except it isn't necessarily the goal of stackexchange to provide a howto guide as an answer. It's to provide an answer of how something could be done. If the user runs into an issue trying to accomplish the goal, they can ask another question on the specific issue. Commented Jan 11, 2014 at 20:49
0

seahorse

One method for caching your passphrase is to make use of the application seahorse. This is the application that's used by all the distros that are based on GNOME2 & GNOME3. It might go by other names or shortcuts but you should be able to launch it on any of these distros from the command line like so:

$ seahorse

Once you invoke it you'll be greeted with a GUI like so. Be sure the GUI is selected so that it shows everything "By keyring". It's helpful to keep things straight in this view.

   ss #1

Adding a key

Once you've brought up the GUI you'll want to click on the plus icon to add a key, and select "Secure Shell Key from the dialog.

   ss #2

                        ss #3

Key setup

Now you'll want to define what user this key will be used for and for what machine. This is just a description, but it's helpful when keeping track of your keys in the `$HOME/.ssh/authorized_keys file where it will get used later on. Also it's usually the last field in your

   ss #4

Setting the key's passphrase

Next you'll need to provide the passphrase for this key 2 times.

  ss #5  ss #6

Copy .pub key to remote server

At this point the public/private key pair has been created, and has a passphrase. Now you'll need to copy the .pub key to a user's account on a remote server.

   ss #7

Authorize the copying of .pub

When you acknowledge the above dialog you'll need to authenticate as userX (tammy in this case) on the remote server (mulder).

                                             ss #8

Login to remote server (mulder)

With the key/pair copied to the remote server (mulder) as userX (tammy) we can now attempt to ssh to this server as this user. Doing this will trigger for the password to get added to the keyring permanently.

                  ss #9

Adding passphrase permanently

You'll then get prompted for the passphrase, with the option to make it permanently part of the keyring store forever.

NOTE: This is critical, doing this will allow you to never have to provide this passphrase ever again. Any time you login to your account and unlock it, you'll be unlocking this keyring, which contains this passphrase.

         ss #10

No more passphrase

From now on any time you log in you'll no longer have to provide your passphrase.

Confirmation

Besides logging in and out to the remote server (mulder) if you close seahorse and reopen it you'll notice an additional "Unlock passphrase" entry now exists in your Login keyring. This was added when you checked the box in the previous dialog.

   ss #11

NOTE: I believe you can also add entries manually to store passphrases within your Login keyring too. This would allow for you to store any preexisting SSH key pair passphrases as well.

The setup

For this to work I'm using gnome-keyring and gnome-keyring-pam which facilitate this. An entry such as this in my PAM configuration allows for the Login keyring within seahorse to be unlocked when I login and/or unlock my screenlock.

$ more /etc/pam.d/passwd #%PAM-1.0 auth include system-auth account include system-auth password substack system-auth -password optional pam_gnome_keyring.so use_authtok password substack postlogin

Notice the 5th line.

References

Improve this answer
9
  • OP's private key requires a password. The public key has already been sent to the remote system. Commented Jan 11, 2014 at 20:38
  • @Patrick - Michas and I already went over this in a discussion. I would like the OP to confirm this. He probably has but doesn't explicitly say that he has. Commented Jan 11, 2014 at 20:40
  • "My local key needs a password to use" "need a secure way of storing the password for the key" "prompted for a password to unlock the key" "I could make the key not require a password". It's very clear Commented Jan 11, 2014 at 20:42
  • @Patrick - I added an explicit comment to the Q, asking for this, I see that he "says" something to that effect in his Q, but I'd like him say it explicitly, and explain how. Otherwise we might be chasing ghosts 8-) Commented Jan 11, 2014 at 20:42
  • @Patrick - mine too, but it can get cached in a variety of ways on the keyring so that you don't have to provide. That's ultimately what I'd like to see hashed out of this Q/A Commented Jan 11, 2014 at 20:43
0

If you are auto-mounting via autofs this will be done with the local root account. So generate a root-key without passphrase and establish a trust to the target account@server.

Improve this answer
4
  • This doesn't solve his problem. If he wanted a key without a passphrase, he could create the ssh key without one to begin with and not as root. Commented Mar 18, 2016 at 3:31
  • @vol7ron Yes. But root keys are propably harder to get at. My presumtion was that his home is inecure e.g. NFS, so in need of a passphrase, while root is normally a local secure fs. Commented May 5, 2016 at 21:31
  • Would this then be available to any user on the file system? Commented May 5, 2016 at 21:46
  • @vol7ron If you want, you can grant any user the rights of the original user. That is a mount option for sshfs. Commented May 18, 2016 at 20:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.