Supporting the from= option in authorized_keys

[Stephen Morton]

Hello Sitaram,

There has been some discussion in this group in the past about adding
support for the ssh "from=" option [3] to gitolite's generated
authorized_keys [1] [2]
and I don't believe you have been directly against it.

I'm interested in using from= for the following use-case.

I have a large number of git users, and if a ssh key somehow becomes
known, I'd like that it not be easily usable.

It's a big company and I cannot make a list of all "allowed subnets"
to whitelist and check in a VREF. (It is so complicated and
dynamically changing as to be effectively impossible. And anyway, the
address space would be so large that whitelisting alone would be of
limited benefit.)

However, if a key were restricted to an the IP address of the user's
workstation, that would make it very much not usable in the wrong
hands. (If the person's workstation is compromized, there's really not
much I can do. Well, I could require ssh key passphrases, but for me
that introduces more complications for me which is a whole other
discussion.)

We have a mechanism to upload keys to the server where they are pushed
into gitolite-admin/users. A user runs a script which makes an https
call, with authentication via the corporate directory, and the script
uploads their ssh public key to the gitolite server. We then take
their key and push it into gitolite-admin/users/ .

My idea is to take the REMOTE_ADDR pushing the key and put it in the
comment field of the key as essentially "from=$REMOTE_ADDR". Then the
'ssh-authkeys' trigger could, given a command-line option, add any
"from=<hostname or ip>" it finds in the comments to the ssh
authorized_keys options.

Would you be receptive to a small patch that accomplishes this?
I won't even start working on it unless I know you think it's a reasonable idea.


BR,
Stephen



[1] https://groups.google.com/forum/#!message/meRd4X6xW0s/bD4a0cBL8ZkJ
[2] https://groups.google.com/forum/#!message/Gosebx2fFjo/8-BMHjMggXMJ
[3] https://linux.die.net/man/8/sshd

[Sitaram Chamarty]

Hi Stephen

Very sorry for the long mail; got somewhat carried away.

TL;DR:

- I like the basic ides, but you seem to assume the user -> IP
mapping is a long term one (read below for why I think so),
which I don't think is true in general.
- A better method would be to have the user -> IP mapping be
recorded **somehow**, at some regular interval, and then a
simple "ACCESS_1" trigger checks that IP.
- Both the recording of the IP and the check would be very
site specific (see below for how kernel.org does it, for
instance, as well as a generalisation of that notion I
created in a project called "totport").

----------------------------------------------------------------------

And now for the longer version :-)

I think that would be a good first level protection against some
of the issues you (and maybe others) have / could have.

While I'm not arguing against such additional protection, I have
a few thoughts.

1. You're recording the IP at the time he uploads his key.
Assuming no one is uploading the key every day or week, that
means the user -> IP mapping is kinda fixed.

This is not true in general, in fact quite the opposite.

This is the crux of my objection to the specifics of your
proposal; everything else kinda follows from that.

2. Similarly, updating the authorized_keys file *directly* is
also a non-scalable solution when you have large numbers of
users with IPs changing frequently.

3. For the general case, it needs to be something much more
dynamic.

For example, here's how kernel.org (or rather, Konstantin
Ryabitsev) has done to add 2FA to gitolite. Broadly
speaking:

- (one time per user) provisioning each user with a TOTP
mechanism (Konstantin uses Yubikeys, but a normal TOTP
app on a phone will do fine if you want to consider
this)
- (once per day) user runs a special gitolite command,
like: "ssh git@host validate 123456". The program
validates the TOTP code and, if valid, records the IP as
being valid for this userid for the next 24 hour (or
whatever period you decide is safe).
- (anytime for the next 24 hours) user runs git push etc.
from the same IP and it all works. From a different IP,
the user is rejected. (Konstantin does this via a VREF,
because kernel.org is all open source and he only cares
about pushes. You and I would do it in an ACCESS_1
trigger, so it covers reads *and* writes.

(Side note: The totport project I spoke of is at
https://gitolite.com/totport, and is much more generic; it
protects not just gitolite, but any arbitrary TCP-based
service on any internal host protected by a bastion host.
It uses the same broad technique outlined above.)

So what it comes down to is:

- some way to record the user's IP in a way that involves more
than just the ssh key

- some way to be able to check, given a $GL_USER and the IP
address from $SSH_CONNECTION, that this user and this IP
map to each other in our recorded list.

Both these things are very clearly site specific.

- for the recording of the IP, in your case, for example, you
have some external-to-gitolite web server that can validate
a user and record his IP. Others may go the TOTP way, or
have some other method entirely.

- even the checking can vary. For example, I can easily see
some sites saying that the IP only needs to match in the
first 3 octets for IPv4, i.e., any IP in the same /24 subnet
as the validated one is fine. So even that is not as simple
as "compare recorded IP for this user with first word of
$SSH_CONNECTION".

So now you see why I have resisted this till now. It can't be
made generic enough to put in gitolite, without gitolite going
way out of its "core competence" :-)

Finally, note that ssh-authkeys is not considered "core"; feel
free to modify it and put your modified copy in a directory
pointed by LOCAL_CODE in the rc file, and gitolite will pick up
your copy instead of the shipped one.

regards
sitaram

> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/CAH8BJxE%2Bpb6BbJTPi%2BJDJYqLM2CfigAX7KRrWV3dJnoa4QcLHA%40mail.gmail.com.

[Stephen Morton]

Thanks Sitaram for the helpful information.

I like your explanation and the two possible solutions you've provided.

I hadn't realized that the triggers were non-core, and for me I think
the best solution will be to modify my own copy of ssh-authkeys. My
use-case is different from gitolite.org's in that I explicitly expect
people's workstations to stay put and if they do change IP addresses,
that's something to worry about.


BR,
Stephen

p.s. For posterity in the group, I mis-copied the links to the topic
threads in my original email. Here are ones that I believe work.
https://groups.google.com/forum/#!topic/gitolite/meRd4X6xW0s
https://groups.google.com/forum/#!topic/gitolite/Gosebx2fFjo

[Mathieu Arnold]

On Fri, May 01, 2020 at 12:36:23PM -0400, Stephen Morton wrote:

> There has been some discussion in this group in the past about adding
> support for the ssh "from=" option [3] to gitolite's generated
> authorized_keys [1] [2]
> and I don't believe you have been directly against it.

In the FreBSD ports tree, we have a small patch that allows users to
have ssh keys with options:

https://svnweb.freebsd.org/ports/head/devel/gitolite/files/patch-src_triggers_post-compile_ssh-authkeys?revision=532452&view=markup

--
Mathieu Arnold

[Sitaram Chamarty]

Interesting; thanks for the link. This is probably the least
intrusive way to deal with this, I agree.

But... if they're adding this *manually* to each pub key, it's
fiddly manual editing of a very rigidly (and probably fragile)
format text file -- neither scalable nor elegant, and it still
seems to assume a long term mapping between user -> IP address.

If you're doing it in an *automated* manner from, say, some CSV
file or list, then why not make gitolite take that data directly
and deal with blocking access? As I wrote in an earlier mail,
that's basically 2 lines of shell, modulo whatever you need to
do to get the "allowed IP" for $GL_USER from that CSV file.

For people who are using this feature: how often are you having
to edit an IP address and rerun ssh-authkeys even though no pub
key has been changed (or added or removed)?

Basically, am I really wrong in insisting user's IP address
changes a lot more often than their pubkey?

I'm curious what you all think about that statement.

regards
sitaram


>
> --
> Mathieu Arnold

>
> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/20200504071224.gdtn6nbgzpuexxig%40aching.in.mat.cc.