Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Log-in Failures and requirements for PubkeyAuthentication

120 views
Skip to first unread message

nolo...@gmail.com

unread,
Aug 26, 2015, 12:44:07 AM8/26/15
to
I'm trying to configure an OpenSSH 7.1p server on OS X 10.5 (Leopard) to use only PubkeyAuthentication. The server was built with `--without-ssh1`. The configuration is partially successful. I can log-in, but other users cannot. I have it narrowed down to an interaction between authorized_keys and id_<type>.[.pub]. Now I am trying to understand what the requirements are.

Here's the short problem description (the longer one is below): If the user's public key is in authorized_keys only, then log-in fails. If the public key is in authorized_keys and on the file system at id_<type>.pub, the log-in succeeds.

Why are user failing to log-in when their public keys are only provided in authorized_keys? What are the requirements that I am missing?

**********

Longer description...

Everyone has their public keys in their respective `.ssh/authorized_keys` file. There are two differences between me and the other users. First, my `.ssh` directory includes both `id_<type>` and `id_<type>.pub`. Second, my authorized_keys file includes all four key types, while others authorized_keys only has the one public key they sent me.

If I delete my `id_<type>` and `id_<type>.pub`, and leave only the `.ssh/authorized_keys`, then I experience log-in failures, too. Here's what it looks like:

$ ssh -p 1522 jwalton@PowerMac
Permission denied (publickey,keyboard-interactive).

I'm fairly certain I have observed the requirements of AUTHORIZED_KEYS FILE FORMAT from sshd(8).

My sshd_config validates with -T, and includes the lines:

KbdInteractiveAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys

I've been through sshd(8) and sshd_config(5), but I don't see requirements more than authorized_keys is needed.

**********

From sshd_config(5):

PubkeyAuthentication
Specifies whether public key authentication is allowed. The
default is ``yes''. Note that this option applies to protocol
version 2 only.

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 rela-
tive to the user's home directory. Multiple files may be listed,
separated by whitespace. The default is ``.ssh/authorized_keys
.ssh/authorized_keys2''.

Graham Murray

unread,
Aug 26, 2015, 4:48:53 AM8/26/15
to
nolo...@gmail.com writes:

> I'm trying to configure an OpenSSH 7.1p server on OS X 10.5 (Leopard) to use only PubkeyAuthentication. The server was built with `--without-ssh1`. The configuration is partially successful. I can log-in, but other users cannot. I have it narrowed down to an interaction between authorized_keys and id_<type>.[.pub]. Now I am trying to understand what the requirements are.
>
> Here's the short problem description (the longer one is below): If the user's public key is in authorized_keys only, then log-in fails. If the public key is in authorized_keys and on the file system at id_<type>.pub, the log-in succeeds.
>
> Why are user failing to log-in when their public keys are only provided in authorized_keys? What are the requirements that I am missing?

What type of keys are they? openssh 7.1 disables DSS keys by default, so
if the users' keys are of type ssh-dss then unless you enable these in
sshd_config (by adding the line "PubkeyAcceptedKeyTypes +ssh-dss") the
users will not be able to connect.
0 new messages