2011-11-02 by sourpoi in misc, tagged: ssh

Tips are running lists of the latest hints that helped.

Too many authentication failures

Too many authentication failures in your server logs is probably the result of too many attempts to use inappropriate SSH keys; the number of invalid credentials provided to a given server overran the server's MaxAuthTries.

On the client there are a couple of ways to address this:

  • Configure which keys are used for which host in ~/.ssh/config:

    Host *
      IdentitiesOnly yes
    
    Host test
      hostname test.example.com
      identifyfile /home/USER/.ssh/id_test
    
  • Disable GSSAPIAuthentication in ~/.ssh/config if you're not in a Kerberos environment:

    Host *
      GSSAPIAuthentication no
    

You may try debugging connectivity by disabling SSH agent and keys:

  • Unset the SSH_AUTH_SOCK for the session in question to disable access to the SSH agent.
  • Disable public keys in the command itself: ssh -o PubkeyAuthentication=no

SOCKSv5 tunneling issues

Firefox (FoxyProxy) encountered a problem with SSH SOCKS proxying and remote DNS (in about:config: network.proxy.socks_remote_dns true). On the remote host, name resolution was failing with messages like this in /var/log/secure:

Jan 22 21:27:49 hostname sshd[11558]: error: connect_to www.example.com: \
unknown host (Temporary failure in name resolution)

The client gave messages like this:

channel 1: open failed: administratively prohibited: open failed

A post at http://forum.nginx.org/read.php?30,56847,56929 suggested that SSH keys might be behind this. After disabling my keys, establishing the tunnel using a standard password worked fine, even with DNS forwarding.

Could not get shadow information

Short version: check that sshd_config sets UsePAM yes.

If the issue is not related to your keys, turn up logging in sshd_config to LogLevel DEBUG3 to see if sshd complains that it Could not get shadow information for some user. This means that /etc/shadow is not being read.

On a working system we're led to believe that standard file permissions (no read permissions for owner, group, or users) aren't the problem:

# ls -lZ /etc/shadow
----------. root root system_u:object_r:shadow_t:s0    /etc/shadow

As a perfectly legal knee-jerk reaction, disable SELinux and the errors will probably disappear ..despite nothing in the audit.log about denials (ausearch -m avc). The bold approach is to assume we're dealing with a dontaudit rule pertaining to a shadow_t target:

sesearch -d --dontaudit -t shadow_t | grep ssh

dontaudit sshd_t shadow_t : file { ioctl read getattr lock open } ;

Voila. Denials will not be logged when a sshd_t source attempts to read a shadow_t file.

I wasn't inclined to follow the sshd process through all the SELinux rules and transitions. I re-enabled SELinux and assumed there must be a good reason for the denial.

By luck I noticed that rpm -ql openssh-server listed /etc/pam.d/sshd. On Red Hat, sshd should ask PAM for authentication and not read /etc/shadow directly. Double-checking sshd_config, UsePAM was not set. Bingo.

Key fingerprints

The hex fingerprint provides the easiest way to visually compare two SSH keys.

Ideally, after generating a server's SSH key, the fingerprint should be announced prior to a client's connection. For a standard protocol 2 RSA key on Red Hat:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key

2048 28:54:bb:c4:bc:20:6a:85:25:c7:c5:31:96:44:a7:e8   (RSA)

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

2048 28:54:bb:c4:bc:20:6a:85:25:c7:c5:31:96:44:a7:e8   (RSA)

Check a host's key without committing it to known_hosts:

ssh-keyscan $host > hostkey
ssh-keygen -lf hostkey

Check an existing key in known_hosts (this requires $host in known_hosts and does not translate Host <-> HostName aliases in ssh_config):

ssh-keygen -lF $host

EOF during negotiation

An EOF during negotiation error after an scp or sftp attempt might be the result of a missing or invalid Subsystem sftp configuration in the server's sshd_config. Double check the path.

If you cannot reconfigure the SSH server, use one of the ssh-only methods of file copying at http://ultra.ap.krakow.pl/~bar/DOC/ssh_backup.html:

ssh target_address cat <localfile ">" remotefile

Slow connection

A slow connection could be due to many authentication attempts (see below), but most likely the server is double-checking the validity of a client's IP against DNS. Disable this on the server (sshd_config) with:

UseDNS no

GSSAPIAuthentication can also add to the login time. If you don't need it (if you're not using Kerberos), disable it in either or both of ~/.ssh/config and sshd_config:

Host *
  GSSAPIAuthentication no

SFTP: Received message too long

See http://www.snailbook.com/faq/sftp-corruption.auto.html. The quick answer is that your login shell is probably printing something to stdout - the result of an echo or maybe even invisible color codes. The output is interfering with the underlying protocol. For fun, you can take the integer in the error message:

Received message too long 1397245260

..and translate it into hex to see the start of the offending character sequence.

Pushing public keys to hosts

Before you can use your SSH keys, they need to be added to the remote computer. Either ask an administrator to do this or push your public key using standard password-based authentication in one of two ways:

ssh-copy-id -i ~/.ssh/id_dsa.pub user@host

cat ~/.ssh/id_dsa.pub | ssh user@host "cat - >> ~/.ssh/authorized_keys"

ssh-copy-id doesn't seem to support a port option, so if you're using a non-standard port (something other than 22), use the second command and specify a port with ssh -p PORT.

Failed to determine Kerberos principal name

Kerberos errors (in general) often come down to timing mismatches between the client and host. On MacOSX check file sharing access in the "Sharing" system configuration.

Comments