grantksupport at operamail.com
2015-Jan-09 20:07 UTC
OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config?
Hi, 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.On Fri, Jan 9, 2015, at 11:40 AM, Iain Morgan wrote:> 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.I edited configs to 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).
grantksupport at operamail.com
2015-Jan-09 20:22 UTC
OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config?
@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). and verbose ssh server.DOMAIN.COM -vvv ... debug1: Authentications that can continue: hostbased debug3: start over, passed a different list hostbased debug3: preferred hostbased debug3: authmethod_lookup hostbased debug3: authmethod_is_enabled hostbased debug1: Next authentication method: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 1000 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 1000 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 1000 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called 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 debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (hostbased).
Iain Morgan
2015-Jan-09 21:02 UTC
OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config?
On Fri, Jan 09, 2015 at 12:07:38 -0800, grantksupport at operamail.com wrote:> Hi, > > 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. > > > On Fri, Jan 9, 2015, at 11:40 AM, Iain Morgan wrote: > > 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. > > I edited configs to > > client ssh_config > ... > - PreferredAuthentications hostbased,publickey > + PreferredAuthentications hostbased > HostbasedAuthentication yes > PubkeyAuthentication yes > + PubkeyAuthentication no > PasswordAuthentication no > ...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. 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. >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).> @ 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).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). 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
Iain Morgan
2015-Jan-09 21:40 UTC
OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config?
On Fri, Jan 09, 2015 at 12:22:00 -0800, grantksupport at operamail.com wrote:> @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). >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. 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
grantksupport at operamail.com
2015-Jan-09 21:50 UTC
OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config?
Hi, 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
Tim Rice
2015-Jan-09 23:20 UTC
OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config?
On Fri, 9 Jan 2015, grantksupport at operamail.com wrote: | @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). I use hostbased auth here extensively and have for years. On my machines 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? -- Tim Rice Multitalents tim at multitalents.net