1

Troubleshooting SSH and NX I have a working SSH connection using a RSA key. The trouble is NX server wants the sshd_config parameter AuthorizedKeysFile to be set to an NX installed file, /var/lib/nxserver/home/.ssh/authorized_keys2. Once I made this change, SSH remote connection could not be authorized. I tried,

  • appendeding the home authorized_keys in ~/.ssh to this /var... file.
  • Its owned by nx, group root, and 644 permissions, so I added the parameters AllowUsers and AllowGroups with both accounts to the end of sshd_config.
  • Restarted the SSHD server after every sshd change.

Unfortunately ssh will not allow this connection.

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

If I change sshd_config AuthorizedKeysFile back to the original settings then its all hunky-dorey. So, Any reason sshd won't accept the authorized key file NX wants?

There are some confusing issues here. Take for example authorized_keys2 was depreciated? Not that these guys cared, because they discuss using authorized_keys2 for NX two years after the first post.

Many NX users note the AuthorizedKeysFile is only the file name, yet this man page on sshd_config (the same as CentOS6) and says "After [token] expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory." The NX path should be OK, right?

Unfortunately my CentOS server is sporting OpenSSH 5.3, because 6.2 (on my client) supports space deliminated list of AuthorizedKeysFile(s).

Community
  • 1
xtian
  • 321
  • 3
  • 15

3 Answers3

2

First of all, in such conditions I always try to have my logs maxed by starting custom undaemonized sshd:

sshd -d -p 11122 -f /new/config/file

And trying connecting to it:

ssh -v -p 11122 this.host

This makes your current configuration safe and gives you all info about how connection was established.

And now comes a wild guess. sshd will require keyfiles to be:

  1. Reachable and readable by server.
  2. Writable only by user. And this means all folders (/var, /var/lib, and so on) should not be writable by any user or group besides root, wheel, and user that logs in.
Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
kworr
  • 1,055
  • 8
  • 14
  • as to #2, which means I can't share an authorized_keys file, which is what I'm trying to do to give both SSHD and NX access. Which means I should probably upgrade to OpenSSH 6.x. – xtian Sep 28 '13 at 22:03
  • Which raises another question. Why would NX server install instructions say to alter the SSHD AuthorizedKeysFile to this path in var when the directory structure has this home/.ssh pattern--seemingly to suggest sshd should look in this directory, the nx user's "home", for `authorized_keys` when the nx user is connecting? – xtian Sep 28 '13 at 22:08
  • I'm still working on the problem, but I have to say Kworr, your recommendation for non-daeminized debugging was perfect tool I needed to get moving on figuring out what's not working and what is working. Cheers! – xtian Sep 30 '13 at 00:24
  • Just as a note about the comment-before-last from xtian: NX server install indicates that the `nx` user's `authorized_keys` should be a path in `/var/`, because `nx` is the web server account — and that's not supposed to be a full login user with a `/home/nx/` directory. Linux has a long tradition (predating SELinux) of account-based partitioning for processes that run with elevated rights. Each daemon runs under a dedicated UID, they don't HAVE a login shell so even compromised they can't be used for remote access, and their "homedirs" are typically `/var/db/bind` `/var/www`, etc. – FeRD Jul 05 '19 at 04:10
2

This is a F'd question, because after using Kworr's tip to test sshd by stopping the daemon service and starting it manually in debug mode, the non-home path works just find (which is what you'd expect after "token expansion") Sorry guys.

Thus, to answer my own question: No, there isn't any reason authorized_keys can't be outside of home.

xtian
  • 321
  • 3
  • 15
1

The default is to use a file in the user's home directory (see below). The %h can be used explicitly to show that. Here it shows a list each path separated by a space...

What I would try is to change the permissions to 600. That's what I have my autorized_keys file set at in all my accounts. Bad permissions are translated in a Permissions Denied error. That gives you a chances to verify that your authorized_keys file does not include unwanted additions before fixing its permissions.

If different users are expected to make use of the same authorized_keys, then you've got a problem...

AuthorizedKeysFile
         Specifies the file that contains the public keys that can be used for user authentication.  The format is described in the AUTHORIZED_KEYS FILE
         FORMAT section of sshd(8).  AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup.  The following
         tokens are defined: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated, and %u is replaced by
         the username of that user.  After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory.
         Multiple files may be listed, separated by whitespace.  The default is “.ssh/authorized_keys .ssh/authorized_keys2”.
Alexis Wilke
  • 2,057
  • 1
  • 18
  • 33