[TriLUG] sshd configuration woes (SOLVED)

Thu Nov 23 16:12:51 EST 2017

The my sshd problems are solved.  It turns out it wasn't sshd problem,
but a SELinux problem.  I (finally) noticed that SELinux was giving
some sort of notification.  I looked at it and I saw that SELinux was
preventing something related to ssh from happening.  I turned off
SELinux (I don't know why I installed in the first place) and voila!
problem goes away. Yay.

On Thu, 23 Nov 2017 15:52:42 -0500
Paul Boyle via TriLUG <trilug at trilug.org> wrote:

> 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/7cf5bda8/attachment.pgp>