How do I set up SSH so I don't have to type a password, and without using a public key?

Question

I know there are dozens of questions here about how to connect to an SSH server without typing your password every time, and the answer is always "use a public key." Well, I find myself in the rare circumstance where that is really not an option. For some inexplicable reason, the OpenSSH daemon on the server I'm trying to connect to is configured with

RSAAuthentication no
PubkeyAuthentication no

in /etc/ssh/sshd_config. I don't have any administrative access on the server so I can't change these or any other server configuration options. (I do, of course, have full control over the client configuration: OpenSSH 5.8 on Linux.)

What are my options, and in particular, what is the safest option, to avoid having to type my password every time I want to SSH into this server? I keep my own computers fairly well secured, so let's assume the security risks of storing the password in a file on the client are acceptably low, if that is indeed necessary.

The other authentication methods the server can accept are evidently GSS API (which I know nothing about), keyboard interactive (which I also know nothing about), and password. Here are some relevant configuration options:

#ChallengeResponseAuthentication yes

#KerberosAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

#UsePAM no

and here is a debug (-vv) trace:

debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information

debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Answer 1

In this case, writing (or better recording) an expect script would be one of your options.

Each system is different so there won't be a script, but with autoexpect it is very easy to record a script for this purpose.

Answer 2

From information gathered so far, the server sftp.pass.psu.edu supports Kerberos 5 (GSSAPI) authentication and is on the dce.psu.edu realm.

Kerberos is very common on networks with many servers and workstations; many large educational institutions have it set up. One if its advantages over public-key authentication is that a single kinit automatically provides credentials to all machines in the Kerberos realm, without having to copy the public keys to each. Another is protocol support – the same Kerberos credentials can be used with over 30 protocols (mail, file systems, databases...), not just SSH.

^{(Regarding "clueless Windows-only admins": the dce.psu.edu realm actually appears to be based on Active Directory and hosted by Windows servers.)}

Try following these steps:

1. Log in to Kerberos. (The kinit and klist tools may be in "krb5-user" or similar package, if not already included with the system.)

   kinit your_username@dce.psu.edu
   

   If no errors are displayed, the login was successful. klist should show a "krbtgt/dce.psu.edu@..." item.

2. Now connect to the SSH server, with the -vv options; if authentication succeeds, good.

   If it doesn't, you might have to edit your /etc/krb5.conf file. Under the [domain_realm] section, add the following:

   [domain_realm]
       .psu.edu = dce.psu.edu
   

3. With default Krb5 settings, the ticket obtained in #1 should be valid for 10 hours, and renewable for up to a week. I have no way of verifying the settings, however.

   If you want to keep the password in a file, a simple kinit your_principal < password.txt should work, although it is not completely reliable.

   With ktutil it is possible to make a "keytab" for use instead of the password.

   $ ktutil
   ktutil:  addent -password -p your_principal -k 1 -e aes256-cts-hmac-sha1-96
   Password for your_principal: *********
   ktutil:  wkt keytab_file
   ktutil:  CtrlD
   

   and log in using:

   $ kinit -kt keytab_file your_principal
   

Answer 3

I would consider a mixed solution, where you enter the password just once, and the computer maintains a socket to the remote SSH server. You can follow these steps to setup the ControlMaster for just that reason.