> Following is an outline of the Client/Server interaction promised > earlier, to support SSH authentication with TACACS+…
Thanks for the clear description. > The key decision for the solution is: where should the SSH > authentication proceed. [...] > Therefore, the solution that will be presented has the following model: > - The SSH client and the TACACS+ client (acting here as the SSH > server) continue with the SSH processing roles they have now. > - The TACACS+ authentication is extended to allow the TACACS+ client > to request the public keys from the TACACS+ server, to ease ssh-key > management > - The TACACS+ authentication is extended to communicate the results of > the TACACS+ client authentication processing to the TACACS+ Server, > for the TACACS+ Server to log centrally and grant the final result for > the TACACS+ client to enact. > All other aspects will continue to use the TACACS+ protocol for > processing of SSH requests as they do now. As an operator (at a NREN/mid-size ISP), I like this approach. It would allow us to provision SSH authentication material (public keys/possibly certificates in the future) in a sane way, without requiring fundamental infrastructure changes - beyond the obvious required upgrades to TACACS+ client and server implementations. Existing authorization and logging will hopefully continue to work as before. > This approach will utilise the data field paradigm discussed earlier > in the thread. We will follow with a document that describes the > complete solution in detail. Looking forward to it. Cheers, -- Simon. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
