After four years this answer deserved an update. While originally I used authorized_keys myself and would probably use it still in some select cases, you can also use the central sshd_config server configuration file.
sshd_config
You can designate (for your particular use case) a group, such as proxy-only or Match individual users. In sshd_config. This is done after the global settings and revokes, repeats or refines some of the settings given in the global settings.
Note: some of the syntax/directives used in sshd_config(5) are documented in the man page for ssh_config(5). In particular make sure to read the PATTERNS section of ssh_config(5).
For a group this means your Match block would begin like this:
Match group proxy-only
You can Match the following criteria: User, Group, Host, LocalAddress, LocalPort and Address. To match several criteria simply comma-separate the criteria-pattern pairs (group proxy-only above).
Inside such a block, which is traditionally indented accordingly for brevity (but needn't to), you can then declare the settings you want to apply for the user group without having to edit every single authorized_keys file for members of that group.
The no-pty setting from authorized_keys would be mirrored by a PermitTTY no setting and command="/sbin/nologin" would become ForceCommand /sbin/nologin.
Additionally you can also set more settings to satisfy an admin's paranoia, such as chroot-ing the user into his home folder and would end up with something like this:
Match group proxy-only
PermitTTY no
ForceCommand /sbin/nologin
ChrootDirectory %h
# Optionally enable these by un-commenting the needed line
# AllowTcpForwarding no
# GatewayPorts yes
# KbdInteractiveAuthentication no
# PasswordAuthentication no
# PubkeyAuthentication yes
# PermitRootLogin no
(check yourself whether you need or want the commented out lines and uncomment as needed)
The %h is a token that is substituted by the user's home directory (%u would yield the user name and %% a percent sign). I've found ChrootDirectory particularly useful to confine my sftp-only users:
Match group sftp-only
X11Forwarding no
AllowTcpForwarding no
ChrootDirectory %h
ForceCommand internal-sftp
PasswordAuthentication no
Please mind that only certain directives can be used in a Match block. Consult the man page sshd_config(5) for details (search for Match).
authorized_keys
NB: the part below this remark was my original answer. Meanwhile - but it also depends on the features of your exact sshd version - I would go for the method described above in most cases.
Yes you can, as fine-grained as you can assign public keys. In addition to nologin as recommended by ajdecon, I would suggest setting the following in front of the key entry in authorized_keys:
no-pty ssh-rsa ...
The no pty tells the server-side that no pseudo-terminal should be allocated for that key.
You can also force the execution of something like nologin for a particular key by prepending this:
command="/sbin/nologin",no-pty ssh-rsa ...
It's unclear what you mean by "double tunnel". It sounds like you're just talking about using SSH port-forwarding to allow the contractor to access the AS/400 via the "InsideLinuxServer" computer.
Make sure SSH is allowed from the Internet to the "InsideLinuxServer"
Create a credential on the "InsideLinuxServer" for the contractor to use. (You might want to get more in-depth and prevent shell access on that Linux machine for the contractor, turn off SFTP, etc.)
Have the contractor configure their SSH client to tunnel some local port to port 23 of the AS/400. In "PuTTY" this is done in the Tunnels node of the SSH node of the Connection node of the settings. They'd add a source port as some unused port on their machine (say "2300"), a destination of the IP address or name of the AS/400 with a ":23" appended after it and add it to the forwarded ports list.
After the contractor connects to the "InsideLinuxServer" machine w/ SSH they would be able to TELNET to their own port 2300 (in the case of my example). PuTTY would answer the TCP connection attempt and forward the traffic to the "InsideLinuxServer" which would, in turn, make a TCP connection to port 23 on the AS/400 and forward the traffic.
As far as making it "scalable", for that number of clients I'd just write instructions for them on how to configure PuTTY and send them on their way.
To make things more secure you may want to think about using public key authentication on the SSH server in lieu of passwords. It's a little more setup labor up front but it's safer than using passwords.
Best Answer
Seems like you want the -N flag.