Differences between version 14 and previous revision of SSHErrors.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
Newer page: | version 14 | Last edited on Tuesday, May 24, 2005 11:29:35 am | by JohnMcPherson | Revert |
Older page: | version 13 | Last edited on Tuesday, May 24, 2005 10:55:37 am | by IanMcDonald | Revert |
@@ -1,12 +1,32 @@
!!! 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.
+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 (
and its contents)
must not be group or world writeable. Additionally, your private key (
<tt>.ssh/id
_dsa
</tt>)
must not be readable or writable by anyone other than you
. 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
+!!! <tt>Connection closed by remote host</tt> Error Message
+There are several reasons why you might get a message like
+
+<tt>ssh_exchange_identification: Connection closed by remote host</tt>
+
+when trying to a machine connect via SSH.
+If you are getting an error message along the lines of it normally means a [TCP] connection was established, but closed before anything could happen.
+
+
!!TCPWrappers
+One cause for this is that [TCP] Wrappers was configured at the server end to drop connections for some reason - perhaps paranoid lookups. Another example is a line such as
+<verbatim>
+sshd: .nz
+</verbatim>
+in /etc/hosts.allow, which restricts incoming SSH connections to [IP] addresses that have a reverse [DNS] entry that ends in ".nz".
+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
+<verbatim>
+sshd sshd1 sshd2 : ALL : ALLOW
+</verbatim>
+to <tt>/etc/hosts.allow</tt>.
+
+!! Server pseudo-terminal problems
+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. If SSH can't allocate a terminal, it returns (by the looks of things), preventing you from getting a shell.
-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:
@@ -34,11 +54,8 @@
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.