Differences between version 20 and predecessor to the previous major change of SSHErrors.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 20 | Last edited on Saturday, June 3, 2006 7:49:30 am | by AristotlePagaltzis | Revert |
| Older page: | version 18 | Last edited on Friday, October 7, 2005 3:42:25 am | by AshleyWard | Revert |
@@ -3,29 +3,30 @@
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.
!!! <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>
+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]. This normally means a [TCP] connection was established, but closed before anything could happen.
-when trying
to a machine connect via SSH
.
-This 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 the following:''''
+
+ <verbatim>
+ sshd:
.nz
+ </verbatim>
+
+in <tt>/etc/hosts.allow</tt>, which restricts incoming [SSH] connections to [IP] addresses that have
a reverse
[DNS
] entry that ends in <tt>.nz</tt>. You can fix it by either getting your [IP] to resolve correctly (both forward and reverse)
, removing the <tt>PARANOID</tt> line in <tt>/etc/hosts
.deny</tt>, or adding
-!!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.
+
+
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.
!!! Commands complain about corruption when piping data via [SSH] / [SCP] errors
@@ -33,51 +34,57 @@
<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.
+Yes, your <tt>.ssh/config</tt> doesn't actually expand out <tt>$HOME</tt>. This is despite the ManPage
ssh_config(5) referring to <tt>$HOME/.ssh/''foo''</tt> for the <tt>~IdentifyFile</tt> section. It will expand out <tt>~~</tt> correctly, however
, 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.
+!!!
<tt>Could not reverse map address
</tt>
-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
.
+sshd(8
) has an option to disallow connections where
the ReverseLookup for the incoming connection’s remote
[IP
] 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(8) 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 won't prompt for passwords
+
+
!!! [
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).
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.
+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 sshd_config(5)
. 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.
+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 <tt>~
~/.ssh</tt>
or else you may have corrupted that file.
-!!! <tt>channel ''n'': open failed: administratively prohibited: open failed</tt>
-Despite this error message, this just means it wasn't able to
open a port forward. Generally this is because the address you have set for port forwarding is wrong, or the port that you are pointing to is incorrect. Check your -L or -R options for accuracy. This is also the message you'll get if your slave SSH server is running port filtering software like "Little Snitch" or have a firewall setup on the slave side.
+!!! <tt>channel <i>n</i>:
open failed: administratively prohibited: open failed</tt>
-This can also be if
the server
you are connecting
to has AllowTcpForwarding
set to no in its sshd_config file
.
+Despite this error message, this just means it wasn't able to open a port forward. Generally this is because
the address you have set for PortForwarding is wrong, or the [Port] that
you are pointing
to is incorrect. Check your <tt>-L</tt> or <tt>-R</tt> options for accuracy. For example this command will bring up the error mentioned above caused by a wrong usage, eg. <tt>ssh -L 9999:__user@__host:22</tt>, where the problem is that you are not allowed to specify a user at that point. [OTOH], this is also the message you'll get if your slave [SSH] server is running port filtering software like "Little Snitch" or
has a FireWall
set up on the slave side
.
-----
+This can also be if the server you are connecting to has <tt>~AllowTcpForwarding no</tt> in its sshd_config(5).
-Part of CategorySecurity, CategoryNetworking,
CategoryErrors
+----
+
Part of CategorySecurity, CategoryNetworking and
CategoryErrors
