| Rev | Author | # | Line |
|---|---|---|---|
| 12 | JohnMcPherson | 1 | !!! Permissions |
| 2 | |||
| 14 | JohnMcPherson | 3 | 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. |
| 12 | JohnMcPherson | 4 | |
| 5 | |||
| 14 | JohnMcPherson | 6 | !!! <tt>Connection closed by remote host</tt> Error Message |
| 7 | |||
| 20 | AristotlePagaltzis | 8 | 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. |
| 14 | JohnMcPherson | 9 | |
| 20 | AristotlePagaltzis | 10 | !! TCPWrappers |
| 11 | |||
| 12 | 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:'''' | ||
| 13 | |||
| 14 | <verbatim> | ||
| 15 | sshd: .nz | ||
| 16 | </verbatim> | ||
| 17 | |||
| 18 | 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 | ||
| 14 | JohnMcPherson | 19 | |
| 20 | <verbatim> | ||
| 21 | sshd sshd1 sshd2 : ALL : ALLOW | ||
| 22 | </verbatim> | ||
| 20 | AristotlePagaltzis | 23 | |
| 14 | JohnMcPherson | 24 | to <tt>/etc/hosts.allow</tt>. |
| 25 | |||
| 26 | !! Server pseudo-terminal problems | ||
| 20 | AristotlePagaltzis | 27 | |
| 28 | 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. | ||
| 12 | JohnMcPherson | 29 | |
| 30 | |||
| 31 | !!! Commands complain about corruption when piping data via [SSH] / [SCP] errors | ||
| 32 | |||
| 33 | [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: | ||
| 34 | |||
| 35 | <verbatim> | ||
| 36 | [ "$TERM" = 'dumb' ] && return | ||
| 37 | </verbatim> | ||
| 20 | AristotlePagaltzis | 38 | |
| 12 | JohnMcPherson | 39 | |
| 40 | !!! Config file not expanding <tt>$HOME</tt> out | ||
| 41 | |||
| 20 | AristotlePagaltzis | 42 | 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. |
| 43 | |||
| 12 | JohnMcPherson | 44 | |
| 45 | !!! <tt>no matching comp found: client zlib server none</tt> | ||
| 46 | |||
| 47 | 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. | ||
| 20 | AristotlePagaltzis | 48 | |
| 12 | JohnMcPherson | 49 | |
| 50 | !!! Privilege Separation | ||
| 51 | |||
| 52 | If you find you are unable to ssh in to a box where auth is [LDAP] via [PAM], you are probably using privelege seperation. | ||
| 53 | |||
| 54 | 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... | ||
| 55 | |||
| 56 | |||
| 20 | AristotlePagaltzis | 57 | !!! <tt>Could not reverse map address</tt> |
| 12 | JohnMcPherson | 58 | |
| 20 | AristotlePagaltzis | 59 | 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. |
| 12 | JohnMcPherson | 60 | |
| 20 | AristotlePagaltzis | 61 | 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. |
| 12 | JohnMcPherson | 62 | |
| 20 | AristotlePagaltzis | 63 | |
| 64 | !!! [SSH] won't prompt for passwords | ||
| 12 | JohnMcPherson | 65 | |
| 66 | 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. | ||
| 20 | AristotlePagaltzis | 67 | |
| 12 | JohnMcPherson | 68 | |
| 69 | !!! <tt>Disconnecting: bad packet length 1349676916.</tt> | ||
| 70 | |||
| 71 | 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). | ||
| 72 | |||
| 73 | 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. | ||
| 74 | |||
| 20 | AristotlePagaltzis | 75 | 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. |
| 76 | |||
| 13 | IanMcDonald | 77 | |
| 78 | !!! Permission denied errors | ||
| 79 | |||
| 20 | AristotlePagaltzis | 80 | 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. |
| 16 | PerryLorier | 81 | |
| 82 | |||
| 20 | AristotlePagaltzis | 83 | !!! <tt>channel <i>n</i>: open failed: administratively prohibited: open failed</tt> |
| 18 | AshleyWard | 84 | |
| 20 | AristotlePagaltzis | 85 | 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. |
| 12 | JohnMcPherson | 86 | |
| 20 | AristotlePagaltzis | 87 | This can also be if the server you are connecting to has <tt>~AllowTcpForwarding no</tt> in its sshd_config(5). |
| 21 | CriggieCriggie | 88 | |
| 89 | Can also occur if you've used a hostname in your tunnel specification, when the remote machine can't resolve that hostname. | ||
| 90 | <tt>ssh remotehost -L 5900:titanium:5900 -g -C</tt> when | ||
| 91 | <tt> [root@remotehost ~]# host titanium | ||
| 92 | Host titanium not found: 3(NXDOMAIN) </tt> | ||
| 93 | |||
| 94 | |||
| 12 | JohnMcPherson | 95 | |
| 20 | AristotlePagaltzis | 96 | ---- |
| 97 | Part of CategorySecurity, CategoryNetworking and CategoryErrors |
lib/blame.php:177: Warning: Invalid argument supplied for foreach() (...repeated 6 times)