Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
SSHErrors
Edit
PageHistory
Diff
Info
LikePages
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 <tt>.ssh</tt> directory (and its parents) on that machine. The <tt>.ssh</tt> directory must have permissions 700 and the parent directory must not be group or world writeable. Additionally, your <tt>authorized_keys2</tt> file must have permissions 700. If this is the problem you will find <tt>sshd: Authentication refused: bad ownership or modes for directory</tt> in your <tt>auth.log</tt> when you try to log in. !!! TCPWrappers If you are getting an error message along the lines of <tt>ssh_exchange_identification: Connection closed by remote host</tt> 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 <tt>/etc/hosts.deny</tt>, or adding <tt>sshd sshd1 sshd2 : ALL : ALLOW</tt> to <tt>/etc/hosts.allow</tt>. !!! 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 <tt>.profile</tt> (and/or <tt>.bash_profile</tt>, <tt>.bashrc</tt> 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 <tt>$TERM</tt> is set to <tt>dumb</tt>. Putting something along these lines at the top of the script(s) will : <verbatim> [ "$TERM" = 'dumb' ] && return </verbatim> !!! Config file not expanding <tt>$HOME</tt> out Yes, your <tt>.ssh/config</tt> doesn't actually expand out <tt>$HOME</tt>. This is despite the man page ssh_config(5) referring to <tt>$HOME/.ssh/''foo''</tt> for the <tt>~IdentifyFile</tt> section. It will expand out <tt> ~~ </tt> correctly, so you can use <tt>~~/.ssh/</tt> instead. !!! <tt>no matching comp found: client zlib server none</tt> You tried to use compression but the ssh server refused. This might be because you had the <tt>-C</tt> option on the command line, or you have <tt>Compression</tt> in your <tt>~/.ssh_options</tt> 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 <tt>~UsePrivilegeSeparation no</tt> and <tt>PAMAuthenticationViaKbdInt yes</tt>, 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 <tt>~VerifyReverseMapping</tt>, but other documentation points to there being a <tt>~RequireReverseMapping</tt> 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 <tt>ssh_exchange_identification: Connection closed by remote host</tt>, ensure that your [PTY]s are correctly installed and configured. In my case, this involved manually remounting <tt>/dev/pts</tt> in order to get it working. Another symptom of this problem is screen(1) reporting that it cannot find any [PTY]s. !!! SSH won't prompt for passwords If [SSH]ing to a machine seems to avoid prompting you for passwords, check the permissions on <tt>/dev/tty</tt>. 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. !!! <tt>Disconnecting: bad packet length 1349676916.</tt> 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
3 pages link to
SSHErrors
:
SSHNotes
ApplicationErrorMessages
SSH