OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config?
grantk...@operamail.com
@ client
which ssh
/usr/local/bin/ssh
ssh -v
OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014
@ server
which sshd
/usr/local/bin/sshd
sshd -v
unknown option -- V
OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014
usage: sshd [-46DdeiqTt] [-b bits] [-C connection_spec] [-c host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-k key_gen_time] [-o option] [-p port]
I have configured for hostbased authentication
client ssh_config
...
PreferredAuthentications hostbased,publickey
HostbasedAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
...
server sshd_config
...
AuthenticationMethods hostbased,publickey
HostbasedAuthentication yes
HostbasedUsesNameFromPacketOnly yes
PubkeyAuthentication yes
PasswordAuthentication no
...
on the server, because I'm not entirely sure where to put it yet
echo "client.DOMAIN.COM" > /etc/shosts.equiv
echo "client.DOMAIN.COM" > /usr/local/etc/shosts.equiv
when I try to connect
ssh -vvv server.DOMAIN.COM
hostname auth fails
...
Permission denied (hostbased).
debug logs return
client log
...
debug1: Authentications that can continue: hostbased
debug3: start over, passed a different list hostbased
debug3: preferred hostbased,publickey
debug3: authmethod_lookup hostbased
debug3: remaining preferred: publickey,password
debug3: authmethod_is_enabled hostbased
debug1: Next authentication method: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug2: we sent a hostbased packet, wait for reply
debug1: Authentications that can continue: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug2: we sent a hostbased packet, wait for reply
debug1: Authentications that can continue: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug2: we sent a hostbased packet, wait for reply
debug1: Authentications that can continue: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug2: we sent a hostbased packet, wait for reply
debug1: Authentications that can continue: hostbased
debug1: No more client hostkeys for hostbased authentication.
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (hostbased).
server log
...
Jan 9 07:37:31 server sshd[19835]: debug2: input_userauth_request: try method hostbased [preauth]
Jan 9 07:37:31 server sshd[19835]: debug1: userauth_hostbased: cuser root chost client.DOMAIN.COM. pkalg ssh-ed25519 slen 83 [preauth]
Jan 9 07:37:31 server sshd[19835]: debug3: mm_key_allowed entering [preauth]
Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_send entering: type 22 [preauth]
Jan 9 07:37:31 server sshd[19835]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_receive_expect entering: type 23 [preauth]
Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_receive entering [preauth]
Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_receive entering
Jan 9 07:37:31 server sshd[19835]: debug3: monitor_read: checking request 22
Jan 9 07:37:31 server sshd[19835]: debug3: mm_answer_keyallowed entering
Jan 9 07:37:31 server sshd[19835]: debug3: mm_answer_keyallowed: key_from_blob: 0x7cd1262cbc76
Jan 9 07:37:31 server sshd[19835]: debug2: userauth_hostbased: chost client.DOMAIN.COM. resolvedname xxxx:xxx:xxxx:xxx::10 ipaddr xxxx:xxx:xxxx:xxx::10
Jan 9 07:37:31 server sshd[19835]: debug2: stripping trailing dot from chost client.DOMAIN.COM.
Jan 9 07:37:31 server sshd[19835]: debug2: auth_rhosts2: clientuser root hostname client.DOMAIN.COM ipaddr client.DOMAIN.COM
Jan 9 07:37:31 server sshd[19835]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Jan 9 07:37:31 server sshd[19835]: debug1: restore_uid: 0/0
Jan 9 07:37:31 server sshd[19835]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Jan 9 07:37:31 server sshd[19835]: debug1: restore_uid: 0/0
Jan 9 07:37:31 server sshd[19835]: Failed hostbased for root from xxxx:xxx:xxxx:xxx::10 port 40452 ssh2: ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx, client user "root", client host "client.DOMAIN.COM"
Jan 9 07:37:31 server sshd[19835]: debug3: mm_answer_keyallowed: key 0x7cd1262cbc76 is not allowed
Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_send entering: type 23
Jan 9 07:37:31 server sshd[19835]: debug2: userauth_hostbased: authenticated 0 [preauth]
Jan 9 07:37:31 server sshd[19835]: debug3: userauth_finish: failure partial=0 next methods="hostbased" [preauth]
...
I see that
mm_answer_keyallowed: key 0x7cd1262cbc76 is not allowed
but am not clear what key that is. grep'ing for '7cd1262cbc76' turns up nothing.
What's wrong or missing in my config?
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Tim Rice
|
| client ssh_config
| ...
| PreferredAuthentications hostbased,publickey
| HostbasedAuthentication yes
| PubkeyAuthentication yes
| PasswordAuthentication no
| ...
|
| server sshd_config
| ...
| AuthenticationMethods hostbased,publickey
| HostbasedAuthentication yes
| HostbasedUsesNameFromPacketOnly yes
| PubkeyAuthentication yes
| PasswordAuthentication no
| ...
|
| on the server, because I'm not entirely sure where to put it yet
|
| echo "client.DOMAIN.COM" > /etc/shosts.equiv
| echo "client.DOMAIN.COM" > /usr/local/etc/shosts.equiv
Host *
HostbasedAuthentication yes
EnableSSHKeysign yes
NoHostAuthenticationForLocalhost yes
NoHostAuthenticationForLocalhost is not necessary.
The one you are missing is EnableSSHKeysign.
Additionally, you made no mention of your ssh_known_hosts files. Make
sure the client's public keys are in the server's ssh_known_hosts file.
--
Tim Rice Multitalents
t...@multitalents.net
Iain Morgan
authentication before you've gotten a single form of authentication
working. In addition, root is too much of a special case for useful
debugging; try your tests as a regular user.
As Tim Rice noted, you will need to set EnableSSHKeysign in the
system--wide client configuration for hostbased authentication to work
for non-root users.
--
Iain Morgan
grantk...@operamail.com
On Fri, Jan 9, 2015, at 10:48 AM, Tim Rice wrote:
> My ssh_config has
> Host *
> HostbasedAuthentication yes
> EnableSSHKeysign yes
> NoHostAuthenticationForLocalhost yes
>
> NoHostAuthenticationForLocalhost is not necessary.
> The one you are missing is EnableSSHKeysign.
>
> Additionally, you made no mention of your ssh_known_hosts files. Make
> sure the client's public keys are in the server's ssh_known_hosts file.
> To begin with, don't complicate the situation by requiring two forms of
> authentication before you've gotten a single form of authentication
> working. In addition, root is too much of a special case for useful
> debugging; try your tests as a regular user.
>
> As Tim Rice noted, you will need to set EnableSSHKeysign in the
> system--wide client configuration for hostbased authentication to work
> for non-root users.
client ssh_config
...
- PreferredAuthentications hostbased,publickey
+ PreferredAuthentications hostbased
HostbasedAuthentication yes
PubkeyAuthentication yes
+ PubkeyAuthentication no
PasswordAuthentication no
...
EnableSSHKeysign yes (note: this had already been 'in there' --- just further down in the config)
...
server sshd_config
...
- AuthenticationMethods hostbased,publickey
+ AuthenticationMethods hostbased
HostbasedAuthentication yes
- HostbasedUsesNameFromPacketOnly yes
+ #HostbasedUsesNameFromPacketOnly yes
- PubkeyAuthentication yes
+ PubkeyAuthentication no
PasswordAuthentication no
...
I already have the server's key in the known hosts file on the client.
@ client
cat ssh_config
...
GlobalKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts
UserKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts
...
ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts
and @server
ssh-keyscan -t ed25519 client.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts
with all of the above, the hostbased auth connnect still fails just as before,
ssh server.DOMAIN.COM
...
Permission denied (hostbased).
grantk...@operamail.com
as root (as before)
ssh server.DOMAIN.COM
Permission denied (hostbased).
instead, as my user, fails differently for some reason,
ssh server.DOMAIN.COM
...
no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
ssh_keysign: no reply
key_sign failed
Permission denied (hostbased).
and verbose
ssh server.DOMAIN.COM -vvv
debug1: Authentications that can continue: hostbased
debug3: start over, passed a different list hostbased
debug3: preferred hostbased
debug1: Next authentication method: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug1: permanently_drop_suid: 1000
debug1: Authentications that can continue: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug1: permanently_drop_suid: 1000
debug1: Authentications that can continue: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug1: permanently_drop_suid: 1000
debug1: Authentications that can continue: hostbased
debug2: userauth_hostbased: chost client.DOMAIN.COM.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug1: permanently_drop_suid: 1000
no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
ssh_keysign: no reply
key_sign failed
debug1: No more authentication methods to try.
Iain Morgan
first get each of the two authentication methods working separately
before you set AuthenticationMethods in sshd_config to require both
hostbased and public-key authentication. While you are debugging your
issue, I would recommend leaving PreferredAuthentications at the default
and leaving the various authentication methods enabled.
When you invoke ssh with the -v option and an authentication method
(such as hostbased authentication) fails, the client can display some
diagnostic information from the server -- provided that you are able to
successfully authenticate by some other method, such as public-key
authentication.
> EnableSSHKeysign yes (note: this had already been 'in there' --- just further down in the config)
> ...
>
> server sshd_config
> ...
> - AuthenticationMethods hostbased,publickey
> + AuthenticationMethods hostbased
> HostbasedAuthentication yes
> - HostbasedUsesNameFromPacketOnly yes
> + #HostbasedUsesNameFromPacketOnly yes
> - PubkeyAuthentication yes
> + PubkeyAuthentication no
> PasswordAuthentication no
> ...
>
> I already have the server's key in the known hosts file on the client.
>
the _client_ in the ssh_known_hosts file (or potentially in the user's
~/.ssh/known_hosts file).
>
> cat ssh_config
> ...
> GlobalKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts
> UserKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts
> ...
>
> ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts
>
> and @server
>
> ssh-keyscan -t ed25519 client.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts
>
> with all of the above, the hostbased auth connnect still fails just as before,
>
> ssh server.DOMAIN.COM
> ...
> Permission denied (hostbased).
shosts.equiv and that the ssh-keysign binary is setuid root (assuming
that you are now trying as a regular user).
Damien recently added some additional debugging messages for hostbased
authentication, so if you continue to have problems you could try
building a recent snapshot for the server.
Hostbased authentication can be a bit thorny to get right since it
depends upon multiple files being correct. Try to keep things simple
initially to avoid unnecessary complications: Only change those options
in the client and server that are necessary to enable hostbased
authentication. make sure that you are using the right location for the
shosts.equiv file and that the entry in the file matches the hostname
(ususally teh fully-qualified hostname) that the client uses. The server
must have the clients public-key in the ssh_known_hosts file, and the
name must also match the client.
In most cases, problems with hostbased authentication end up being due
to either a typo or an inconsistency between the name claimed by the
client and the name that the server associates with the client's IP
address.
--
Iain Morgan
grantk...@operamail.com
On Fri, Jan 9, 2015, at 12:34 PM, Mark Hahn wrote:
> >> The one you are missing is EnableSSHKeysign.
>
> I suppose it's worth asking: is your ssh-keysign suid root
> (and are the permissions on your host keys sufficiently tight)?
Note that everything works correctly with other auth methods: pubkey, password, ...
I suspect key perms issues would've come up there.
Here's also the ssk-keysign perms
client
ls -al /usr/local/libexec/ssh-keysign
-rwsr-xr-x+ 1 root root 459K Oct 11 06:51 /usr/local/libexec/ssh-keysign*
ls -al /usr/local/etc/ssh/ssh.client.ed25519*
-rw-------+ 1 root root 517 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519
-rw-r--r--+ 1 root root 107 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519.pub
server
ls -al /usr/local/libexec/ssh-keysign
-rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign*
ls -al /usr/local/etc/ssh/ssh.server.ed25519*
-rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519
-rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub
> > ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts
>
> fine, though it's worth verifying that these are the files being used
> by the (non-default, right) sshd and ssh (client) that you're using.
i have
@ server
which sshd
/usr/local/sbin/sshd
systemctl status sshd
sshd.service - OpenSSH Daemon
Loaded: loaded (/etc/systemd/system/sshd.service; enabled)
Active: active (running) since Fri 2015-01-09 12:57:12 PST; 2s ago
Main PID: 21534 (sshd)
CGroup: /system.slice/sshd.service
├─ 4662 sshd: root@pts/0
├─ 4664 -bash
├─21534 /usr/local/sbin/sshd -D -f /usr/local/etc/ssh/sshd_config
└─21541 systemctl status sshd
ps ax | grep sshd_config
20989 ? Ss 0:00 /usr/local/sbin/sshd -D -f /usr/local/etc/ssh/sshd_config
and
@ client
which ssh
/usr/local/bin/ssh
ssh server.DOMAIN.COM -vvv
...
debug3: load_hostkeys: loading entries for host "server.DOMAIN.COM" from file "/usr/local/etc/ssh/ssh_known_hosts"
debug3: load_hostkeys: found key type ED25519 in file /usr/local/etc/ssh/ssh_known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "server.DOMAIN.COM" from file "/usr/local/etc/ssh/ssh_known_hosts"
debug3: load_hostkeys: found key type ED25519 in file /usr/local/etc/ssh/ssh_known_hosts:2
debug3: load_hostkeys: loaded 1 keys
...
> > Permission denied (hostbased).
Iain Morgan
> @client
>
> as root (as before)
>
> ssh server.DOMAIN.COM
> Permission denied (hostbased).
>
> instead, as my user, fails differently for some reason,
>
> ssh server.DOMAIN.COM
> ...
> no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
> ssh_keysign: no reply
> key_sign failed
> Permission denied (hostbased).
>
you are trying to use ssh from /usr/local/bin, I take it that it is a
local build. As such, some of the files may not be properly located.
You can check the location of the ssh-keysign binary by running strings
on the ssh executable and grep'ing for ssh-keysign. I expect that it
will be /usr/local/libexec/ssh-keysign. Make sure that it is setuid
root.
You can then run strings on the ssh-keysign executable and grep for
ssh_host ed25519 to confirm the expected location for the host key. Make
sure that the key can be found in the expected location, and that the
public key is world-readable, but that the private key is readable only
by root.
Note, if you do not see a reference to ssh_host_ed25519 in the above
strings output, the ssh-keysign executable is from an older distribution
that does not support ED25519.
Given that possibility, you might try adding the ECDSA key for the
client to the ssh_known_hosts file on the server.
--
Iain Morgan
grantk...@operamail.com
On Fri, Jan 9, 2015, at 01:02 PM, Iain Morgan wrote:
> I suppose I wan't specific enough; I was recommending that you should
> first get each of the two authentication methods working separately
> before you set AuthenticationMethods in sshd_config to require both
> hostbased and public-key authentication. While you are debugging your
> issue, I would recommend leaving PreferredAuthentications at the default
> and leaving the various authentication methods enabled.
Sorry, perhaps I'm being thick. I don't get it.
pubkey auth works fine.
password auth works fine.
pubkey,password works fine
hostbased &/or hostbased,anything_else does not.
What config would you like me to try?
> When you invoke ssh with the -v option and an authentication method
> (such as hostbased authentication) fails, the client can display some
> diagnostic information from the server -- provided that you are able to
> successfully authenticate by some other method, such as public-key
> authentication.
As above, if hostbased is enabled, NOTHING works.
> > I already have the server's key in the known hosts file on the client.
> >
>
> But, for hostbased authentication, the _server_ must have the key for
> the _client_ in the ssh_known_hosts file (or potentially in the user's
> ~/.ssh/known_hosts file).
I've now done @ both server & @client
ssh-keyscan -t ed25519 client.DOMAIN.COM > /usr/local/etc/ssh/ssh_known_hosts
ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts
It makes no difference; failure as reported.
> You may want to check that you are using the right location for your
> shosts.equiv and that the ssh-keysign binary is setuid root (assuming
> that you are now trying as a regular user).
already done
man 5 sshd_config | grep shosts
Specifies whether or not the server will attempt to perform a reverse name lookup when matching the name in the ~/.shosts, ~/.rhosts, and /etc/hosts.equiv files during HostbasedAuthentication. A setting of “yes” means
Specifies that .rhosts and .shosts files will not be used in RhostsRSAAuthentication or HostbasedAuthentication.
---> /etc/hosts.equiv and /usr/local/etc/ssh/shosts.equiv are still used. The default is “yes”.
@ both server & client
cat /usr/local/etc/ssh/shosts.equiv
client.DOMAIN.COM
server.DOMAIN.COM
> Damien recently added some additional debugging messages for hostbased
> authentication, so if you continue to have problems you could try
> building a recent snapshot for the server.
how recently? these are tarball builds
-rw-rwxr--+ 1 root root 1.3M Oct 6 15:34 openssh-6.7p1.tar.gz*
newer that the release, I presume?
> Hostbased authentication can be a bit thorny to get right since it
> depends upon multiple files being correct. Try to keep things simple
> initially to avoid unnecessary complications: Only change those options
> in the client and server that are necessary to enable hostbased
> authentication.
I start with a KNOWN TO WORK pubkey,password config, then ONLY change to add the hostbased auth.
And then it fails.
Reverse JUST those changes, and it succeeds.
> make sure that you are using the right location for the
> shosts.equiv file and that the entry in the file matches the hostname
> (ususally teh fully-qualified hostname) that the client uses. The server
> must have the clients public-key in the ssh_known_hosts file, and the
> name must also match the client.
all hostnames a FQDNs.
all have correct/verified forward & reverse DNS entries.
both IPv4 & IPv6 ssh, from any to all machines works using pubkey/password auth. In all cases, on alll machines, hostbased auth fails, as above.
> In most cases, problems with hostbased authentication end up being due
> to either a typo or an inconsistency between the name claimed by the
> client and the name that the server associates with the client's IP
> address.
everything matches afaict
@ client
hostname
client.DOMAIN.COM
hostname -s
client
hostname -f
client.DOMAIN.COM
dig A `hostname` +short
192.168.1.65
dig AAAA `hostname` +short
xxxx:xxx:xxxx:xxx::65
host 192.168.1.65
65.1.168.192.in-addr.arpa domain name pointer client.DOMAIN.COM.
host xxxx:xxx:xxxx:xxx::65
65.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer client.DOMAIN.COM.
dig A server.DOMAIN.COM +short
192.168.1.68
dig AAAA server.DOMAIN.COM +short
xxxx:xxx:xxxx:xxx::68
host 192.168.1.68
68.1.168.192.in-addr.arpa domain name pointer server.DOMAIN.COM.
host xxxx:xxx:xxxx:xxx::68
68.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer server.DOMAIN.COM.
host client.DOMAIN.COM
client.DOMAIN.COM has address 192.168.1.65
client.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::65
host server.DOMAIN.COM
server.DOMAIN.COM has address 192.168.1.68
server.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::68
ssh-keyscan -t ed25519 client.DOMAIN.COM
# client.DOMAIN.COM SSH-2.0-OpenSSH_6.7
client.DOMAIN.COM ssh-ed25519 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ssh-keyscan -t ed25519 server.DOMAIN.COM
# server.DOMAIN.COM SSH-2.0-OpenSSH_6.7
server.DOMAIN.COM ssh-ed25519 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
@ server
hostname
server.DOMAIN.COM
hostname -s
server
hostname -f
server.DOMAIN.COM
dig A `hostname` +short
192.168.1.68
dig AAAA `hostname` +short
xxxx:xxx:xxxx:xxx::68
host 192.168.1.68
68.1.168.192.in-addr.arpa domain name pointer server.DOMAIN.COM.
host xxxx:xxx:xxxx:xxx::68
68.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer server.DOMAIN.COM.
dig A client.DOMAIN.COM +short
192.168.1.65
dig AAAA client.DOMAIN.COM +short
xxxx:xxx:xxxx:xxx::65
host 192.168.1.65
65.1.168.192.in-addr.arpa domain name pointer client.DOMAIN.COM.
host xxxx:xxx:xxxx:xxx::65
65.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer desk.DOMAIN.COM.
host client.DOMAIN.COM
client.DOMAIN.COM has address 192.168.1.65
client.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::65
host server.DOMAIN.COM
server.DOMAIN.COM has address 192.168.1.68
server.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::68
ssh-keyscan -t ed25519 client.DOMAIN.COM
# client.DOMAIN.COM SSH-2.0-OpenSSH_6.7
client.DOMAIN.COM ssh-ed25519 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ssh-keyscan -t ed25519 server.DOMAIN.COM
# server.DOMAIN.COM SSH-2.0-OpenSSH_6.7
server.DOMAIN.COM ssh-ed25519 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
grantk...@operamail.com
On Fri, Jan 9, 2015, at 01:40 PM, Iain Morgan wrote:
> So, that indicates that you have a problem with your client setup. Since
> you are trying to use ssh from /usr/local/bin, I take it that it is a
> local build. As such, some of the files may not be properly located.
./configure \
--prefix="/usr/local" \
--sysconfdir="/usr/local/etc/ssh" \
--libdir="/usr/local/lib64" \
--with-ssl-dir="/usr/local/ssl" \
--with-md5-passwords \
--with-xauth=/usr/bin/xauth \
--with-pam
> You can check the location of the ssh-keysign binary by running strings
> on the ssh executable and grep'ing for ssh-keysign. I expect that it
> will be /usr/local/libexec/ssh-keysign. Make sure that it is setuid
> root.
> ssh_host ed25519 to confirm the expected location for the host key. Make
> sure that the key can be found in the expected location, and that the
> public key is world-readable, but that the private key is readable only
> by root.
/usr/local/etc/ssh/ssh_host_ed25519_key
That's NOT the name/location of the key.
On the client
grep Identity /usr/local/etc/ssh/ssh_config
IdentityFile /usr/local/etc/ssh/ssh.client.ed25519
and on the server
grep HostKey /usr/local/etc/ssh/sshd_config
HostKey /usr/local/etc/ssh/ssh.server.ed25519
As reported above
client
ls -al /usr/local/etc/ssh/ssh.client.ed25519*
-rw-------+ 1 root root 517 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519
-rw-r--r--+ 1 root root 107 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519.pub
server
-rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519
-rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub
> Note, if you do not see a reference to ssh_host_ed25519 in the above
> strings output, the ssh-keysign executable is from an older distribution
> that does not support ED25519.
ssh -V
/usr/bin/ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1j-fips 15 Oct 2014
> Given that possibility, you might try adding the ECDSA key for the
> client to the ssh_known_hosts file on the server.
Iain Morgan
> Hi
>
> On Fri, Jan 9, 2015, at 12:34 PM, Mark Hahn wrote:
> > >> The one you are missing is EnableSSHKeysign.
> >
> > I suppose it's worth asking: is your ssh-keysign suid root
> > (and are the permissions on your host keys sufficiently tight)?
>
> Note that everything works correctly with other auth methods: pubkey, password, ...
> I suspect key perms issues would've come up there.
Not so, only hostbased authentication uses the client's host keys, and
it is likewise the only method that uses ssh-keysign. Further,
ssh-keysign is only used for non-root users.
>
> Here's also the ssk-keysign perms
>
> client
>
> ls -al /usr/local/libexec/ssh-keysign
> -rwsr-xr-x+ 1 root root 459K Oct 11 06:51 /usr/local/libexec/ssh-keysign*
>
> ls -al /usr/local/etc/ssh/ssh.client.ed25519*
> -rw-------+ 1 root root 517 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519
> -rw-r--r--+ 1 root root 107 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519.pub
>
Err, those _should_ be ssh_host_ed25519 and ssh_host_ed25519.pub.
>
> server
>
> ls -al /usr/local/libexec/ssh-keysign
> -rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign*
>
> ls -al /usr/local/etc/ssh/ssh.server.ed25519*
> -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519
> -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub
>
Renaming the keys in your output only serves to complicate matters for
those who are taking time to try to help you. Further, ssh-keysign plays
no role on the server and the server's keys are not a factor in the
problem you are facing.
>
> > > ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts
> >
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-...@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Iain Morgan
grantk...@operamail.com
On Fri, Jan 9, 2015, at 02:26 PM, Iain Morgan wrote:
> > server
> >
> > ls -al /usr/local/libexec/ssh-keysign
> > -rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign*
> >
> > ls -al /usr/local/etc/ssh/ssh.server.ed25519*
> > -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519
> > -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub
> >
>
> Renaming the keys in your output only serves to complicate matters for
> those who are taking time to try to help you.
Those are the actual keynames, and locations, that I've been using for years, renewed, as you can see by the date, just last May
grantk...@operamail.com
> > On the client
> >
> > grep Identity /usr/local/etc/ssh/ssh_config
> > IdentityFile /usr/local/etc/ssh/ssh.client.ed25519
>
> presumably that's what ssh-keysign is looking for,
> not a *user* key.
That's on the *client*. note that it's in ssh_config
cat /usr/local/etc/ssh/ssh_config
...
Host *
IdentityFile /usr/local/etc/ssh/ssh.client.ed25519
...
On the *server*, in sshd_config it's
cat /usr/local/etc/ssh/sshd_config
...
HostKey /usr/local/etc/ssh/ssh.server.ed25519
...
Mark Hahn
>>> grep Identity /usr/local/etc/ssh/ssh_config
>>> IdentityFile /usr/local/etc/ssh/ssh.client.ed25519
>>
>> shouldn't this be HostKey in sshd_config?
>> presumably that's what ssh-keysign is looking for,
>> not a *user* key.
>
> That's on the *client*. note that it's in ssh_config
non-default (client) host key's location?
> cat /usr/local/etc/ssh/ssh_config
> ...
> Host *
> IdentityFile /usr/local/etc/ssh/ssh.client.ed25519
> On the *server*, in sshd_config it's
>
> cat /usr/local/etc/ssh/sshd_config
> ...
> HostKey /usr/local/etc/ssh/ssh.server.ed25519
regards, mark hahn
Iain Morgan
>
>
> On Fri, Jan 9, 2015, at 02:26 PM, Iain Morgan wrote:
> > > server
> > >
> > > ls -al /usr/local/libexec/ssh-keysign
> > > -rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign*
> > >
> > > ls -al /usr/local/etc/ssh/ssh.server.ed25519*
> > > -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519
> > > -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub
> > >
> >
> > Renaming the keys in your output only serves to complicate matters for
> > those who are taking time to try to help you.
>
> How so? What's being complicated? I haven't renamed anything "in my output".
>
> Those are the actual keynames, and locations, that I've been using for years, renewed, as you can see by the date, just last May
It looks like you need to read the manual files. While the server
permits you to specify the names and locations of the host keys, the
client does NOT. The locations are hard-coded into ssh and ssh-keysign
at build time; using IdentitryFile does not alter this.
As noted before, only hostbased authentication uses the client's host
keys, so renaming the keys would not have impacted other authentication
methods.
--
Iain Morgan
grantk...@operamail.com
On Fri, Jan 9, 2015, at 03:13 PM, Iain Morgan wrote:
> So, how many barrels do you have in that shotgun pointed at your foot?
>
> It looks like you need to read the manual files.
Thanks anayway. Moving on.
Mark Hahn
has the hostkey paths hardcoded.
would it be bad if this were runtime-configurable?
Tim Rice
| @client
|
| as root (as before)
|
| ssh server.DOMAIN.COM
| Permission denied (hostbased).
|
| instead, as my user, fails differently for some reason,
|
| ssh server.DOMAIN.COM
| ...
| no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
| ssh_keysign: no reply
| key_sign failed
| Permission denied (hostbased).
here, hostbased does not work as root but does as a regular user.
Another thing that has not been mentioned in the thread so far is the
need for properly configured DNS when using hostbased.
If you nslookup the client does it show a single IP?
If you nslookup the IP, does it return the client name?
Does the name and IP match what is in ssh_known_hosts on the server?
Does the client's entry in the server's ssh_known_hosts file have both
the hostname and the FQDN?
If you nslookup the server does it show a single IP?
If you nslookup the IP, does it return the server name?