SSH not honoring use of ~/.ssh/authorized_keys

Bug #1858285 reported by Timothy Yates
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Have tested this successfully on other distros, used the same steps to updating /etc/ssh/sshd_config but SSH will not honor the use of ~/.ssh/authorized_keys.

Simple test

mkdir -m 700 ~/.ssh
cd ~/.ssh
ssh-keygen -t rsa -b 4096
press enter to accept the defaults and empty passphrase
cp id_rsa.pub authorized_keys

ssh localhost /bin/date
works

mv id-rsa $(hostname -s)
mv id-rsa.pub $(hostname -s).pub
ssh localhost /bin/date
**fails. this works on CentOS, RHEL

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: openssh-server 1:8.0p1-6build1
ProcVersionSignature: Ubuntu 5.3.0-1014.16-raspi2 5.3.10
Uname: Linux 5.3.0-1014-raspi2 aarch64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: arm64
Date: Sat Jan 4 12:42:58 2020
ExecutablePath: /usr/sbin/sshd
ProcEnviron:
 LANG=C.UTF-8
 PATH=(custom, no user)
SourcePackage: openssh
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Timothy Yates (tdy-boc) wrote :
Revision history for this message
Timothy Yates (tdy-boc) wrote :

Also, i just tested this on Ubuntu 17.10 "Artful" as well so it seems to not be a problem for 19.10.

Revision history for this message
Timothy Yates (tdy-boc) wrote :

mistyped, it's a problem in 17.10 as well so the same problem has persisted for a few releases.

Revision history for this message
Timothy Yates (tdy-boc) wrote :

Update, possible workaround. Still a bug that needs permanently fixed as other distros honor ~/.ssh/authorized_keys properly with settings in /etc/ssh/sshd_config

use a directive within the ~/.ssh/config file but seems it requires both private and public keys to be present/exchanged for the required hosts.

host short_hostname
hostname IPaddr_or_FQDN
user username
port 22 or other port if not 22
identityfile /home/username/.ssh/private_key_filename

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

From man ssh:
     -i identity_file
      Selects a file from which the identity (private key) for public key authentication is read. The default is ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files). If no certificates have been explicitly specified by the CertificateFile directive, ssh will also try to load certificate information from the filename obtained by appending -cert.pub to identity filenames.

Accodring to that the above reported behavior is correct.

I tried your case and found Fedora and Centos work the same way as Ubuntu.
Note: filename is id_rsa not id-rsa
Didn't work with "localhost" nor with a real hostname set in /etc/hosts

This doesn't seem "SSH not honoring use of ~/.ssh/authorized_keys" to me.
What you want seems to me more like "Try target hostname as -i argument ~/.ssh/<hostname>.pub" is that right?

You might also have an ssh-agent set up, that will pick up the key on first use and might try it.

Maybe you happen to have that in your own ssh config?
What you (seem to) want can be achieved by this entry in /etc/ssh/ssh_config:
   IdentityFile ~/.ssh/%h
But that would just be a local config and not a bug.
It might be discussed as default config, but people don't want to use keys by default too easily.
All tested systems have no difference in their default configs in regard to IdentityFile.
Do the systems that you report as working better have anything in /etc/ssh/ssh_config for it?

Changed in openssh (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for openssh (Ubuntu) because there has been no activity for 60 days.]

Changed in openssh (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.