On 5/8/2015 7:22 AM, Valeri Galtsev wrote:> On Fri, May 8, 2015 8:58 am, James B. Byrne wrote: >> While attempting to debug something else I ran across this: >> >> ssh -vvv somehost >> . . . >> debug1: Connection established. >> debug1: permanently_set_uid: 0/0 >> debug1: identity file /root/.ssh/identity type -1 >> debug1: identity file /root/.ssh/identity-cert type -1 >> debug3: Not a RSA1 key file /root/.ssh/id_rsa. >> debug2: key_type_from_name: unknown key type '-----BEGIN' >> debug3: key_read: missing keytype >> debug3: key_read: missing whitespace >> . . . >> >> However if I verify the key I see this: >> >> ssh-keygen -l -f ~/.ssh/id_rsa.pub >> 4096 08:70:3b:92:4c:96:1c:6a:03:a4:ae:66:8d:9e:6c:93 >> /root/.ssh/id_rsa.pub (RSA) >> >> Which seems ok to me. The permissions also seem ok: >> >> .ssh]# ll >> total 40 >> -rw-------. 1 root root 3863 Oct 11 2012 authorized_keys >> -rw-------. 1 root root 3243 Aug 9 2012 id_rsa >> -rw-r--r--. 1 root root 757 Aug 9 2012 id_rsa.pub >> -rw-r--r--. 1 root root 11071 May 8 09:42 known_hosts > When checking permissions don't forget to check permissions on parent > directories (all levels up to the /). E.g., if your home directory is > world writable, ssh will ignore authorized_keys as well, as the above > permissions _can_ be changed by everybody. The same is true if / is > ridiculously world writable (I've never seen that myself, but I do mean: > check all levels of what the path ~/.ssh is). > > It's not clear from your description, but I'm sure you have the following > right: id_rsa and id_rsa.pub is a pair you have on local machine (the one > you ssh from). autorized_keys is on the remote machine (the one you > connect to), and it contains the contents of id_rsa.pub that you have on > local machine (i.e. you copied id_rsa.pub from local machine to remote and > dumped it into ~/.ssh/autorized_keys on it). > > I would also check that in sshd config file (usually: > /etc/ssh/sshd_config) on remote machine you do have line > > PubkeyAuthentication yes > > Good luck! > > Valeri > >> The password-less connections complete in any case but I am perplexed >> as to what is the problem with the root identity key that ssh is >> reporting. >> >> Can anyone explain to me what this means? >> >>Also check that the selinux context on all files and directories are set to "ssh_home_t". From the home dir: #chcon -R -t ssh_home_t .ssh
chmod 0700 .ssh chmod 0600 .ssh/* Keys can fail if you don't have that setup correctly. Also do: grep sshd /var/log/audit/audit.log| audit2allow -m sshd # Will let you see what modules it will create. grep sshd /var/log/audit/audit.log| audit2allow -M sshd # Creates the modules semodule -I sshd.pp grep ssh /var/log/audit/audit.log| audit2allow -m ssh # Will let you see what modules it will create. grep ssh /var/log/audit/audit.log| audit2allow -M ssh # Creates the modules semodule -I ssh.pp sshd is the server; ssh is the client. Regards Matthew M. Conley Linux Administrator / IA AECOM Linux+, Security+, Network+, LPIC1, EMT, FF1 -----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Kirk Bocek Sent: Friday, May 08, 2015 11:28 AM To: CentOS mailing list Subject: Re: [CentOS] Q: respecting .ssh/id_rsa On 5/8/2015 7:22 AM, Valeri Galtsev wrote:> On Fri, May 8, 2015 8:58 am, James B. Byrne wrote: >> While attempting to debug something else I ran across this: >> >> ssh -vvv somehost >> . . . >> debug1: Connection established. >> debug1: permanently_set_uid: 0/0 >> debug1: identity file /root/.ssh/identity type -1 >> debug1: identity file /root/.ssh/identity-cert type -1 >> debug3: Not a RSA1 key file /root/.ssh/id_rsa. >> debug2: key_type_from_name: unknown key type '-----BEGIN' >> debug3: key_read: missing keytype >> debug3: key_read: missing whitespace >> . . . >> >> However if I verify the key I see this: >> >> ssh-keygen -l -f ~/.ssh/id_rsa.pub >> 4096 08:70:3b:92:4c:96:1c:6a:03:a4:ae:66:8d:9e:6c:93 >> /root/.ssh/id_rsa.pub (RSA) >> >> Which seems ok to me. The permissions also seem ok: >> >> .ssh]# ll >> total 40 >> -rw-------. 1 root root 3863 Oct 11 2012 authorized_keys >> -rw-------. 1 root root 3243 Aug 9 2012 id_rsa >> -rw-r--r--. 1 root root 757 Aug 9 2012 id_rsa.pub >> -rw-r--r--. 1 root root 11071 May 8 09:42 known_hosts > When checking permissions don't forget to check permissions on parent > directories (all levels up to the /). E.g., if your home directory is > world writable, ssh will ignore authorized_keys as well, as the above > permissions _can_ be changed by everybody. The same is true if / is > ridiculously world writable (I've never seen that myself, but I do mean: > check all levels of what the path ~/.ssh is). > > It's not clear from your description, but I'm sure you have the > following > right: id_rsa and id_rsa.pub is a pair you have on local machine (the > one you ssh from). autorized_keys is on the remote machine (the one > you connect to), and it contains the contents of id_rsa.pub that you > have on local machine (i.e. you copied id_rsa.pub from local machine > to remote and dumped it into ~/.ssh/autorized_keys on it). > > I would also check that in sshd config file (usually: > /etc/ssh/sshd_config) on remote machine you do have line > > PubkeyAuthentication yes > > Good luck! > > Valeri > >> The password-less connections complete in any case but I am perplexed >> as to what is the problem with the root identity key that ssh is >> reporting. >> >> Can anyone explain to me what this means? >> >>Also check that the selinux context on all files and directories are set to "ssh_home_t". From the home dir: #chcon -R -t ssh_home_t .ssh _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos
On 8 May 2015 20:41, "Conley, Matthew M CTR GXM" < matthew.m.conley1.ctr at navy.mil> wrote:> > chmod 0700 .ssh > chmod 0600 .ssh/* > > Keys can fail if you don't have that setup correctly. > Also do: > grep sshd /var/log/audit/audit.log| audit2allow -m sshd > # Will let you see what modules it will create. > grep sshd /var/log/audit/audit.log| audit2allow -M sshd > # Creates the modules > > semodule -I sshd.pp > > grep ssh /var/log/audit/audit.log| audit2allow -m ssh > # Will let you see what modules it will create. > grep ssh /var/log/audit/audit.log| audit2allow -M ssh > # Creates the modules > > semodule -I ssh.pp > > sshd is the server; ssh is the client. > ><cleveland>No no no no nooooo </Cleveland> Blindly running audit2allow and creating modules weakens your security not enhances it. If you have not messed up your labeling then SSH will have no problem reading keys - SSH keys are fully supported under the policy shipped with CentOS. If you are mounting your home elsewhere do: semanage fcontext -a -e /home /mynewspecialhome restorecon -Rv /mynewspecialhome That will fix any selinux labelling issues of your home directories properly.