Differences between version 12 and predecessor to the previous major change of SSHErrors.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 12 | Last edited on Friday, December 3, 2004 10:24:33 pm | by JohnMcPherson | Revert |
| Older page: | version 8 | Last edited on Thursday, August 19, 2004 10:17:50 pm | by StefanKuklik | Revert |
@@ -1,15 +1,16 @@
!!! 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 :
+[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>
@@ -45,18 +46,11 @@
!!! <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).
-To
solve this problem, you may
either install
a ssh client which supports
[SSH] protocol 2 on the source machine, or change
the configuration of the ssh
server on the destination machine.
+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
.
-To
do the the latter
, look for a file named sshd_config, usually
in /etc/ssh. Change
the line:
+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.
-Protocol 2
+----
-to
-
-Protocol 2,1
-
-After restarting the ssh-server you may logon using clients with [SSH] protocol 1 as well.
-
-----
-and
CategoryNetworking
+Part of CategorySecurity,
CategoryNetworking, CategoryErrors
