[TriLUG] sshd configuration woes

Thu Nov 23 15:52:42 EST 2017

The 

On Thu, 23 Nov 2017 15:12:29 -0500
Aaron Joyner <aaron at joyner.ws> wrote:
> Based on your description, I suspect your .ssh/ directory has the
> wrong permissions, I believe it has to be 700 and
> the .ssh/authorized_keys* file needs to be 600 or similar.  Check the
> sshd_config man page to be sure. You can confirm this by inspecting
> the sshd logs,  though you might have to launch it in debug mode to
> see enough logging to be sure.

I looked at the file permissions and all seems to be order (700
for .ssh/ and 600 for authorized_keys, (and 644 for known_hosts)).  One
difference between my old configuration and the new configuration is
that the old setup used RSAAuthentication, which seems to have been
deprecated in the current sshd version included in CENTOS 7.

So, maybe this is a dumb (or naive) question:  In the old
configuration, we were using 2048 bit RSA keys with RSAAuthentication
turned on.  With the deprecation of RSAAuthentication, should we be
using some other type of key rather than an RSA key?  Making all the
users generate new keys wouldn't be that big of a deal. 

The man pages differentiate between rsa1 (used for Protocol 1) and rsa
which is (presumably) used with Protocol 2.  I'm pretty sure my old
setup was using Protocol 2, but it was originally setup in 2012).
Could it be that the rsa keys we have been using are really rsa1 keys
and the problem is there?

I should note I still have one OpenSuSE box running sshd and the public
key authentication works fine on that.

Paul

> 
> Best of luck,
> Aaron S. Joyner
> 
> 
> On Nov 23, 2017 7:07 PM, "Paul Boyle via TriLUG" <trilug at trilug.org>
> wrote:
> 
> Hi,
> 
> In my lab I've converted all of my OpenSuSE boxes to CENTOS 7 and I am
> running into some sshd configuration problems.  Users in my lab
> generate ssh keys  (RSA keys) to be able to scp archival data to a
> central backup host without having to type in a password.  This was
> working fine under my OpenSuSE computational environment, but under
> CENTOS 7, the public key authentication fails.  I'm having trouble
> figuring out what is going wrong, and would appreciate any pointers
> in getting this problem fixed.  I include a trace of an attempted ssh
> login from a user's account to the backup account (ssh -v
> backup at bravais):
> 
> maar:/~% ssh -v backup at bravais
> OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 58: Applying options for *
> debug1: Connecting to bravais [aaa.bbb.ccc.ddd] port 22.
> debug1: Connection established.
> debug1: identity file /home/maar/.ssh/id_rsa type 1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/maar/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/maar/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/maar/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/maar/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/maar/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/maar/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/maar/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.4
> debug1: Remote protocol version 2.0, remote software version
> OpenSSH_7.4 debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
> debug1: Authenticating to bravais:22 as 'backup'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha256
> debug1: kex: host key algorithm: rsa-sha2-512
> debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC:
> <implicit> compression: none
> debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC:
> <implicit> compression: none
> debug1: kex: curve25519-sha256 need=64 dh_need=64
> debug1: kex: curve25519-sha256 need=64 dh_need=64
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ssh-rsa
> SHA256:wS+uHBZWQWtkgjLdqfQ8FcwvcOnW2CUUz QpalQri5L8
> debug1: Host 'bravais' is known and matches the RSA host key.
> debug1: Found key in /home/maar/.ssh/known_hosts:2
> debug1: rekey after 134217728 blocks
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: rekey after 134217728 blocks
> debug1: SSH2_MSG_EXT_INFO received
> debug1: kex_input_ext_info:
> server-sig-algs=<rsa-sha2-256,rsa-sha2-512> debug1:
> SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can
> continue: publickey,password debug1: Next authentication method:
> publickey debug1: Offering RSA public key: /home/maar/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/maar/.ssh/id_dsa
> debug1: Trying private key: /home/maar/.ssh/id_ecdsa
> debug1: Trying private key: /home/maar/.ssh/id_ed25519
> debug1: Next authentication method: password
> backup at bravais's password:
> 
> I don't quite understand what the output is telling me.  Is it that
> the sshd server isn't accepting RSA keys?
> 
> Thanks,
> 
> Paul
> --
> This message was sent to: Aaron S. Joyner <aaron at joyner.ws>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from
> that address.
> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  : https://www.trilug.org/
> mailman/options/trilug/aaron%40joyner.ws
> Welcome to TriLUG: http://trilug.org/welcome

-- 
Paul D. Boyle, Ph. D.
Manager, X-ray Facility
Department of Chemistry
Western University
London, ON N6A 5B7
Canada
GPG Fingerprint: 8ECE 516D 9046 FE83 4A46  7E8E D720 555D 8CC3 EC6B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://www.trilug.org/pipermail/trilug/attachments/20171123/b8305378/attachment.pgp>