Can't write to /var/mod/root/.ssh (it's a symlink instead of a directory)

[mickey]

It's not possible to write to /var/mod/root/.ssh because it is a symlink and not a directory as it should be.

# ls -la /var/mod/root/.ssh
lrwxrwxrwx    1 root     root           31 Jan  1  2000 /var/mod/root/.ssh -> /tmp/flash/authorized_keys_root

Why do you think that it doesn't work? Could you at least mention one example. It's a symlink since a long, long time.

Replying to Whoopie:

Why do you think that it doesn't work?

Because .ssh is supposed to be a directory where ssh (or dropbear) store several files, e.g. authorized_keys, known_hosts et.al.

Without .ssh beeing a directory this is simply impossible.

Could you at least mention one example.

Currently dropbear fails to store host keys of known hosts once you connect to them:

# ssh some.server.com
ssh: Failed to open /mod/root/.ssh/known_hosts

Host 'some.server.com' is not in the trusted hosts file.
(fingerprint md5 DE:AD:BE:EF:00:00:00:00:00:00:00:00:00:00:0F:00)
Do you want to continue connecting? (y/n) y

It's a symlink since a long, long time.

That doesnt make it right.

If you dont believe me why dont you check out dropbear documentation or source code?

Because it works perfectly here with dropbear:

/var/mod/root # ssh testaccount@192.168.1.2 -i /mod/root/.ssh/id

Host '192.168.1.2' is not in the trusted hosts file.
(fingerprint md5 72:ee:24:fd:94:73:e5:de:41:eb:6b:e9:5d:bf:4a:ef)
Do you want to continue connecting? (y/n) y
Linux notebook 2.6.25.20 #1 PREEMPT Tue Nov 3 00:43:36 CET 2009 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
Last login: Tue Jan  5 12:32:04 2010 from XXX
testaccount@notebook:~$ exit
logout
/var/mod/root # 

Could you show me the authorized_keys_root directory permissions?

And I checked the dropbear source code. There's nothing mentioned in the cli-kex.c file that symlinks are not allowed.

As far as I can see, it might be a problem related to previous versions?
In a 701 with Rev. 3873 I had only /var/mod/root/.ssh as a symlink to /tmp/flash/authorized_keys_root but /tmp/flash/authorized_keys_root was not existing as a directory.

The actual rc.authorized-keys shoud call convert_compat() and therefore doing a mkdir -p $dir with dir="/tmp/flash/authorized_keys_root"

Here is a sample of the (not working) Rev. 3873 and the "fix" by creating the directory (you should do a modsave afterward, of course).

/var/mod/root # ls -l .ssh 
lrwxrwxrwx    1 root     root           31 Jan  1 01:00 .ssh -> /tmp/flash/authorized_keys_root
/var/mod/root # ls -l /tmp/flash/authorized_keys_root
ls: /tmp/flash/authorized_keys_root: No such file or directory
/var/mod/root # ssh localhost
'''ssh: Failed to open /mod/root/.ssh/known_hosts'''

Host 'localhost' is not in the trusted hosts file.

[...]

/var/mod/root # exit
/var/mod/root # ls -l /tmp/flash/authorized_keys_root
ls: /tmp/flash/authorized_keys_root: No such file or directory
/var/mod/root # mkdir -p /tmp/flash/authorized_keys_root
/var/mod/root # ssh localhost

Host 'localhost' is not in the trusted hosts file.
[...]

/var/mod/root # exit
/var/mod/root # ls -l /tmp/flash/authorized_keys_root
-rw-r--r--    1 root     root          223 Jan  1 01:05 known_hosts
/var/mod/root #

Replying to Whoopie:

Because it works perfectly here with dropbear:

/var/mod/root # ssh testaccount@192.168.1.2 -i /mod/root/.ssh/id

Ok, ok, i've got the point: the symlink target name is very misleading so i thought its a file. Obvisously its ment to be a directory. Then we are d'accord.

Could you show me the authorized_keys_root directory permissions?

The link target /tmp/flash/authorized_keys_root doesn't exist.

And dropbear's attempt to create the directory if its not there is fooled by the fact that it is a symlink:

		snprintf(filename, len+18, "%s/.ssh", homedir);
		/* Check that ~/.ssh exists - easiest way is just to mkdir */
		if (mkdir(filename, S_IRWXU) != 0) {
			if (errno != EEXIST) {
				dropbear_log(LOG_INFO, "Warning: failed creating %s/.ssh: %s",
						homedir, strerror(errno));
				TRACE(("mkdir didn't work: %s", strerror(errno)))
				goto out;
			}
		}

Replying to MaxMuster:

As far as I can see, it might be a problem related to previous versions?

What do you mean by "previous versions"?

In a 701 with Rev. 3873 I had only /var/mod/root/.ssh as a symlink to /tmp/flash/authorized_keys_root but /tmp/flash/authorized_keys_root was not existing as a directory.

That is exactly the case on my box, too. I run 7170_04.76freetz-devel-4150

The actual rc.authorized-keys shoud call convert_compat() and therefore doing a mkdir -p $dir with dir="/tmp/flash/authorized_keys_root"

Sounds like a solution to me.

Here is a sample of the (not working) Rev. 3873 and the "fix" by creating the directory (you should do a modsave afterward, of course).

Thanks for the hint

Replying to mickey:

What do you mean by "previous versions"?

I first thought it was a problem e.g. with my version 3873 and o.k. with 4150. But taking a second look to rc.authorized-keys, the mkdir is only called, if there are some "older" versions around, using the file /tmp/flash/dropbear/authorized_keys.

