Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
SSHErrors
Edit
PageHistory
Diff
Info
LikePages
You are viewing an old revision of this page.
View the current version
.
!!! 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 (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> 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 <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. !!! 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: <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. !!! <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. 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 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. !!! 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. !!! <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. This can also be if the server you are connecting to has AllowTcpForwarding set to no in its sshd_config file. ---- Part of CategorySecurity, CategoryNetworking, CategoryErrors
3 pages link to
SSHErrors
:
SSHNotes
ApplicationErrorMessages
SSH