Cache the password if SSH-keys are forbidden

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 [email protected] -fNMS ~/.ssh/bar.socket
   [email protected]'s password:
   

   You're back to the local shell.

2. Start a new connection through the master:

   $ ssh [email protected] -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 [email protected]
   [email protected]'s password:
   [foo@bar:~]$ exit
   

3. The second doesn't:

   $ ssh [email protected]
   [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.

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.

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