At the moment I am not sure, if the creation of the directory is allways done when needed. Maybe there is a simple [ -d /tmp/flash/authorized_keys_root ] || mkdir -p /tmp/flash/authorized_keys_root missing?

Replying to MaxMuster:

At the moment I am not sure, if the creation of the directory is allways done when needed. Maybe there is a simple [ -d /tmp/flash/authorized_keys_root ] || mkdir -p /tmp/flash/authorized_keys_root missing?

A reliable solution is definatly required. Adding the suggested line to the rc script seems reasonable to me.

Perhaps we should create this directory in the dropbear script. Because for authorized_keys everything is okay and works fine. The directory is created when the keys are saved.

Might be a reasonable approach but on the other hand it is the "authorized-keys" package which installs the symlink to an (not allways existing) directory. So I think it should indeed be checked here. Otherwise (not checked) we would to do it for different ssh-clients (like open-ssh), too?? As far as I see the "normal" approach (checking .ssh ) is not possible for the ssh client because of the symlink??

Could someone please explain me why authorized-keys package claims the ~root/.ssh symlink for itself? I mean there are other files user may want to save in ~root/.ssh directory. The way it is implemented now he is forced either to save them directly in /tmp/flash/authorized_keys_root or to create symlinks.

Why can't authorized-keys package simply detect the ssh-server (dropbear/openssh) being used and modify the corresponding authorized_keys file. In case both are installed (it seems to be possible, but I don't believe anyone use both at the same time) it should simply modify both authorized_keys files (possibly one by being a symlink to another). In the latter case it doesn't even need to detect anything, it should simply iterate over /tmp/flash/dropbear and /tmp/flash/openssh.

p.s. I do also believe authorized-keys package should be optional, I don't need it at all.

Perhaps IPPF-user mehle can do. He created this package when openssh was added to Freetz.

​http://www.ip-phone-forum.de/showpost.php?p=1381472&postcount=50

Do you use password or how do you authenticate yourself?

Do you use password or how do you authenticate yourself?

I do use public key authentication, moreover public key authentication only. I just don't need any web-interface, I do know what I have to do…

The mess with the symlink is the main reason I revert parts of r3701 in my personal tree and don't use authorized-keys package at all. As of me rc.dropbear/rc.openssh should create symlink to /tmp/flash/dropbear or to /tmp/flash/openssh, the only task authorized-keys package should take care of is file editing, nothing else, no subdirectory in /tmp/flash, no symlink and so on.

Replying to er13:

Could someone please explain me why authorized-keys package claims the ~root/.ssh symlink for itself?

p.s. I do also believe authorized-keys package should be optional, I don't need it at all.

Replying to er13:

As of me rc.dropbear/rc.openssh should create symlink to /tmp/flash/dropbear or to /tmp/flash/openssh, the only task authorized-keys package should take care of is file editing, nothing else, no subdirectory in /tmp/flash, no symlink and so on.

I fully agree. Its really a pain that such long-prooven and commonly known conventions beeing broken by freetz packages.

Replying to mickey:

Its really a pain that such long-prooven and commonly known conventions beeing broken by freetz packages.

I wouldn't go that far. There are usually (more or less) long discussions before changes like this. And for this special case: As far as I see the package in question it is not in the stable branches but only in trunk, so this is the right place to try out and discuss packages and find possible problems like the one you reported.
Don't get me wrong, I appreciate your ticket but I don't think it is fair to claim the freetz community is "breaking conventions on purpose", as one might interpret your statement.

(in r4197): authorized_keys package:

• Create directory at startup

Is anybody willing to invest some time here? Otherwise I will move this to milestone 1.3. I think it's reasonable to have one package managing the keys. Instead having two packages with two different storage places. Perhaps it's the method the storage is done we should review.

@er13: Bitte etwas detaillierter. Das Problem war, dass das Verzeichnis nicht angelegt wurde, was mit r4197 behoben wurde. Und das war vor genau 2 Jahren

Das authorized-keys-Paket ist mit einigen (mindestens 2) Designfehlern behaftet, s. comment:10. Das Problem in diesem Ticket ist die Folge von einem von diesen…

Irgendwie muss ~/.ssh angelegt werden, da es keinen Reboot überlebt. Wie sonst auch als Link nach /tmp/flash/. Der Verzeichnisname "authorized-keys-root" ist seltsam, aber naja. Wenn man es umbenennt, muss längere Zeit eine compat-Sektion mitgeschleppt werden. Wenn nun jedes Package das ~/ssh nutzt das Package authorized-keys auswählt, ist der Link ~/ssh immer da und zeigt immer auf die gleiche Stelle mit dem gleichen Inhalt, egal für welches Package. Das authorized-keys Package hat auch nicht wirklich viel Code, eigentlich nur den Link anlegen, das Verzeichnis und dann werden noch Dateien registriert die man per Webif bearbeiten kann.
Das finde ich so alles okay.

ping

@er13: Ich möchte mich da ungern hinein denken. Du kennst seit Jahren die Problematik und die (Zitat) Designfehler. Würdest Du das bitte so beheben, wie es Dir angemessen erscheint? Ansonsten weiß ich nicht, wieso das Ticket nach so langer Zeit noch offen bleiben sollte. Der Schmerz scheint ja nicht besonders groß zu sein, obwohl Du "reopen" geklickt hast.

Fall es jemand wieder öffnet, bitte mit Grund dafür!

Mir fehlt die Motivation, es zu korrigieren. In meiner working-copy patche ich den Unsinn raus und bin damit zufrieden. Sollte sich das mit der Motivation bei mir ändern, so werde ich das Ticket wieder öffnen