https://bugzilla.mindrot.org/show_bug.cgi?id=2246
Kirill 'kkm' Katsnelson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #10 from Kirill 'kkm' Katsnelson <[email protected]> --- Damien, another important thing to consider here is the interactive vs. non-interactive nature of the session. When the used logs on interactively, the pam_systemd session module is usually in the stack, and this creates the whole shebang of the session for the user. However, when the host is connected for port or stream forwarding or the subsystem only (jump host, or an sftp connection), the interactive session makes no sense. On a jump proxy (thanks for implementing the ProxyJump shortcut, by the way, my favorite addition ever!), I normally modify the distro-supplied PAM configuration to bypass systemd user session mechanism. Unfortunately, this is not as clear cut as i wished it were. Is, for one, scp an interactive login or not? From the client's point of view, it's not, but the server cannot tell (if I understand how the protocol works); a command is just a command. The same goes for the ProxyCommand, which the server sees as _just_ a command. Does it need the full user environment, such as, e. g., active DBus session? The server has no idea at the moment when the service is started. One feeble attempt to, at the very least, _guess_ whenther an interactive session is wanted is the PTY request by the client. Another strong clue is, when the server is in forward-only mode ('MaxSessions 0'), then the session is clearly non-interactive. A request for a subsystem with MaxSession=1 is also likely, but again, not necessarily noninteractive. And then what to do with connection multiplexing: I usually do not open an sftp session and then multiplex an interactive shell, but people use complex tools like ssh in unimaginably complex ways. All in all, this guesswork is messy and as far away from The Right Thing as I could only think. Maybe there should be an explicit interactive session request in the protocol, like "client requests an { interactive | non-interactive } logon session", with the current behavior (admin's discretion) as the default? There are possible security implications from server misconfiguration, naturally, but if anyone is using systemd session mechanism as a security control, they are doing it wrong anyway. Another possible way to approach this issue is akin to AuthorizedKeysCommand: let a script to decide what pam service to use, given all the interesting information about the request (the command, auth method, the remote and local endpoints, etc.). This would also cover the original idea of using the token substitution, where the impetus for the change was, as I understand, is to decide on the PAM service based on the auth method, which would also be made available in the external command's environment. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
