Inject ssh keys

[drtyhlpr]

Inject ssh keys

[drtyhlpr]

hi, sounds like a good idea. I am currently fixing some other stuff and will add this feature maybe next week. SSH_USER_PUB , SSH_ROOT_PUB parameters or something like that...

[jp-hoehmann]

I have made a fork, that adds an option to inject the key(s), that are authorized for the build server, to the image. Would you accept a PR for this?

[drtyhlpr]

sure I am happy with all PRs! I checked your patch and on one hand I like it for it's simplicity on the other hand I ask myself - do you (or anyone else than you) need this patch. In general I expect a RPi to be a system with a very small amount of users and a very small amount of users working in different remote sessions. But of course I may be wrong. I think I can definitely add your AUTHORIZE_(ALL_)SSH_KEYS together PR with the upcoming SSH_USER_PUB , SSH_ROOT_PUB parameters (that will simply accept a pub file).

[g-vidal]

That is agood idea I +
Just to give my use case to support this idea. I am using raspis for teaching a course on "learning how to code using weather stations and micro-sensors", I have built with rpi23-gen-image (many many thanks for the work) an image with all the necessary software and I use the raspi sas a jupyter servers for groups of students. It is very convenient and efficient to be able to use ssh keys, having them on the image will save a lot of time.

[quozl]

@g-vidal, sounds great, have you published your work anywhere? Disclosure: I work for One Laptop per Child.

@drtyhlpr, both your SSH_{USER,ROOT}_PUB and @theOtherNuvanda's AUTHORIZE_SSH_KEYS have merit and use-cases.

Bike shedding:

For systems to be accessed by others, I wouldn't let them onto my build host, so SSH_ROOT_PUB would be best. I suggest using _KEY or _KEYS rather than _PUB, because my first reaction is "socialising and drinking venue".

For systems to be controlled only by me, AUTHORIZE_SSH_KEYS is adequate. I suggest renaming the option to SSH_COPY_KEYS.

ENABLE_ROOT_SSH might also change to SSH_ENABLE_ROOT or SSH_PERMIT_ROOT_LOGIN=yes since it sets sshd_config PermitRootLogin.

[jp-hoehmann]

I just did it like that because I am lazy. ;) This way any admin can check on it when something is not working and nobody needs to get the guy with the key.

I will update my fork to make the options take a file name rather than a boolean as you suggested and add a second one for the regular user. If somebody wants to grant access to all sysadmins, they can still specify the file as “/root/.ssh/authorized_keys” anyways, so I don't think a third option is needed.

SSH_ROOT_PUB or SSH_ROOT_KEYS?

[jp-hoehmann]

Opened #69

[drtyhlpr]

Feature added:
15fff1e

Thanks for your work theOtherNuvanda patching was a little more complex then I thought first.

[drtyhlpr]

please test the new added ssh features. ssh settings are critical to the system security.

[quozl]

Reviewed 15fff1e.

• OpenSSH already does not support SSH-1; it was replaced by SSH-2 some years ago,
• OpenSSH uses authorized_keys for SSH-2 keys, with a fall-back to authorized_keys2 which was used during the transition,
• your use of authorized_keys2 is unnecessary and adds confusion; mentions of authorized_keys2 should be avoided, and replaced with authorized_keys.
• documenting OpenSSH default behaviour in the configuration file is redundant (adds an extra place for that documentation) and increases future maintenance.

Not tested.

[drtyhlpr]

hi the man page says that both protocol versions are supported and that authorized_keys2 is the default file to use for protocol 2 public keys. in my point of view using authorized_keys2 does not add confusion but clarity about the version.

documenting OpenSSH default behaviour

what do you mean with that?

[quozl]

You may be reading a different manual page to mine. I'm typing man authorized_keys which opens the sshd(8) page, and the section AUTHORIZED_KEYS FILE FORMAT says

     AuthorizedKeysFile specifies the files containing public keys for public
     key authentication; if none is specified, the default is
     ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.

Yes, protocol 1 keys are supported by OpenSSH, but the default is disabled in the packages you are using. See the Protocol clause in /etc/ssh/sshd_config which is normally set to 2. Anyway, whether protocol 1 keys are used or not, my point is that both protocol 1 and protocol 2 keys are read from the file authorized_keys. ssh-keygen generates protocol 2 keys unless -t rsa1 is used.

The use of authorized_keys is generally accepted practice; ask around, get a feel for what is used by others. ssh-copy-id also uses that name, as do other utilities, services, and instructions on the internet.

On documenting the defaults. When you add documentation to rpi23-gen-image about how OpenSSH defaults are set upstream or packaged, you're making work for yourself in future, which has no value. It is best to leave the documentation for OpenSSH to the OpenSSH project developers or the Debian maintainer. Especially as generally accepted practice continues to change.

[drtyhlpr]

I know when sshd is about to use protocol version 2 and how to generate protocol 1 keys. I am used to save the keys into a ...2 file - for clarity - because openssh still supports v1 (for compatibility reasons?!).

I used $name2 and mentioned v2 in the README to make sure noone will use a v1 key and find out that it does not work after building and after successfully booting.

I will remove to 2 from the filename soon to stop any confusion.

[quozl]

Thanks. You can change your personal practices to use the shorter file name now; it will save you a tiny bit of typing. 😁

Apart from your own clarity, using authorized_keys2 has no purpose, and it was deprecated 17 years ago.

OpenSSH will use a v1 key from authorized_keys2 if Protocol 2 is changed to 1,2 or 2,1, so the name of the file is no protection.

OpenSSH only reads an authorized_keys2 file if there is no AuthorizedKeys option in /etc/ssh/sshd_config. Reference: line 100 of pathnames.h and line 323 of servconf.c;

