Firstly, I have had a recent question about SFTP user setup via support. So I have been working on a blog post to step through the process to achieve an ends somewhat similar to what you are trying to achieve. It doesn't explicitly do what it sounds like you appear to want to do. My "tutorial" covers creation of an SFTP user with read/write to /var/www/wordpress, but not an SSH login.

How to support (relatively) secured "jailed" SFTP user who can log in and run some commands was going to be "part 2". But perhaps I should consider that sooner? I'm not sure...

Anyway, the first thing that strikes me is the permissions. 766 (owner read/write/execute, group read/write, everyone read/write) is a very weird permission for a directory! Firstly, that's because the "execute bit" on directories has a very different meaning than it does on files. Without the execute bit on a directory, it is not possible to view the contents (even if you have read/write). So that would explain why your user can't access the /var/www/wordpress.

Generally in /var/www directory permissions should be 755 (owner read/write/execute, group read/execute, everyone read/execute) and 644 for files (owner read/write, group read-only, everyone read-only). But as you want the group ('www-data') to also have read/write access (I assume?) then you'll need 775 (owner read/write/execute, group read/write/execute, everyone read/execute) on directories and 664 (owner read/write, group read/write, everyone read-only) on files.

Furthermore, I'd suggest setting the "setgid" bit for directories in /var/www. That means that new files and directories created by your user should inherit the group owner of the parent directory ('www-data' in this case) rather than your user's default group (by default it will be a group with the same name as the user). In octal notation, the permission is 2775 (the leading '2' is 'setgid'). An alternate path to achieve a similar ends is to make 'www-data' the primary group of your user (rather than a secondary group).

Assuming you want to set the 'setgid' bit, here's how to set the permissions like that:

find /var/www -type d -exec chmod 2775 {} \;
find /var/www -type f -exec chmod 664 {} \;

Alternatively (or as well) you can set the new user's primary group as 'www-data' like this (assuming new user name: 'new_user'):

usermod -g www-data new_user

Another thing to keep in mind is that when you sftp in, your user will start in their home dir (by default will be '/home/new_user' by default - where 'new-user' is the actual username). So to access /var/www/wordpress, you'll need to use it's absolute path.

Otherwise, I think you're good.

One other thing to keep in mind though is that whilst any new files created by your new user should inherit the 'www-data' group, because the default umask is 022 the group won't have write permissions by default.

I didn't really want to go into umask too much, but it's probably worth explaining so the next bit makes sense. Default permission for directories is 777 and files is 666. The actual permission of new files/directories is worked out by subtracting the user mask (umask) from the default values. So assuming defaults, new directories should be 755 and files 644. I.e.:

777 - 022 = 755
666 - 022 = 644

So if you want the group to get the same permissions as the user, you'll need to either manually fix files and directories (by adding group write permissions - or rerunnign the find commands above) or change the use's umask. E.g. if you set a umask of '002' that will ensure that the group gets write access by default. I.e.:

777 - 002 = 775
666 - 002 = 664

Please note though that umask is a "per user" setting, so will mean that all file/folders created by this user, anywhere on the system will have these permissions. So that has security implications.

Which brings me to my final question, why is this user a member of the sudo group? I would suggest that it's a better idea to not give this user sudo privileges and just log in as root when you need to do admin. That would make setting a non-standard umask less of a security risk too.