Penguin

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.