Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
SSHErrors
Edit
PageHistory
Diff
Info
LikePages
!!! 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 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 <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 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... !!! <tt>Could not reverse map address</tt> 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 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 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 <tt>~~/.ssh</tt> or else you may have corrupted that file. !!! <tt>channel <i>n</i>: 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 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). Can also occur if you've used a hostname in your tunnel specification, when the remote machine can't resolve that hostname. <tt>ssh remotehost -L 5900:titanium:5900 -g -C</tt> when <tt> [root@remotehost ~]# host titanium Host titanium not found: 3(NXDOMAIN) </tt> ---- Part of CategorySecurity, CategoryNetworking and CategoryErrors
3 pages link to
SSHErrors
:
SSHNotes
ApplicationErrorMessages
SSH
