ssh vs. scp in custom PAM module

Hi,

- here my question again,
this time with more background detail

- I implement a custom PAM lib

- two linux boxes A and B; B runs an Openssh server
- use case 1: ssh login from A to B
- use case 2: scp files from A to B

- in case of the ssh login I want to give the user an info text
to read; user has to confirm typing "yes";
then, and only then, login is allowed

- the code works, but the side effect is to have to type "yes"
also in case of the scp transfer; which is not wanted and not
possible because of a bunch of automated scp based stuff

---> I have to distinguish inside my custom PAM code;
tried getenv("SSH_CLIENT") / getenv("SSH_TTY"),
but both are "null" at the time I call my custom lib
(latest inside the "auth" section of the config file)

?? any other idea what could be used to differntiate ??

regards,
Uwe

Uwe Drekert <(E-Mail Removed)> writes:
> - I implement a custom PAM lib

Define "a custom PAM lib"

> - in case of the ssh login I want to give the user an info text
> to read; user has to confirm typing "yes";
> then, and only then, login is allowed

Did you actually mean "a custom PAM module"?

> - the code works, but the side effect is to have to type "yes"
> also in case of the scp transfer; which is not wanted and not
> possible because of a bunch of automated scp based stuff
>
> ---> I have to distinguish inside my custom PAM code;
> tried getenv("SSH_CLIENT") / getenv("SSH_TTY"),
> but both are "null" at the time I call my custom lib
> (latest inside the "auth" section of the config file)
>
> ?? any other idea what could be used to differntiate ??

You can't - scp basically uses ssh (meaning the ssh program itself) as a
pipe to start and communicate with another scp instance on the server.
It's like running "ssh user@host ls": all sshd knows is that it should
run a certain command instead of opening a pty and forking a shell - and
it doesn't even figure *that* out until *after* authentication is
complete.

You can differentiate on pam_user if you use different users for the
automated transfers. If permissions are an issue, use aliases - i.e.
users with the same UID as other users, like the classic BSD "toor"
user. I would recommend implementing this as module options, so you can
specify which users or groups to include or exclude in pam.conf, instead
of hardcoding them. If you're on a system that uses OpenPAM instead of
Linux-PAM, the openpam_get_option() function makes that very easy;
otherwise, you have to use getopt() or similar to process the argc /
argv you get from the stack.

DES
--
Dag-Erling Smørgrav - (E-Mail Removed)