I think there will be a few posts on this, while I really like the Kano, there are a number of little quirks which range between irritating, and downright annoying – so hopefully here are some solutions.
tl;dr: This is an example of irritation and annoyance.
Installing SSH server (sshd)
So why would I want to do this? A number of reasons:
- The keyboard isn’t great if you need to do any extended hacking about with the OS/sub-system
- Multiple windows – the kano is single app view only, which is fine for the general use case, but not if you need to debug something or research.
- Network admin
Installing Open SSH (Server)
The kano doesn’t have the sshd server installed out of the box, so we need to add it, which for the reasons above and the fact that the package manager is a terminal application makes this a little venture off the beaten track, so:
- Find the Terminal
- Install ssh (I tried to find this in the terminal through aptitude, and failed)
sudo apt-get install ssh
systemctl enable ssh
systemctl start ssh or sudo /etc/init.d/ssh start
- Update the boot scripts so it starts on boot:
sudo update-rc.d ssh defaults
- netstat -an to check that the server is listening on port 22
Now, at this point I had the following issue – the service would fail and tell me to check the logs etc using:
> systemctl status ssh > journalctl -xe
The service couldn’t start because it wouldn’t bind to 0.0.0.0:22 – i.e. listen on 22 for all addresses on this host.
So I ran
netstat -n, and I got… nothing. Usually this error is because someone has got port 22 already, so you need to find that thing, and either change it or perhaps you’re running two instances of the same thing and they are fighting. Checked the ps -ef output, and nothing, no ssh.
Having read that this might be an issue with ip4 vs ip6 conflicts, I made it IP4 only by setting:
Port 22 AddressFamily any ListenAddress 0.0.0.0
In the end, a reboot via sudo reboot fixed it, once it rebooted, running
netstat -4an showed:
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
Meh. Anyway – now, with a client of your choice, you can login. Just remember there is probably only the one user on the Kano.
But there’s more…
So while writing this, I checked the logs to make sure I got the commands right, and lo and behold there is a failure… in “dropbear“. What’s dropbear? It’s a lightweight SSH server.
Ok, so there was a server, and I just didn’t use or know it, let’s re-enable, so stop the ssh server, and start dropbear and that should be better for the underlying Pi and I might get some space back (about 2Mb). This would also imply it was the root cause of the issue above, and that the reboot simply re-ordered the sequence of things running and this time dropbear lost to the “real” sshd.
> sudo systemctl stop ssh > sudo systemctl start dropbear
and then a check with
> sudo systemctl status ssh > sudo systemctl status dropbear > netstat -4an
I can confirm there is a service listening on 0.0.0.0:22. Let’s try logging in.
Right – time to undo the ssh install so I can get some space back, it’s a Pi after all.
> sudo apt-get remove ssh
Remove the SSH package we installed
> sudo apt autoremove
Remove the openssh-server and openssh-sftp-server dependencies
Reboot – and cross fingers – then login via client and success!
Well the obvious bit, I wasn’t as smart as I thought I was, and there is a big knowledge gap around what’s running and what it does. Looking for ssh in ‘dropbear’ didn’t occur to me, and I suspect unless you’ve been buried in the Pi lore for a while, it wouldn’t be your first guess, which might explain why I couldn’t find this in aptitude. I have to say I find the Kano’s underlying debian package system less… intuitive than I was used to with Redhat/SuSE. Well lots more to find out about the Kano I guess.