#define _PATH_SSH_USER_PERMITTED_KEYS  _PATH_SSH_USER_DIR "/authorized_keys"
#define _PATH_SSH_USER_PERMITTED_KEYS2  _PATH_SSH_USER_DIR "/authorized_keys2"
...
	if (options->num_authkeys_files == 0) { // the option was omitted
		options->authorized_keys_files[options->num_authkeys_files++] =
		    xstrdup(_PATH_SSH_USER_PERMITTED_KEYS);
		options->authorized_keys_files[options->num_authkeys_files++] =
		    xstrdup(_PATH_SSH_USER_PERMITTED_KEYS2);
	}

See also the end of /usr/share/doc/openssh-client/NEWS.Debian.gz:

openssh (1:3.0.1p1-1) unstable; urgency=high

  As of version 3, OpenSSH no longer uses separate files for ssh1 and ssh2
  keys. This means the authorized_keys2 and known_hosts2 files are no longer
  needed. They will still be read in order to maintain backward
  compatibility.

 -- Matthew Vernon <[email protected]>  Thu, 28 Nov 2001 17:43:01 +0000

It seems unnecessary to give precautions against using v1 key given that OpenSSH is packaged by Debian with Protocol 2 in /etc/ssh/sshd_config.

I don't think anybody will accidentally use a v1 key, because it is hard to make one, and if they do the sshd configuration will stop them.

[drtyhlpr]

you have definitely convinced me :)

[jp-hoehmann]

Quick question: What is the difference between SSH_ROOT_AUTHORIZED_KEYS and SSH_ROOT_PUB_KEY?

Reading the patch, they seem to get treated equally, simply being concatenated into authorized_keys. Wouldn't it be better to name them SSH_ROOT_AUTHORIZED_KEYS_FILE1 and SSH_ROOT_AUTHORIZED_KEYS_FILE2 – or something like that – to reflect them being interchangeable?

[drtyhlpr]

SSH_ROOT_AUTHORIZED_KEYS is meant to be used if you want to add all public keys of a authorized_keys (list of public keys) file. SSH_ROOT_PUB_KEY is meant to be used if you want to simply add one .pub file. one uses a copy of the file the other simply appends the pub key if file exists.

I am a little bit confused because from you post before I did understand that you simply like to copy the authorized_keys file because lazy. In general its true it would be possible to only have SSH_*_PUB_KEY parameters that will support both a single pub key or a list of pub keys like in authorized_keys.

[quozl]

I see the doubt. I had expected SSH_ROOT_PUB_KEY to be a key, but it is instead a file containing a key. So SSH_ROOT_AUTHORIZED_KEYS and SSH_ROOT_PUB_KEY are functionally identical. If SSH_ROOT_PUB_KEY was a key, then use echo not cat.

[drtyhlpr]

I have a doubt of adding long string of pub key to the command line parameters. It was meant to be a file on purpose! I just added the "copy AUTHORIZED_KEYS file" because it was requested. I am still at the point - does the regular rpi user realy need multiple SSH pub keys to login for one user? - I can only think about laziness here - "I dont know witch key i need - lets take all". I will remove the AUTHORIZED_KEYS parameters soon and just keep the PUB_KEY parameters ("this parameters also supports a list of public keys".)

[quozl]

Long strings are fine. Test it if you are not sure. Yes, with the very low price of rpi, it would not be surprising to have more than one, and therefore more than one public key to add. I think the main question for you is what does rpi23-gen-image need, and why can't users of rpi23-gen-image write a custom script to do these steps instead of manually adding a key as @gfa said to begin with? Is it just a convenience? If so, just one key, and for root only. That would be convenience without complexity.

[drtyhlpr]

I fixed it. I dont want to invest more time on a in general "simple cp of a existing file (that may contain one or more public keys". I think its a good solution to simply use the SSH_*_PUB_KEY for adding a key (mentioning in the readme that you can even add mutiple keys in a file - if you realy need it)

[drtyhlpr]

ps. I asked myself - how often did I copy a (full) authorized_file to a system? how often did I see someone to copy a (full) authorized_file to a system? How often was I asked to copy a authorized_file to a system? How often did I read to copy a (full) authorized_file to a system? 0 times in 20 years+.

ps. in my opinion - long strings are not fine if you work on the command line (technically possible: getconf ARG_MAX: check). there are very few people I know that regularly use forward-word or even shell-forward-word (and other shell a likes) to move between words/arguments on a long command line - they to use char-by-char with left-right arrow keys or worst. (also in term of the "i asked myself" style above - all the docs and tutorials I found about ssh public key auth use "cat .pub" file instead of echo [copy and pasted key line].)

[gfa]

@drtyhlpr I've just tested the script, everything works as "advertised" 👍 thank you so much

also i can confirm uboot works on the rpi3

PS: only one minor issue, rc.local calls your infrastructure

[drtyhlpr]

@gfa ok cool.

does uboot work on rpi3 if you add a dtoverlay= to the config.txt? if I did try it only went into LSD color screen without uboot or system booting. I tried different stuff and did not get it working.

PS: only one minor issue, rc.local calls your infrastructure
I dont understand, please be a little bit more specific :) what line ?

[gfa]

@drtyhlpr
uboot does work, but as soon as i added dtoverlay=pi3-disable-bt the rpi failed to boot
i can't tell you about the screen as i use the pi headless.
I use stretch FYI

regarding ssh key injection, super happy about it, i made a few other builds last night. feel free to close this issue :)

edit: what i mentioned about rc.local is on this line
https://github.com/drtyhlpr/rpi23-gen-image/blob/master/files/etc/rc.local#L14

[drtyhlpr]

rc.local fixed thanks for the hint!