We have a topsecret@remote.org SSH account that can be accessed with SSH key pair ts_key.pub/ts_key.priv from our gateway server (gateway.org). We have many sysadmins that need to access that account. Each of them has its own SSH account on gateway.org, like sysadmin1@gateway.org.

Is there a way to keep ts_key.pub/ts_key.priv on gateway.org and enable sysadmins to use it, but without exposing it to the sysadmins? So if one of them leaves his job, and his account on gateway.org is closed, then he will not be able to use ts_key.pub/ts_key.priv anymore.

Update: I was suggested (by nice people on IRC/#OpenSSH) to encrypt the private key with a passphrase and then to use ssh-agent/ssh-add. However I didn't figured out the details...

  • 1
    "if one of them leaves his job" you should assign new credentials – Fabian Apr 29 '18 at 12:50
  • @Fabian, there is no reason to change ts_key.pub/ts_key.priv if the sysadmin that left the job never saw this key pair (even though he used it all the time). Otherwise it is not manageable. That is the point of the question. – user1876484 Apr 29 '18 at 13:59
  • Would that be an option for you - to put personal admins public keys on remote.org and allow gateway to forward ssh agent? That will not require shared keypair at all. – Tagwint Apr 29 '18 at 14:03
  • 1
    @Tagwint, for certain reasons, sysadmin account/keys management should be done on gateway server. Thank you! – user1876484 Apr 29 '18 at 14:30
  • @Debian_yadav Please don't use code formatting for random words. Code formatting is for code. – Gilles 'SO- stop being evil' Apr 29 '18 at 14:55

As an alternative, you could prefix the key in the authorized_keys file of topsecret@remote.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

Have ~secretkeeper/.ssh/config specify as much of the connection parameters as possible, for user-friendliness:

Host secretremote
    User topsecret
    HostName remote.org
    EscapeChar none
    IdentityFile /some/where/ts_key.priv

Now your sysadmin1 and others will be able to run sudo -u secretkeeper ssh secretremote, but no other commands via sudo (unless there are other sudoers definitions). secretremote is just a keyword that can be anything, as long as it is the same in both the sudoers and ~secretkeeper/.ssh/config files.

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 secretkeeper user.

Of course, all this requires that your sysadmin users must not have root access to the gateway.org system.

  • It's a good point, and I'll most probably do it as additional measure, but I prefer to make this "topsecret" master key usable but not accessible for sysadmins... Thank you! – user1876484 Apr 29 '18 at 14:29
  • @user1876484 If your "sysadmins" have root access to the box, there's nothing you can do if that key also lives on the box. You will need to redesign the solution for whatever it is you're trying to accomplish. – Patrick Apr 29 '18 at 16:25
  • I added another solution, now that I'm no longer phone-posting. – telcoM Apr 29 '18 at 17:38
  • 1
    @Patrick, no sysadmins do not have root access to the box, I also was told to encrypt the key and to use ssh-agent/ssh-add - but I didn't figure yet how... – user1876484 Apr 29 '18 at 17:54
  • @telcoM, after several days of thinking I came to the conclusion that your approach suits my case better than ssh-agent/ssh-add as my sysadmins really do not require root access. Actually it would be perfect if you could even further tighten the security in your answer and disable for the sysadmins all other commands, even those that do not require sudo as this server is supposed to be a gateway only. – user1876484 May 3 '18 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.