Differences between version 9 and predecessor to the previous major change of SSHErrors.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 9 | Last edited on Friday, August 20, 2004 5:43:55 am | by AristotlePagaltzis | Revert |
| Older page: | version 8 | Last edited on Thursday, August 19, 2004 10:17:50 pm | by StefanKuklik | Revert |
@@ -7,9 +7,9 @@
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 +45,10 @@
!!! <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:
-
-
-
-
-
-
-
-After restarting
the ssh-
server you may logon using clients with [SSH] protocol 1 as well
.
+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
.
----
Part of CategorySecurity and CategoryNetworking
