I have a server which I have to access frequently via ssh, because I compute on it. Now, the computing center explicitly forbids SSH-keys because they are "insecure". They feel that typing my password, on a keyboard, everytime, possible in front of other humans, is a much safer way to login.

Now; I cannot change their minds (I tried).

Is there a way to at least temporarily store SSH passwords, the way GIT can store passwords in a cache for some defined time?

  • 55
    the computing center explicitly forbids SSH-keys because they are "insecure" - my opinion on the matter? Find a new server host, because yours is obviously inept. – Matt Clark Oct 1 '18 at 15:28
  • 18
    @Matt: "computing center" sounds more like an academic grid system, which doesn't have nearly as much competition I guess – user1686 Oct 1 '18 at 16:18
  • 27
    They are wrong. They have probably been forgetting to disable ssh keys when they expire accounts, so they decided that ssh keys are the problem. – Joshua Oct 1 '18 at 16:20
  • 10
    grawity is right. it's a national supercomputer so I'm stuck with it. for what it's worth, the machine is nice. Joshua is probably right as well, but, well, that's the kind of right not good for anything – user2667180 Oct 1 '18 at 18:55
  • 7
    @TheHansinator If there is a keylogger installed you have already been compromised to the point where it no longer matters whether you are protecting your ssh connections. But there are other advantages of publickey authentication. If you disable password authentication on the server, you prevent all of those attackers trying to guess passwords. And if an attacker attempt a mitm attack against a client which has not previously stored the public key of the server, you are much better protected with publickey than if you were using password authentication. – kasperd Oct 2 '18 at 8:04

Connection reuse

SSHv2 allows the same authenticated connection to establish multiple 'channels' – interactive shell, batch command, SFTP, along with the secondary ones such as agent-forwarding or TCP-forwarding. Your server probably supports connection multiplexing by default. (If your admins complain, it's not caching your password anywhere – it's caching the whole connection.)

With OpenSSH you have ControlMaster and ControlPath options (-M and -S) to make use of this:

  1. Start a 'master' SSH connection using -M. (Since you don't have a ControlPath in your config yet, you need to specify it in command line using -S. It needs to live long, so I add the -fN options to drop to background; they're technically optional otherwise.)

    $ ssh foo@bar.example.com -fNMS ~/.ssh/bar.socket
    foo@bar.example.com's password:

    You're back to the local shell.

  2. Start a new connection through the master:

    $ ssh foo@bar.example.com -S ~/.ssh/bar.socket

    You're in.

  3. To make this useful for Git/rsync/SFTP, you need to set up ControlPath in your configuration, because you won't be able to specify -S all the time:

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p

You can automate this – recent OpenSSH versions also have ControlPersist which automatically establishes a master connection in background if there isn't one yet. This allows you to skip step 1 and just use ssh as you normally would.

  1. Configuration in ~/.ssh/config:

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p
        ControlMaster auto
        ControlPersist 15m
  2. First connection asks for password:

    $ ssh foo@bar.example.com
    foo@bar.example.com's password:
    [foo@bar:~]$ exit
  3. The second doesn't:

    $ ssh foo@bar.example.com
    [foo@bar:~]$ yay

To control the multiplex master (stop it or configure TCP forwardings), use the -O option.

A similar method is supported by recent PuTTY versions.

| improve this answer | |
  • 2
    thank you very much for this nice answer. google was not useful on this problem, as it always turned to ssh-keys and I did not know the right keywords. helped me a lot! – user2667180 Oct 1 '18 at 12:39
  • 1
    It should go without saying, but if you use this configuration is is imperative that you make sure your account is secured and that that your .ssh folder is correctly locked down as anyone with access to the channel files on that machine can piggyback off of your connection, and access the server as you. – shellster Oct 1 '18 at 20:43
  • 3
    @shellster: You mean "anyone with the same UID", just as is the case with ssh-agent already. Even if you deliberately open up the socket file's permissions (which are 0600 by default), other users will just get "multiplex uid mismatch" out of it. – user1686 Oct 1 '18 at 22:04
  • 4
    @shellster Someone with root could install a keylogger and steal your password to the remote system anyway, or do any number of nefarious things. If we're worried about local root, this is no less secure than saving an SSH private key. – amalloy Oct 3 '18 at 2:03
  • 2
    I don't consider local root a threat because if it ever becomes a threat, you're toast no matter what. (As with government-grade spying.) Frankly a local root could just replace your ssh client and ssh-agent with whatever they want. Store all passwords and private keys in /root/.secret? Sure. – user1686 Oct 3 '18 at 4:35

