I think what you are looking for is ident <https://en.wikipedia.org/wiki/Ident_protocol>, but while I could see using it for auditing purposes I would be uncomfortable recommending it as an authentication mechanism. You would need to be running some identd (available in any Linux distro, usually gidentd), often through inetd/xinetd. --Greg On Sun, Jan 03, 2016 at 01:03:27AM +0100, Esben Nielsen wrote: > Hi, > > Question: > > Can a TCP server (running on the same host as the OpenSSH server) know > the user id/name of a user forwarding an TCP port ? > > I.e. if someone on some client machine does > ssh -L9999:localhost:9999 someuser@somehost > nc localhost 9999 > and a service accepts the connection on port localhost:9999 on > somehost, can it somehow safely read out the user name "someuser"? > > Long explanation: > > We consider using SSH port forwarding as a way to enforce > authentication and authorization in an old application (running on > Linux) exposing a quite a few TCP connections. > > On the client side the clients can use OpenSSH client or Putty to make > a Socks proxy. If their application framework already supports Socks > they do not have to change much to connect. Or something like libssh > can be used to include the ssh client side into the application. > > On the server side the sshd_config can be used to set up allowed ports > per user or group. This is, however, not good enough, because the > application will not know the original user id, so it can niether log > actions, nor allow or block actions not allowed for that particular > user. > > So my question is: > Is there any way to let the TCP application server know the user id of > the SSH forwarded TCP connection? > If no, would it be possible to set up the OpenSSH server to do > something special per destination port basis, such as connecting to a > UNIX socket instead of a TCP socket or sending the user ID as the > first thing on the connection ? > (We could use UNIX socket forwarding, but the the client side can't > use a Socks, and most other clients such as libssh does not support it > either...) > > Regards, > Esben > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
