[fedora-arm] Solved - Re: Fedora-Xfce-armhfp-21-20140815-sda.raw.xz problems with sshd

[Robert Moskowitz]

Kindof.

I had installed the Xfce image on a Cubieboard2 which has no video 
support, hopeing to later use VNC to connect to the Xfce desktop.  I 
fully understood, that I could not perform the install steps presented 
in the Xfce image to the monitor.  Never thought to consider that there 
would be other activities to still perform.

I just did an install of the same date, but the Minimal image.  And SSH 
is working just fine.

Still a problem with semanage.  Separate note for that.

On 08/16/2014 05:45 AM, Daniel J Walsh wrote:
> On 08/15/2014 03:34 PM, Robert Moskowitz wrote:
>> My cubieboard2 does not have an rtc, so at boot time the clock is at
>> the epoche start.  Once the network is up, then NTP sets the clock.
>>
>> So I tried connecting to SSH after the install and got:
>>
>> Read from socket failed: Connection reset by peer
>>
>> systemctl status sshd.service, said something about could not read
>> keys, so I checked and found:
>>
>> # ls /etc/ssh/ -ls
>> total 252
>> 240 -rw-r--r--. 1 root root     242153 Jul 18 19:50 moduli
>>    4 -rw-r--r--. 1 root root       2121 Jul 18 19:50 ssh_config
>>    8 -rw-------. 1 root root       4400 Aug 15 14:45 sshd_config
>>    0 -rw-r-----. 1 root ssh_keys      0 Dec 31  1969 ssh_host_ecdsa_key
>>    0 -rw-r--r--. 1 root root          0 Dec 31  1969
>> ssh_host_ecdsa_key.pub
>>    0 -rw-r-----. 1 root ssh_keys      0 Dec 31  1969 ssh_host_ed25519_key
>>    0 -rw-r--r--. 1 root root          0 Dec 31  1969
>> ssh_host_ed25519_key.pub
>>    0 -rw-r-----. 1 root ssh_keys      0 Dec 31  1969 ssh_host_rsa_key
>>    0 -rw-r--r--. 1 root root          0 Dec 31  1969 ssh_host_rsa_key.pub
>>
>>
>> I stopped sshd, deleted the key files, restarted sshd and now:
>>
>> # ls /etc/ssh/ -ls
>> total 272
>> 240 -rw-r--r--. 1 root root     242153 Jul 18 19:50 moduli
>>    8 -rw-------. 1 root root       4400 Aug 15 14:45 sshd_config
>>    4 -rw-r-----. 1 root ssh_keys    227 Aug 15 14:53 ssh_host_ecdsa_key
>>    4 -rw-r--r--. 1 root root        162 Aug 15 14:53
>> ssh_host_ecdsa_key.pub
>>    4 -rw-r-----. 1 root ssh_keys    387 Aug 15 14:53 ssh_host_ed25519_key
>>    4 -rw-r--r--. 1 root root         82 Aug 15 14:53
>> ssh_host_ed25519_key.pub
>>    4 -rw-r-----. 1 root ssh_keys   1675 Aug 15 14:53 ssh_host_rsa_key
>>    4 -rw-r--r--. 1 root root        382 Aug 15 14:53 ssh_host_rsa_key.pub
>>
>> And I can connect.
>>
>> So this is a problem with ssh that it will not properly make the keys
>> when the system date is that old.
>>
>> related, I move the sshd port, and update SELinux policy with:
>>
>> semanage port -a -t ssh_port_t -p tcp 1234
>>
>> and got the following messages:
>>
>> [ 1828.788735] SELinux:  Permission audit_read in class capability2
>> not defined in policy.
> This means you have a capability defined in policy "audit_read", which
> the kernel does not understand
>> [ 1828.796870] SELinux: the above unknown classes and permissions will
>> be allowed
>> [ 1829.450779] SELinux:  Context
>> system_u:system_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped).
>> [ 1831.528160] SELinux:  Context
>> system_u:unconfined_r:sandbox_t:s0-s0:c0.c1023 became invalid (unmapped).
>> [ 1832.890157] SELinux:  Context
>> unconfined_u:system_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped).
>> [ 1834.966398] SELinux:  Context
>> unconfined_u:unconfined_r:sandbox_t:s0-s0:c0.c1023 became invalid
>> (unmapped).
> These are types that have been removed from the default packages.  So
> they were defined in the previous policy that you had in the kernel, but
> the new policy you loaded no longer has sandbox_t and vbetool_t. These
> should not be a problem
> unless you had an application running as sanbox_t or vbetool_t, most
> likely not.
>> But it seems to have worked.  That is SSH can be reached at the
>> changed port.  And yes, I also did the firewall-cmd for the new port
>> number.
>>
>>