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
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?
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?
-- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
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@centos.org [mailto:centos-bounces@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@centos.org http://lists.centos.org/mailman/listinfo/centos
On 8 May 2015 20:41, "Conley, Matthew M CTR GXM" < matthew.m.conley1.ctr@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.
True true. I was just trying to keep it simple. Most people I deal with, I don't have time to explain rules.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of James Hogarth Sent: Saturday, May 09, 2015 1:47 AM To: CentOS mailing list Subject: Re: [CentOS] Q: respecting .ssh/id_rsa
On 8 May 2015 20:41, "Conley, Matthew M CTR GXM" < matthew.m.conley1.ctr@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. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--On Friday, May 08, 2015 09:58:32 AM -0400 "James B. Byrne" byrnejb@harte-lyne.ca 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
[snip]
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?
IIRC there was a time when id_rsa could refer to either an RSA1 key or RSA2 key. I believe ssh is first trying to read the file as an RSA1 key, finding problems, and then opening it as an RSA2 key. In fact, if you scroll down from there you probably see a line like the following:
debug1: identity file /home/somebody/.ssh/id_rsa type 1
which is a successful read (note the type is 1 and not -1).
In other words, it's nothing to worry about. The messages are a bit different under CentOS 7 (I suspect you're running CentOS 6 on the client), but they say about the same thing.
While the other followups would be good ideas if you actually had a problem logging in, it sounds like you don't have a problem and the question was just a curiosity thing.
Devin
Devin Reade wrote:
--On Friday, May 08, 2015 09:58:32 AM -0400 "James B. Byrne" byrnejb@harte-lyne.ca 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
[snip]
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?
IIRC there was a time when id_rsa could refer to either an RSA1 key or RSA2 key. I believe ssh is first trying to read the file as an RSA1 key, finding problems, and then opening it as an RSA2 key. In fact, if you scroll down from there you probably see a line like the following:
debug1: identity file /home/somebody/.ssh/id_rsa type 1
which is a successful read (note the type is 1 and not -1).
In other words, it's nothing to worry about. The messages are a bit different under CentOS 7 (I suspect you're running CentOS 6 on the client), but they say about the same thing.
<snip> I would *strongly* recommend editing your /etc/ssh/sshd_config, and comment or delete the fallback, and replace it, like: #Protocol 2,1 Protocol 2
That way, it won't even try.
mark
--On Friday, May 08, 2015 01:23:57 PM -0400 m.roth@5-cent.us wrote:
I would *strongly* recommend editing your /etc/ssh/sshd_config, and comment or delete the fallback, and replace it, like: # Protocol 2,1 Protocol 2
That way, it won't even try.
While forcing protocol 2 on the server is not a bad idea, it won't help here. Remember, that's a client-side debug message that the OP was seeing. I can verify that the client still produces that message even when talking to a server that does only protocol 2.
Forcing protocol 2 on the client side also does not suppress that message, so the key-type-determination algorithm is not likely dependent on the protocol version.
Devin
For security you can make these changes, I am being lazy and just pulled from my scripts:
echo "PermitEmptyPasswords no" >> /etc/ssh/sshd_config echo "HostbasedAuthentication no" >> /etc/ssh/sshd_config echo "IgnoreRhosts yes" >> /etc/ssh/sshd_config echo "Banner /etc/issue" >> /etc/ssh/sshd_config echo "ClientAliveInterval 900" >> /etc/ssh/sshd_config echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/sshd_config echo "PermitUserEnvironment no" >> /etc/ssh/sshd_config echo "PermitRootLogin no" >> /etc/ssh/sshd_config echo "Protocol 2" >> /etc/ssh/sshd_config sed -i 's@PrintLastLog no@$PrintLastLog yes@g' etc/ssh/sshd_config echo "ClientAliveCountMax 0" >> /etc/ssh/sshd_config
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Devin Reade Sent: Friday, May 08, 2015 1:57 PM To: CentOS mailing list Subject: Re: [CentOS] Q: respecting .ssh/id_rsa
--On Friday, May 08, 2015 01:23:57 PM -0400 m.roth@5-cent.us wrote:
I would *strongly* recommend editing your /etc/ssh/sshd_config, and comment or delete the fallback, and replace it, like: # Protocol 2,1 Protocol 2
That way, it won't even try.
While forcing protocol 2 on the server is not a bad idea, it won't help here. Remember, that's a client-side debug message that the OP was seeing. I can verify that the client still produces that message even when talking to a server that does only protocol 2.
Forcing protocol 2 on the client side also does not suppress that message, so the key-type-determination algorithm is not likely dependent on the protocol version.
Devin
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Conley, Matthew M CTR GXM -
Devin Reade -
James B. Byrne -
James Hogarth -
Kirk Bocek -
m.roth＠5-cent.us -
Valeri Galtsev