Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Sometimes I need to ssh to a new remote server and immediately fix something without ssh trying to find any private keys on my host. It usually stalls at this point:

debug1: Next authentication method: gssapi-with-mic


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/blah' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/blah2' not found

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

Is there a way I can specify for ssh to just do password based authentication immediately?

share|improve this question
4  
Note that the time to stat(2) a missing file only take a millisecond, so you won't notice any speedup. –  Martin Sep 3 '10 at 17:33
add comment

3 Answers

up vote 9 down vote accepted
ssh -o PreferredAuthentications=password,keyboard-interactive,gssapi-with-mic,hostbased,publickey user@host.example.com

This setting can also be put into ~/.ssh/config if you do not want key access for any server that allows password access.

share|improve this answer
add comment

It's trying to find private keys on your computer; the remote computer would have the public key. Remote computers should never have your private key (unless it's a computer under your control).

Looks like you've got GSS Auth turned on, from the command line you can turn it off with something like ssh -o GSSAPIAuthentication=no user@host.example.com.

If that works it would probably be easier to turn off for default connections by adding GSSAPIAuthentication no under the Host * section of your ~/.ssh/config file (or the system wide ssh_config file). If you need it for local servers you can then add a Host *.my_company.com section with it turned back on.

share|improve this answer
add comment

If you connecting to the server with a command like

ssh user@192.168.1.188

then problem you are seeing is most likely caused by the client not being able to resolve the hostname of the server. Once the client can resolve the server's hostname you still get the error messages but without the delay which is caused by the name service timing out.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.