Can't SSH via public key to home node (due to wrong uid for /etc/dropbear)

gobengo commented 6 years ago

I added my public key to /etc/dropbear/authorized_keys on my home node, but can't figure out how to ssh to it.

ben@bengo-air ~/dev/sudomesh/makenode master+1 ⚡ ssh 172.30.0.1 
ben@172.30.0.1's password: 

ben@bengo-air ~/dev/sudomesh/makenode master+1 ⚡ ssh root@172.30.0.1 
root@172.30.0.1's password:

(If I manually enter the password):

ben@bengo-air ~/dev/sudomesh/makenode master+1 ⚡ ssh root@172.30.0.1 cat /etc/dropbear/authorized_keys
root@172.30.0.1's password: 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDLFnHrMbFMJYaOxV1a4m4Yq/twb2zQCXBYbYdRdzU/q1bLyiJptQXvK2/rmRfmzezqhkL2c06eVKO67IWp8UNm+iW+jNV9I+NYqP67ucbeX5nPI9z574vUA81+4CUEI7te5avamPRhdCHu3EXJmixtc+jvv1mf0zmymx5uiescva7zK0q/7/298mZQdS8dT774kBJgCCyI2V0Ee6XXI20eyS5vORMfDttG68zNgjLAyciC6gKKmeBg0a/CFPqwgqgx3rxwQcQshAM3xHmlMeKvpU+wO4QAi9HuLL32leSjbjuF5D7D9XqQILXYJyWGrslMbEmWY6ZsO3Kt2NeGP8vo+BeUR82cMlQPF9iRtXqGTdZOXI1PfhxEo+T1i2LwZDIobLsnwoLgkxp6ByKbRcasWGQw5A8enWUnSfNWPNFm8DMi76fQux8jOYb4Gj5lMINslSEYKZeJ2K57P+MaZ0W+4K/v+IJoPrAhZMd6TVA4LpZlWeFbjTmVoa2PmCFqUUORwaIkyzlfBaI+nX8d3lxk/pgLEjfcJ5zDby/zHcKGcCQ9Gjv5eONDnBKyw8iL4zFCQTwqNqTbvGlRx14eibGHJGZazOlb36coOuhyfazKuM+38AXk6bTMRqIPbRDxkapimGxyvIYFywM2VHfo8LwJRTjrk7/dOGCTfAhf4OqsNw== bengoering@gmail.com

Diagnosis: /etc/dropbear isn't owned by 'root' (on the router). i.e. the uid of the owner is not 0. On my system it was 502. This is also the uid of the user on my mac:

ben@bengo-air ~ ⚡ id -u
502

root@annie:~# cd /etc/dropbear/
root@annie:/etc/dropbear# ls -alh
drwx------    1 502      root           0 Apr 17  2017 .
drwxr-xr-x    1 502      root           0 Apr 17  2017 ..
-rw-------    1 502      root         746 Feb 19 12:36 authorized_keys
-rw-------    1 502      root         457 Feb 19 11:44 dropbear_dss_host_key
-rw-------    1 502      root         805 Feb 19 11:44 dropbear_rsa_host_key

Workaround/Solution: Make sure /etc/dropbear is owned by root

root@annie:~# chown root:root -R /etc/dropbear/

ben@bengo-air ~/dev/sudomesh/makenode master+1 ⚡ ssh root@172.30.0.1 echo "connected with ssh key"
connected with ssh key

Future Work:

[ ] - makenode itself should probably do that chown root:root.
- Would it make sense to do via remoteCommand here? https://github.com/sudomesh/makenode/blob/master/makenode.js#L643

jhpoelen commented 6 years ago

@gobengo thanks for sharing! I think it would be great if you could create a pull request with a proposed fix and then ask someone (your future self?) to reproduce issue and test the fix.

gobengo commented 6 years ago

@jhpoelen will do. I'll tinker with a fix and ultimately convert this issue to PR

Juul commented 6 years ago

makenode uses the node module ipk-builder which uses the fakeroot command to set root ownership of all files.

Permissions are set in config files, e.g. see the permissions section in configs/config.js.

Since this works normally you may have accidentally changed something to break this. Inspect the generated .ipk file in the ipks/ directory to see if the ownership of the file is something other than root (e.g. the midnight commander will let you browse into an .ipk as if it was a directory).

gobengo commented 6 years ago

Since this works normally you may have accidentally changed something to break this

It seems more likely to me that this is just due to my setup of running makenode on mac and as a non-root user.

It would 'work normally' under conditions where I was running as a user with uid=0 (e.g. as root on a Linux OS).

--

Inspect the generated .ipk file in the ipks/ directory to see if the ownership of the file is something other than root

ben@bengo-air ~/dev/sudomesh/makenode/ipks master+1 ⚡ mkdir -p ./ipk-extracted/data/
ben@bengo-air ~/dev/sudomesh/makenode/ipks master+1 ⚡ tar -xf ./per-node-config-00-90-a9-0c-71-f8.ipk -C ./ipk-extracted
ben@bengo-air ~/dev/sudomesh/makenode/ipks master+1 ⚡ tar -ztvf ipk-extracted/data.tar.gz | grep etc/dropbear
drwx------  0 ben    wheel       0 Feb 19 11:44 etc/dropbear/
-rw-------  0 ben    wheel     457 Feb 19 11:44 etc/dropbear/dropbear_dss_host_key
-rw-------  0 ben    wheel     805 Feb 19 11:44 etc/dropbear/dropbear_rsa_host_key
-rw-------  0 ben    wheel    1945 Feb 19 11:44 etc/dropbear/authorized_keys

Reading this makes me realize that everything here is doing it's job and no more, the IpkBuilder + tar are just using the existing uid/gid from when I cloned the makenode repo as 'ben'. But surely we should allow cloning/building on the build host with different uid/gid than we plan to use on the embedded host.

The two paths forward seem to be:

chown at build-time - Allow makenode.js to be configured with a build-time uid/gid (e.g. uid=0 gid=0), and as part of building the filesystem to go into the ipk, it runs 'chown' on anything it puts into the staging dir (or relevant subset)
- Thinking about this a bit more... it's actually kind of bad unpredictability to just use the build host's UIDs (which will always be different). We should have a sane default of uid=0, gid=0. Re-using build host UIDs is almost never what the builder-user actually wants... right?
  - I prototyped this at gobengo:changeOwnership, but it didn'twork so well. I think maybe because at build time we're limited in what uids/gids the building user can chown to.
chown at post-install-time - Add a post-install script to the IPK (or ammend configs/ar71xx/home_nodes/templates/postscripts/enable-services.sh) to do a chown root:root -R /etc/dropbear/ (or similar)
- Notably this may not be needed if we do chown-at-build-time with default of uid=0, gid=0.
- Relevant Reading
  - debian/rules - Do we have that for packages built by ipk-builder?
  - use a postinstall script

@Juul Do you support one of those two options? Or am I misunderstanding something?

bennlich commented 6 years ago

It seems more likely to me that this is just due to my setup of running makenode on mac and as a non-root user.

@gobengo I have successfully flashed nodes from a mac as a non-root user.

Maybe something went wrong with fakeroot.

My current understanding is that when you run fakeroot, you enter a shell environment where you appear to be a root user even though you are not actually a root user. Then, when you create a package, tar thinks you're a root user creating the package, so it records the ownership/permissions as though they were created with root.

I just did this test as a non-root user to see if my fakeroot was working:

mkdir fakeroot-test
cd fakeroot-test
fakeroot
touch a.txt
touch b.txt
tar -pczf ../data.tar.gz *
exit
sudo tar -xzpf ../data.tar.gz
ls -l

The extracted a.txt and b.txt should belong to root.

sudomesh / makenode

Can't SSH via public key to home node (due to wrong uid for /etc/dropbear) #21