Use sshpass

sshpass (github, man page) is a tool that automatically feeds the password to ssh. The secure way to use it is this:

% echo 'correct horse battery staple' > ~/.ssh/compute_password
% chmod go-rw ~/.ssh/compute_password

% sshpass -f ~/.ssh/compute_password ssh foo@host

This will read the password from ~/.ssh/compute_password, much like a private key file without passphrase. You could put the sshpass command in a small shell script or a shell alias to avoid typing that full command. Sadly, I haven't found a way to do this from ~/.ssh/config.

(It is also possible to specify the password directly on the command line to sshpass, but this should be avoided, as it leaks the password to anyone who can do ps)

Comparison to other methods

This approach is of course less secure than properly set up public key authentication, but you probably know that already.

It is also less secure than @grawity's answer about connection re-use, but it has the advantage of not having to enter the password interactively at all.

You could consider @grawity's answer an alternative to pubkey auth with a passphrase and private key caching (i.e. ssh-agent). Then my answer would be an alternative to pubkey auth without a passphrase on the private key file.

| improve this answer | |
  • 3
    If the computing centre's policy was written based on "but keypairs are stored on disk where someone could steal them!", then it looks like that policy is going to rather backfire. – user1686 Oct 2 '18 at 10:47
  • 6
    @grawity Well, bad policies lead to even worse work-arounds ¯\_(ツ)_/¯ – marcelm Oct 2 '18 at 21:58
  • 1
    If you generate your password as a sufficiently long stream of random characters (say head -c 16 /dev/urandom | base64 for 128 bits) and don't use it on other systems, it's security-wise similar to a key. As hard to brute force, and as simple to use from the file if not encrypted. This goes for the bad guy too, if they get the file. The only difference is that the password is sent to the server as-is, while keys have better maths to prove that you own the correct private key without revealing it, and usability-wise, it's harder to encrypt the file containing the password (no standard tools). – ilkkachu Oct 3 '18 at 10:24

Use password manager.

Some password managers (ex. KeePassXC) have the 'auto-type' feature. You store the password on the password manager, unlock the database when you run the manager and every time ssh prompts you for your password you press a key combination which makes the password manager write your long password to the console.

No need to copy, remember anything (except for the password to unlock the database) and you can have a strong password without mashing those 30 characters every time you try to login.

You can pick your favourite from this list: https://en.wikipedia.org/wiki/List_of_password_managers

| improve this answer | |
  • 3
    I'm not sure if the auto-type feature works well with terminal-based programs. The detection will be looking for a specific window title, and the autotyping itself best not have the fancy "anti-keylogging" features that KeePass2 had... – user1686 Oct 2 '18 at 10:28
  • 1
    @grawity gnome-terminal changes its title to ssh somehost when ssh asks me for password so you can match the title window against this with no problems. I don't know anything about 'anti-keylogging' features - I'm using KeePassXC in terminal on daily basis and the worst I had to deal with is choosing the appropriate account from the list. – styrofoam fly Oct 2 '18 at 14:37
  • 2
    @grawity The anti-keylogging features need to be enabled on a per-entry basis anyway (exactly for the reason that many programs do not support paste). – Bob Oct 3 '18 at 2:23

Another alternative is to use a GUI ssh client. On Windows the obvious choice would be PuTTY. There's also a Linux version of PuTTY, notably most Debian based distros like Ubuntu normally include PuTTY in their repo.

Another really good client is Termius. It supports not just Windows and Linux but also OSX, iOS and Android. Although it was primarily designed for phones the desktop version is actually quite good.

If I'm not mistaken, the venerable Hyperterminal on Windows also has/had an ssh client built in but I haven't used windows in a very long time so I'm not entirely certain.

All GUI clients include the ability to save connection settings which includes your username and password.

| improve this answer | |
  • 2
    "GUI-based" doesn't automatically imply it'll allow storing your password, something which PuTTY explicitly refuses to do. The version of HyperTerminal that was bundled with Windows was Telnet-only, focused more on serial links. Maybe you're thinking of CKermit for Windows which does have SSH support, but its cipher support is so outdated it won't easily connect to many current servers. – user1686 Oct 3 '18 at 4:06

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.