Differences between version 14 and predecessor to the previous major change of SSHErrors.
Other diffs: Previous 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 12 | Last edited on Friday, December 3, 2004 10:24:33 pm | by JohnMcPherson | 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.
@@ -49,8 +66,12 @@
You can solve this problem by either installing a [SSH] client which supports protocol version 2 on the source machine (strongly recommended), or by changing the configuration of the [SSH] server on the destination machine. Note that protocol versions 1.x are deprecated because they're vulnerable. You should really upgrade the client instead.
If you cannot do that for whatever reason, you have to permit clients to use a 1.x protocol in sessions with the server by changing the directive <tt>Protocol 2</tt> to <tt>Protocol 2,1</tt> in the server's <tt>/etc/ssh/sshd_config</tt>. Don't forget to restart the daemon.
+
+!!! Permission denied errors
+
+If you get an error similar to <tt>Permission denied (publickey).</tt> you probably have not put your public key into the authorized_keys file in ~/.ssh or else you may have corrupted that file.
----
Part of CategorySecurity, CategoryNetworking, CategoryErrors
