Hi Jochen,
On Wed, 12 Feb 2020 at 14:54, Jochen Bern <Jochen.Bern@xxxxxxxxx> wrote:
>
> On 02/12/2020 12:00 PM, Clément Péron wrote:
> > On Wed, 12 Feb 2020 at 00:16, Jochen Bern <Jochen.Bern@xxxxxxxxx> 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.
Actually my AuthorizedKeysFile is an AuthorizedKeysCommand that
connect to an API and get if the public keys are allowed or not.
So I can easily manage to add a "command=" or "environement=" for each
device and adding their "real-name".
Do you think about something like this?
If for device-1 I do something like this.
command="echo $(date) >> device.log; echo device-1-pid:$$ >>
device.log; sh;" ssh-rsa AAA......
Then I can see in device.log
Wed Feb 12 15:43:05 CET 2020
device-1-pid:5080
And from "sudo netstat -natp"
tcp 0 0 127.0.0.1:43867 0.0.0.0:*
LISTEN 5079/sshd: device
There is a small mismatch between the PID of the command shell and the
sshd command.
>
> 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.
But the user can also disable the command with -NT (or maybe I'm wrong here?).
I think I can assume that's all my device can be trusted to execute
the command when they connect.
>
> 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.
client IP are not stable, so I can't use this solution :(
Thanks a lot for your help!
Clement
>
> 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@xxxxxxxxx
> 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.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
