Clément Péron
2020-Feb-12 11:00 UTC
Identify multiple users doing reverse port FWD with their pubkeys
Hi Jochen, 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. For example I try to set an environnement variable for each pubkey in the authorized file but can't get it when doing reverse forwarding. Then I try to have a different permitlisten port but it doesn't work with dynamic port :(. Can i create a tunnel for each device or execute a specific command to identify a posteriori which device created the reverse forwarding port? Thanks, Clement> > 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 ... > > Kind regards, > -- > Jochen Bern > Systemingenieur > > Binect GmbH > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Jochen Bern
2020-Feb-12 13:54 UTC
Identify multiple users doing reverse port FWD with their pubkeys
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>
Clément Péron
2020-Feb-12 14:48 UTC
Identify multiple users doing reverse port FWD with their pubkeys
Hi Jochen, On Wed, 12 Feb 2020 at 14:54, Jochen Bern <Jochen.Bern at binect.de> 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 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.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 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. >