Penguin
Note: You are viewing an old revision of this page. View the current version.

Permissions

If you are having trouble logging in to a remote machine using ssh keys, or other methods you would be wise to check the permissions on your .ssh directory (and its parents) on that machine. The .ssh directory must have permissions 700 and the parent directory must not be group or world writeable. Additionally, your authorized_keys2 file must have permissions 700. If this is the problem you will find sshd: Authentication refused: bad ownership or modes for directory in your auth.log when you try to log in.

TCPWrappers

If you are getting an error message along the lines of ssh_exchange_identification: Connection closed by remote host it normally means the ssh connection was established, but closed before anything could happen. This probably means TCP Wrappers was configured at the server end to drop connections for some reason - perhaps paranoid lookups. You can fix it by either getting your IP to resolve - both forward and reverse - correctly, removing the PARANOID line in /etc/hosts.deny, or adding sshd sshd1 sshd2 : ALL : ALLOW to /etc/hosts.allow.

Commands complain about corruption when piping data via SSH / SCP errors

SSH always launches a login shell on the remote end. Such a shell always source your .profile (and/or .bash_profile, .bashrc etc). Anything printed in the course of its execution (invoking fortune(6) is a common offense) will end up in your data stream and end up throwing a monkey wrench in, say, tar(1)'s or even scp(1)'s gears. You can work around this by checking whether $TERM is set to dumb. Putting something along these lines at the top of the script(s) will :

[ "$TERM" = 'dumb' ] && return

Config file not expanding $HOME out

Yes, your .ssh/config doesn't actually expand out $HOME. This is despite the man page ssh_config(5) referring to $HOME/.ssh/foo for the IdentifyFile section. It will expand out ~ correctly, so you can use ~/.ssh/ instead.

no matching comp found: client zlib server none

You tried to use compression but the ssh server refused. This might be because you had the -C option on the command line, or you have Compression in your /.ssh_options file. This might mean that there are different versions of ssh installed on the two machines, or different versions of libssl. Not trying to use compression will work around this.

Privilege Separation

If you find you are unable to ssh in to a box where auth is LDAP via PAM, you are probably using privelege seperation.

You have two options. Set UsePrivilegeSeparation no and PAMAuthenticationViaKbdInt yes, or use keys only. Keep in mind that using keys will require local home directories, which you may not have if you're using LDAP auth...

Could not reverse map address

sshd has an option to disallow connections where the ReverseLookup for the IP that is connecting does not match the ForwardLookup. In sshd_config(5)? it says the parameter is called VerifyReverseMapping, but other documentation points to there being a RequireReverseMapping as well.

Should sshd complain (and take a long time to let you connect), and the DNS appears sound, restart the service. These results appear to be cached so restarting sshd will solve your problem.

SSH Daemon not responding

If clients do nothing after authenticating or report an error such as ssh_exchange_identification: Connection closed by remote host, ensure that your PTYs are correctly installed and configured. In my case, this involved manually remounting /dev/pts in order to get it working. Another symptom of this problem is screen(1) reporting that it cannot find any PTYs.

SSH won't prompt for passwords

If SSHing to a machine seems to avoid prompting you for passwords, check the permissions on /dev/tty. If the user cannot write to this device, then SSH is unable to turn off local echo when prompting for passwords, so it just silently skips asking for passwords.

Disconnecting: bad packet length 1349676916.

There was a protocol error, normally due to conflicting versions of ssh on the two machines. You might get this on a machine running Slackware version 7 (where OpenSSH-1.2 only supports SSH protocol 1.5) when trying to SSH to a machine running Slackware 8 (with OpenSSH-3.4 and only using SSH protocol 2).


Part of CategorySecurity and CategoryNetworking