As an alternative, you could prefix the key in the authorized_keys file of firstname.lastname@example.org with a "from=ip.address.of.gateway.org", effectively making the key work only if the connection comes from the gateway system.
See "man sshd" for more details.
Another possibility would be to have the private key on a separate account on
gateway.org that has logins disabled. Let's call that account
secretkeeper for example. Then you could give the sysadmins limited sudo access to that account like this (
sudoers file syntax):
User_Alias ADMINUSERS=sysadmin1, sysadmin2, sysadmin3 #...etc.
ADMINUSERS ALL=(secretkeeper) /usr/bin/ssh secretremote
~secretkeeper/.ssh/config specify as much of the connection parameters as possible, for user-friendliness:
sysadmin1 and others will be able to run
sudo -u secretkeeper ssh secretremote, but no other commands via
sudo (unless there are other
secretremote is just a keyword that can be anything, as long as it is the same in both the
Since the command specified in the
sudoers file includes parameters, only that specific command will be accepted. Then
sudo will run the command (and only that command) as the
secretkeeper user, which can read the SSH configuration file and the private key, and then establish the connection. And since the
sudo session is only running that one
ssh command, once SSH is disconnected, the
sudo session will end; there will be no interactive shell running as the
Of course, all this requires that your sysadmin users must not have root access to the