Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
share|improve this question
Does the server have a /etc/krb5.keytab? GSSAPI (Kerberos) can be simple to set up client-side; I'd have to ask for the server's hostname, though. (Also: keyboard-interactive is very similar to password, except not limited to one "Password:" prompt.) – grawity May 8 '12 at 19:31
@grawity No /etc/krb5.keytab, but it does have /etc/krb5/krb5.keytab. I don't have access to the contents. The server name is (I don't think there's any harm in giving that name out) if it helps you explain the procedure. – David Z May 8 '12 at 19:40
Aah, the old PSU passdisk. Such pleasant memories. I was quite happy with password auth. Why haven't you asked the campus computing folk (was CAC when I went there) instead of reaching out to the 'net? I mean, c'mon, they have a Debian mirror. They're not all clueless Windows-only admins. – Broam May 8 '12 at 19:43
@Broam I can't imagine that I'd be the first one to ask, so presumably they have some reason for keeping it that way... I suppose it wouldn't hurt to try, though. – David Z May 8 '12 at 19:44
up vote 3 down vote accepted

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.

share|improve this answer
Heinously insecure, but have an upvote for being the simplest and most direct answer. – Zac B May 9 '12 at 13:50
good point. it is better that all these are done behind a firewall and in a private network. – johnshen64 May 9 '12 at 15:45

From information gathered so far, the server supports Kerberos 5 (GSSAPI) authentication and is on the 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 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.)


    If no errors are displayed, the login was successful. klist should show a "krbtgt/" 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] =
  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
share|improve this answer
This seems like it should be pretty close to ideal for me, but it doesn't seem to work - I was able to login with Kerberos successfully (no error messages), but I still get prompted for a password. Error messages from ssh -vv are similar to the trace I posted except I get debug1: Unspecified GSS failure. Minor code may provide more information\n Server not found in Kerberos database instead of the thing about the credential cache file not being found. – David Z May 8 '12 at 20:59
Ah, it seems that the "clueless Windows-only admins" set up the keytab for host/, but its real name should have been host/ You can get around this by adding "" to your /etc/hosts, but it's sort of ugly -- would be much nicer if the admins fixed the server... – grawity May 8 '12 at 21:11
Yeah, it would... I'll ask them about it, but for now hopefully your fix should settle things. I'll try it tomorrow. – David Z May 8 '12 at 22:30
@DavidZaslavsky: Might be useful to mention to them that MIT Krb5 v1.10 supports multiple host principals (i.e. both host/ and host/ in a single keytab. (Previous versions only used the first one.) – grawity May 8 '12 at 22:34
Sorry I forgot to come back and provide feedback on this. After modifying /etc/hosts as suggested I get debug1: Unspecified GSS failure. Minor code may provide more information Generic error (see e-text). Nothing else in the output is relevant to the error. – David Z Jun 18 '12 at 22:02

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.

share|improve this answer
The master connection would reset when I shut the client down, though. So this isn't an ideal solution, but it would be a slight improvement over my current situation. – David Z May 8 '12 at 19:41
Use screen to protect shells from terminating on connection break or hangup. – LawrenceC May 8 '12 at 20:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .