On Sat, Mar 5, 2016 at 8:08 AM, Dag-Erling Smørgrav <des@xxxxxx> wrote: > Nico Kadel-Garcia <nkadel@xxxxxxxxx> writes: >> Dag-Erling Smørgrav <des@xxxxxx> writes: >> > It is relatively trivial to write a PAM module to do that. >> Which will have the relevant configuration overwritten and disabled >> the next time you run "authconfig" on Red Hat based sysems. I'm not >> sure if this occurs with other systems, but tuning PAM is like tuning >> SELinux: it's a lot of extra work with little return-on-investment, >> and in this case for a change that will irritate *every single user* >> and break a number of API's. I can't recommend this approach. > > It won't break any APIs, and have you considered that OP might not have > a choice? That this may be a legal requirement? > > DES As described, it won't break the SSH API per ses. A careless version could break rsync over SSH and tools that may rely on automatic connections via SSH keys or shared authentication models such as Kerberos. However, it's the API for tools that users run locally that are most likely to break. Scripts that run remote commands automatically and use "ssh -n" may break. And gods forbid, because it would be foolish but I've seen it done, scripts that have the password input and a full set of scripted command line interactions hardcoded as part of a remote shell interaction, one prevously recorded with the "script" command, will need to have an extra option added to handle this "reply yes" requirement. A particular Perl command I just saw with quite a complex little MySQL interaction leaps to mind and makes me shudder in horror. My concern for API's is basically that of an old XKCD cartoon, https://xkcd.com/1172/ . It's easy to break people's workflows that you never even realied existed. As already pointed out, if necessary, this can be done basically in /etc/profile (depending on the shells supported). That already resolves the "don't run this on automated remote SSH scripts" to avoid breaking non-interactive tools like rsync, and it gets you away from having to support a binary module that doesn't exist upstream and which is vulnerable to bog standard upgrade reconfigurations. I've run into support issues with just such PAM integration, with a senios sysadmin who wrote his own settings and couldn't be bothered to make the PAM configuration tool idempotent, so it *kept appending the required option* every time the configuration tool ran. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
