ssh & Kernel modification?

[jandrieu]

So, I've got eOS working and am trying to figure out how to extend it.

In particular, I tried setting up the LPC SSH module: https://github.com/dworkin/lpcssh which suggests adding / modifying /usr/system/initd.c, but I couldn't get that to do anything.

I also tried walking through the directions at https://github.com/noahgibbs/phantasmal/blob/master/website/DGD/Kernel/Modifying.base.html but, again, couldn't get the basic "hello world" example to write a file.

Any suggestions?

-j

p.s. @ChristopherA suggested I ping @noahgibbs

[noahgibbs]

This definitely highlights one of the difficulties with our current system of git submodules - lpcssh wants to be installed by copying include files into kernellib... :-/

Looks like lpcssh implements one each of key-exchange methods, host-key types and ciphers. That makes sense - OpenSSH is enormous and there's only one of Dworkin. But that means you'll need to specify those things when SSHing in.

Once I copied the appropriate lpcssh files into place, I had to ssh in with this monstrosity:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -c 3des-cbc localhost -T -p 50110

That's ssh'ing to the local machine on port 51100 (by default lpcssh uses the first listed binary port) with DGD's preferred key-exchange algorithm, host-key algorithm and cipher.

That doesn't fix everything - I'm now getting "SSH:debug1: ASN.1 length octets exceed available data", which almost certainly means DGD is implementing something else in an outdated way, and needs either an LPC fix or an SSH command-line parameter to handle it appropriately...

So: this definitely looks like it's pretty advanced for a first project. And unfortunately, it's advanced in a "system-admin trying to get ancient SSH protocols to work" way, not an educational LPC or DGD way...

[ChristopherA]

ssh in with this monstrosity

Since you figured this out, can add it to the appropriate doc? Either to keep someone else from going down this rabbit hole, or if someone really wants to tackle it, an clue on where to get started. Thanks!

[noahgibbs]

Also, looks like actually generating a keypair as lpcssh suggests gives the error above, probably because the keypair has more bits than DGD is expecting (i.e. it's something resembling secure on a modern system, so it's using more bits than expected, possibly also exceeding eOS's current default array max length in the config file.) By using the supplied key, I instead get a bad packet length error, which could be for a number of reasons. But again, the solution, if it's possible, is almost certainly going to be about the ssh configuration rather than the LPC side.

[noahgibbs]

Reading through that old Modifying doc (which I wrote a long, long time ago), it has definitely aged poorly :-/

Let me give you the upshot of it, up to the write_file(), translated to eOS.

• First, run eOS normally and make sure it's working
• Second, add usr/System/initd.c as described in that doc - re-run eOS and make sure it's still working.
• Third, update usr/System/initd.c with the single write-file line added. Re-run eOS and make sure you get a log.txt file in the eOS root directory saying you had a successful test.

For me, that works. I see the file eOS/log.txt and it contains "Successful initd.c test" as it should.

With that said, I 200% understand why you've been having trouble with that doc. A lot of what it describes has changed or moved in the intervening (mumble) years.

[jandrieu]

So, the only System directory is in eOS/kernellib/src/usr

Putting an initd.c in there didn't seem to help. Here's the full path:

/home/joe/Software/eos/eOS/kernellib/src/usr/System/initd.c

I restart eos and I can log in just fine. I exist. I can type 'users' and get a list of logins.

However, I don't get the log file written anywhere. Literally, nowhere in the file system.

Here's the code in initd.c:

static int create(varargs int clone) {
  write_file("/log.txt", "Successful initd.c test\n");
}

[jandrieu]

Ok. I got it to work.

The problem is the duplication of files and file structure in kernellib. I simply put the initd.c in the wrong folder.

[ChristopherA]

So what was the wrong folder path, and what was the correct folder path?

Do you know the source of the confusion in "duplication of files and file structure in kernellib" that we might be address in documentation?

[jandrieu]

The confusion was from ambiguity over the / character at the beginning of a path. To my sensibility that means / on the unix system. Since it didn't mean that with DGD, and because I had been investigating kernellib related stuff wrt Gurbalib and LPCSSH, I did not automatically assume that /usr meant $REPOROOT/usr and instead found the usr directory in the kernellib.

There is still a lot of weird factoring in the directories. For example there are five directories labelled "kernel" and with kernel being a symlink to kernelib/src/kernel, which also includes a lib directory so there is also a kernel/lib.

I get that some of this is the submodules having their own file structure, but it takes a bit to learn up and understand what's going on.

[noahgibbs]

That's a great point - I think there are some old docs that explain the directory weirdness, but we could use a new one. We should have something well-phrased, up-front, making a good distinction between Git paths, DGD paths and system (host) paths. And there's definitely nothing like that already in place in the docs :-)

Also more about the structure of a kernellib-based app, which is highly relevant to how eOS and SkotOS do it.