Consider following scenario:

I am logged on serverA as a user 'common'. The key thing about common user is that a bunch of people have access to it - it is unrestricted and unsecure by design.

Let's say, I periodically need to login from this user/server to serverB as user secure - i.e. I need to scp files owned by secure@serverB.

While I have full access and control over secure user, I certainly do not want to add common's public key to trusted keys for secure user - I do not want anyone who can login as common to be able to login as secure as well.

I also do not want to type in secure's password 5 times per hour. Ideally, I'd like to type it once, have some agent or so magically remember it - but only for this login session - and than use it anytime I connect from this session until the timeout expires. Not unlike kinit, actually.

Is there anything out there which could achieve this goal?

2 Answers 2


It's not as easy if You have shared user on intermediate server and that user has shell access as almost everything there is by default accessible by each other session.
There are ways in modern kernels, of course.
Eigther there could be a tool that utilizes session (process/thread) keyrings to store the private data in kernel or the system can be probably be made safe enough to disallow the different processes of same user to access each other so a program could held the authentication information also in normal userspace memory protected from other sessions. Anyway both had to identify requests to do the authetication based on some PID/SID information which will work for basic usage. At the end You need a daemon that does the session setup for You or deliver the stored passwords to Your process so that You can use it with sshpass tool or such.

Another approach is to utilize namespaces and mount a private tmpfs or tmpdir (while tmpfs is better protected or at least less easy accessible from root users than tmpdir).

You could eigther use sshd on a separate port with a wrapper that sets up the namespace environment for that user, or most easily on a modern system at least You can use pam and pam_namespace.so to set up a private user tmpdir or tmpfs. There You could store eigther Your passworrd in cleartext to be used by sshpass or such or even better could put the socket for ssh-agent in that directory and load Your personal private key into that agent while ensuring the access to agent is protected from access by other sessions of same user. If You have a private key with stong password You can also store it on the machine. Otherwise You had to transfer it. You could also make the whole /tmp directory such a private dir (possibly with some subdirs shared) and utilize SSH agent forwarding in quite a secure manner (You can not really protect it to be abused by root user but at least if You use tmpfs it is dificult for root and not possible for normal user to use the Auth-Sock).

Anyway the You need to be able to configure the server sufficently or it needs to be configured sufficently - at least that far that the processes of the users cannot attach to each other.


You're probably looking for ssh-agent, which comes with OpenSSH. Use the -t option to set a timeout.

  • From what I know about it, I do not - as per my knowledge ssh-agent remembers passphrase for password-protected key files. My case doesn't allow me to use ssh key files. If I am mistaken, can you please explain exactly how I'd use ssh-agent in this scenario?
    – SergeyA
    Nov 5, 2019 at 22:43
  • Oh, I misunderstood that you wanted to log in from the common account to the secure account. This isn't secure to begin with, as other people with access to the common account could try to, say, add a different ssh executable to the path that logs passwords or whatever. Any reason why you can't log into the secure account directly and scp files in the other direction?
    – jjlin
    Nov 5, 2019 at 23:07
  • It is as secure as it gets. As I explain in my use case, I do not want to create any permanent files which would be accessible to common login. I want a way to login without password in this particular login session, again, similar to the way kinit works.
    – SergeyA
    Nov 6, 2019 at 1:28
  • Well, if that's really how you want to do it, then you would create an SSH key protected with a password that you keep secret from other users. Then you ssh-add that to ssh-agent. In your shell, your ssh calls will use the value of SSH_AUTH_SOCK to communicate with ssh-agent. If other common users know how to set their SSH_AUTH_SOCK to the right value, then they can use your agent too, similar to knowing the right value for KRB5CCNAME.
    – jjlin
    Nov 6, 2019 at 1:45
  • BTW, in case your serverB is in fact only network-accessible via serverA, there are various ways to use serverA as a "jump host". ProxyJump provides direct support in newer versions.
    – jjlin
    Nov 6, 2019 at 1:54

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.