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. [ 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).
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.
I would suspect that a number of armv7 boards lack an RTC, and an old date will be bad for a lot of processes beyound just SSH key generation.
So on first boot (and maybe any boot), check the system time. If it is ZERO, then read some file that has the last boot date and update with that. That will more than likely get the system close enough for services to start up better until NTP can get the current time.
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. [ 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).
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.
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.
On 08/16/2014 05:45 AM, Daniel J Walsh wrote:
On 08/15/2014 03:34 PM, Robert Moskowitz wrote:
My cubieboard2 vanilla see below 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
Well this is a clean install:
# fedora-arm-image-installer/fedora-arm-image-installer.sh --image=Fedora-Xfce-armhfp-21-20140815-sda.raw.xz --target=Cubietruck --media=/dev/sdb --norootpass
But replacing the Cubietruck uboot with the cubieboard2 uboot:
# dd if=/root/u-boot-sunxi/u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8; sync
So I am performing a 'rather common' semanage command to allow sshd to listen on a non-standard port, using the provided kernel and stuff. The Cubieboard2 uboot is what is being cleaned up for inclusion in armhfp-21.
[ 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.
Again, I am doing something that lots of others do, that is move sshd to another port using a common semanage command. So I did not do anything knowingly wiht sandbox_t or the rest you identify. Something provided in the current build is resonding not as it does in F20.
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.
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.
OK. I am running Minimal 'out of the box'. I DID install tigervnc-server and policycoreutils-python and all dependencies.
# semanage port -a -t ssh_port_t -p tcp ___ [ 2043.787411] SELinux: Permission audit_read in class capability2 not defined in policy. [ 2043.795520] SELinux: the above unknown classes and permissions will be allowed [ 2045.025332] SELinux: Context unconfined_u:system_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped). [ 2047.090145] SELinux: Context unconfined_u:unconfined_r:sandbox_t:s0-s0:c0.c1023 became invalid (unmapped). [ 2047.654731] SELinux: Context system_u:system_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped). [ 2049.710431] SELinux: Context system_u:unconfined_r:sandbox_t:s0-s0:c0.c1023 became invalid (unmapped).
But it seems to have made the needed changes so I can SSH to my non-standard port.
This is a commonly done system change. Move SSH to someother port just to cut down on the robot noise. One time during this testing, I had port 22 open from the outside and before I could change the port number I had almost 600 attempted SSH logins.
On 08/16/2014 05:45 AM, Daniel J Walsh wrote:
On 08/15/2014 03:34 PM, Robert Moskowitz wrote:
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.
-
Daniel J Walsh -
Robert Moskowitz