Probably not.
The man page for pam_group says:
Only the auth module type is provided.
And since SSH doesn't use PAM to authenticate when it uses public keys, the auth modules are not used.
As to why pam_group only works as an auth module and not as a session module, I can't say.
If you can use SSH agent forwarding, there actually is a way: pam_ssh_agent_auth.so (source here) is a PAM module that can do what you ask. It's available in Debian and Ubuntu as package libpam-ssh-agent-auth and as CentOS package pam_ssh_agent_auth.
# Debian/Ubuntu:
apt update; apt install libpam-ssh-agent-auth
# CentoOS
yum install pam_ssh_agent_auth
Security Considerations
You should evaluate the risks of using SSH agent forwarding, as the developer says:
There are caveats of course, ssh-agent forwarding has it’s own security risks
which must be carefully considered for your environment. In cases where there
are not untrustworthy intermediate servers, and you wish to retain traceability,
accountability, and required authentication for privileged command invocation,
the benefits should outweigh the risks.
If you make sure your KeeAgent has the option Always require confirmation when client program requests to use key set, this even offers you a degree of protection against someone else with root access on the remote host: if you get a SSH key request confirmation dialog with no obvious reason, you'll know that someone is trying to abuse your SSH agent connection.
If you also make sure you'll always lock your KeePass and/or workstation screen when you step away from it, I think this should offer pretty good security; it's certainly more secure than using NOPASSWD in sudoers. It is also better than allowing root logins with ssh keys only and adding everyone who is allowed to log in as root to root's authorized_keys file because it maintains the advantages of sudo.
Usage
To use it, you basically add this as the first auth line in /etc/pam.d/sudo:
auth sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys
A simple sed command to do this (adds it to the second line, since the first is a comment):
sed -i '2 i\auth sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys' /etc/pam.d/sudo
Then add the public SSH keys of users that should be authorized to use SSH-authenticated sudo to /etc/security/authorized_keys in the usual single-line OpenSSH compatible format.
Then configure sudoers to preserve the environment variable SSH_AUTH_SOCK by editing the sudoers file (use visudo). Add this line to the section with the other Defaults.
Defaults env_keep += "SSH_AUTH_SOCK"
Then, you need to make sure that your ssh client allows agent forwarding. In PuTTY you need to check this:
While testing this, don't forget to terminate your sudo sessions with sudo -k.
Best Answer
SFTP is a command access to file operations, with the restrictions from the account you use. You must use ssh for make more administrative operations, making impossible use sudo and SFTP at same time. If you need access to the entire disk without restriction using SFTP, do it using the root account. Anyway you can make a login with root on sftp and ssh at same time, of course, using two different sessions.
The security keys improve the security and make more easy the logging, not requiring keyboard input. Only helps to make login, you can had several passwords for every account user and had the same effect.
EDIT: I forgot: you can create another account with the same effect than root if you assign the user id to 0, but not had any sense, being dangerous in the same way. Could give some obfuscation if somebody try to login like root, but apart of that, not had much sense.