Identify multiple users doing reverse port FWD with their pubkeys

[Jochen Bern]

On 02/12/2020 12:00 PM, Clément Péron wrote:
> On Wed, 12 Feb 2020 at 00:16, Jochen Bern <Jochen.Bern at binect.de> wrote:
>> On 02/11/2020 07:07 PM, Clément Péron wrote:
>>> - I have X devices (around 30) and one SSH server
>>> - Each of them have a unique public key and create one dynamic reverse
>>> port forwarding on the server
>>> - All of them connect with the same UNIX user (I don't want to create
>>> a new user each time, I add a new device)
>>>
>>> When I connect to the server, I would like to know which pubkey as
>>> open which reverse port.
>>
>> The auth happens when the device opens the SSH connection, and if your
>> logging verbosity is high enough, the pubkey's fingerprint will be
>> written to the log. If you really need to identify *the pubkey*, you'll
>> have to grab the PID of the sshd process holding the reverse port (can
>> be gleaned from the output of "{netstat,ss} -natp") and then search
>> through the logs for the lines of when it got started.
> 
> Thanks for the solution, Indeed it will works but it's not really
> proper, I would like to find a way like having a different parameter
> for each pubkey in the authorized key file and then be able to
> identify which device did the established connection.

The parameters in the Authorized_Keys File Format that promise an
ability to carry over ~30 different values into the running process
(rather than being used only by sshd itself in the login / tunnel setup
process, and then forgotten) are command=, environment=, and tunnel=.

*If* you can throw command= at the pubkeys in question (you AFAIR did
not yet say what the devices do with the actual login, so I assumed that
they might need/get a general shell), you've pretty much won; add an
(ignored) parameter to the command, make a command/executable that sets
an env var or massages $0, add/remove an entry in some lookup table as
the executable starts/terminates, whatever.

environment= is IMHO useless for this scenario, because unless you
*also* use command=, the logged-in user can manipulate env vars any way
he wants.

tunnel= sets up / removes a /dev/tun* device, that's quite a bit of
overhead just to get the info you want ... :-}

Still, *if* you can identify devices by their client IP (*and if* you do
the lookup on the server with root privileges, which is IMHO a necessity
to get info that the devices cannot falsify), I'ld still recommend to
just two-pass parse the output of "netstat/ss -natp", first to get the
sshd's PID from the LISTEN for the reverse port, then to get the
ESTABLISHED SSH connection with the client IP.

On 02/12/2020 08:46 AM, Philipp Marek wrote:
>> [... suggestion of log parsing ...]
> An unpriviledged user can't filehandles of other users.
> And grepping through logs isn't allowed for normal users as well -
> especially not the authentication logs...

Yes. And identifying the client that has the port XY forwarded to itself
is *also* a bit of information that *should* require admin privileges on
the central server.

>> Whereas the *IP* of the device in question can be read on demand from
>> the same netstat/ss output, just look for the incoming SSH connection
>> held by the same PID ...
> No. Just no. ;)
> Look at $SSH_CLIENT and/or $SSH_CONNECTION for that kind of information. 

Clément is trying to get that information for whichever of up to 30
current logins has a specific port forwarded back to itself. How are you
going to find out, sans admin privileges, *which* sshd process' env vars
you need to read?

Kind regards,
-- 
Jochen Bern
Systemingenieur

T  +49 6151 9067-231
F  +49 6151 9067-290
E  jochen.bern at binect.de
W  www.binect.de

Binect GmbH
Robert-Koch-Straße 9
64331 Weiterstadt

Geschäftspost. Einfach. Besser.
Wir sind zertifiziert: https://www.binect.de/zertifikate.html
Melden Sie sich zum Newsletter: https://www.binect.de/newsletter.html

Die Portoerhöhung ist da!
https://www.binect.de/portoerhoehung-2019?utm_source=email&utm_medium=button&utm_campaign=portoerhoehung
https://de-de.facebook.com/binect/ -
https://www.linkedin.com/company/binect-gmbh -
https://www.xing.com/xbp/pages/binect-gmbh
Binect Erklärvideo ansehen: https://www.youtube.com/watch?v=LhL1BZ8fci0

Geschäftsführung: Dr. Frank Wermeyer
Unternehmenssitz: Weiterstadt
Register:         Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID:  DE 221 302 264

MAX 21-Unternehmensgruppe
✁
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anhänge an dieser Nachricht durchzuführen.
Wir schließen, außer für den Fall von Vorsatz oder grober
Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200212/a2b6d1c2/attachment-0001.p7s>