FlightAware Discussions

Source packages?

@abcd567 if you are able to complete ssh on the same image without reinstall, -it is possible that my card was corrupt in some way.-

Update for @zenonp:

As abcd567 seems to be able to ssh in, I reimaged my card and confirmed that this image does not properly generate host key. From systemctl status sshd:

● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-11-08 09:49:34 UTC; 5min ago
Docs: man:sshd(8)
man:sshd_config(5)
Process: 600 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 626 (sshd)
Tasks: 1 (limit: 4476)
Memory: 2.9M
CGroup: /system.slice/ssh.service
└─626 /usr/sbin/sshd -D

Nov 08 09:49:34 fabian64 sshd[626]: Could not load host key: /etc/ssh/ssh_host_rsa_key
Nov 08 09:49:34 fabian64 sshd[626]: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 08 09:49:34 fabian64 sshd[626]: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Nov 08 09:49:34 fabian64 sshd[626]: Server listening on 0.0.0.0 port 22.
Nov 08 09:49:34 fabian64 sshd[626]: Server listening on :: port 22.
Nov 08 09:49:34 fabian64 systemd[1]: Started OpenBSD Secure Shell server.
Nov 08 09:51:30 fabian64 sshd[1125]: error: Could not load host key: /etc/ssh/ssh_host_rsa_key
Nov 08 09:51:30 fabian64 sshd[1125]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 08 09:51:30 fabian64 sshd[1125]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Nov 08 09:51:30 fabian64 sshd[1125]: fatal: No supported key exchange algorithms [preauth]

$ ls -l /etc/ssh
total 560
-rw-r--r-- 1 root root 565189 Jan 31  2020 moduli
-rw-r--r-- 1 root root   1580 Jan 31  2020 ssh_config
-rw-r--r-- 1 root root   3250 Jan 31  2020 sshd_config

After manually generating host keys, I can ssh in. In other words, the image isn’t corrupt, but openssh-server installer wasn’t run correctly when the image was built.

As I continue to suffer from frequent file system failures, I will not test password change for now. In order to narrow down possible causes of the corruption, reducing engagement with KDE is one way to reduce card access as one possible factor.

(1) In Debian:

sudo nano /etc/default/dump1090-fa

Scroll down to the following line:
RECEIVER_OPTIONS="--device-index 0 --gain -10 --ppm 0"

in this line add following
--lat xx.xxxx --lon yy.yyyy
(Replace xx.xxxx and yy.yyyy by actual figures)

(2) From your stats page

For Beginners - Howto Set Receiver Location

1 Like
sudo piaware-config allow-manual-updates yes  

sudo piaware-config allow-auto-updates yes  

sudo systemctl restart piaware  

1 Like

sed -i ‘s/fabian/fabian64/g’ /etc/hosts

Explanation: In the first image I made, the hostname was just fabian. On the second iteration, which just built further on the first, I changed /etc/hostname but forgot /etc/hosts. Normally, the dhcp client reports its hostname to the dhcp server, which then goes on to resolve it for as long as the client’s lease is valid. That’s the case with my router (an AVM Fritzbox), which is why I never noticed this. Some dhcp implementations don’t do this, which apppears to be the case with your dhcp server, which is why it bit you.

Why? sudo already worked fine for pi.

I have a suspicion. Take a look in /root/cleanup. I mount the image on another system and run that as the last thing before I compress and publish a new image. As you see, it deletes all sshd keys, so I don’t go distributing systems with identical keys. When sshd is first started, it is supposed to create a set of keys if they are not already present. Most likely this did not happen, so sshd was running without keys, making it impossible to accept a connection.

Looking now at systemd’s ssh.service, it says
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

On my SL7 workstation it says
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

And I can’t find an sshd-keygen.service on debian. Whatever generates the keys on first boot does not seem to run ever again. It’s probably a post-install scriptelt in the sshd.deb. If that is the case, it is a bug in the distro. I’ll fix it on the image. In the meanwhile,

# after -C and after -N it's two single quotes, not one double quote
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -C '' -N ''
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -C '' -N ''
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -C '' -N ''
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -C '' -N ''

That has probably something to do with your USB stick, or perhaps you pulled it out without cleanly unmounting it first. Please try another stick and see if that works better.

Aha, now we know that abcd567 is using the second iteration of the image, while you’re using the third. And only belatedly I see that you figured out and fixed the sshd problem. I’m leaving the key regeneration instructions anyway, since they might be useful to someone else.

Only now, several hours later, did I spot the typo in the image: “ssh febian64”: Error resolving ‘febian64’. Then again, if your router does DNS for internal machines and does not store and serve their DHCP-reported hostnames, sshing by name would have failed even without the typo.

OOPS!!!

Actually, I didn’t realize the full extent of the problem in the above observation. KDE requires a UI logon before starting WiFi. This is totally nuts if I want to do anything headless - which is how I run Linux.

To recap: In order for WiFi to start,

  1. A human user must be on the UI to logon.
  2. The root user’s password must match that of KDE Wallet; else the user must manually start WiFi, then enter Wallet password.

But the previous image was able to generate keys on start. I also compared with Raspbian - rather, PiAware. It has the same unit file, also no ssh-keygen service.

pi@piaware:~ $ cat </usr/lib/systemd/system/ssh.service 
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service

Is it possible the other images ship with openssh-server in cache but only install on first boot? (Wild guess.)

See /lib/systemd/system/regenerate_ssh_host_keys.service on a Raspbian or PiAware image.

1 Like

@zenonp Source is named for Raspberry Pi https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/master/debian/raspberrypi-sys-mods.regenerate_ssh_host_keys.service. This suggests that there is no universal solution. This code looks very solid and may be adopted for your image.

I looked at it as soon as obj mentioned it, and I must say I don’t like it. First it regenerates keys unconditionally, even if they already exist, then it cuts the branch that it’s sitting on, so it will never run again without manual intervention. I find the redhat script much more reasonable: it runs every time before sshd, but it only generates keys if they do not already exist. This has the benefit that you can never be accidentally locked out for lack of keys, and also that you can just do ‘rm -f /etc/ssh/*key*; systemctl restart sshd’ if you want to change your keys. So I think in this case debian will invite redhat on a date and I’ll just swipe that script.

I’m still mildly scratching my head on the wifi/kdewallet problem, but I’ve had no time these last days to do any work on it. It looks like everything will have to wait for the weekend.

Debian 10.6 cannot get airspy conf working ?