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 .ssh directory (and its parents) on that machine. The .ssh directory (and its contents) must not be group or world writeable. Additionally, your private key (.ssh/id_dsa) must not be readable or writable by anyone other than you. If this is the problem you will find sshd: Authentication refused: bad ownership or modes for directory in your auth.log when you try to log in.
There are several reasons why you might get a message like ssh_exchange_identification: Connection closed by remote host when trying to a machine connect via SSH. This normally means a TCP connection was established, but closed before anything could happen.
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:
sshd: .nz
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 correctly (both forward and reverse), removing the PARANOID line in /etc/hosts.deny, or adding
sshd sshd1 sshd2 : ALL : ALLOW
to /etc/hosts.allow.
Ensure that your PTYs are correctly installed and configured. In my case, this involved manually remounting /dev/pts in order to get it working. Another symptom of this problem is screen(1) reporting that it cannot find any PTYs. If SSH can't allocate a terminal, it returns (by the looks of things), preventing you from getting a shell.
SSH always launches a login shell on the remote end. Such a shell always source your .profile (and/or .bash_profile, .bashrc 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 $TERM is set to dumb. Putting something along these lines at the top of the script(s) will:
[ "$TERM" = 'dumb' ] && return
Yes, your .ssh/config doesn't actually expand out $HOME. This is despite the ManPage ssh_config(5) referring to $HOME/.ssh/foo for the IdentifyFile section. It will expand out ~ correctly, however, so you can use ~/.ssh/ instead.
You tried to use compression but the ssh server refused. This might be because you had the -C option on the command line, or you have Compression in your /.ssh_options 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.
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 UsePrivilegeSeparation no and PAMAuthenticationViaKbdInt yes, 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...
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 VerifyReverseMapping, but other documentation points to there being a RequireReverseMapping 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.
If SSHing to a machine seems to avoid prompting you for passwords, check the permissions on /dev/tty. 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.
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 Protocol 2 to Protocol 2,1 in the server's sshd_config(5)?. Don't forget to restart the daemon.
If you get an error similar to Permission denied (publickey). you probably have not put your public key into the authorized_keys file in ~/.ssh or else you may have corrupted that file.
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 -L or -R options for accuracy. For example this command will bring up the error mentioned above caused by a wrong usage, eg. ssh -L 9999:user@host:22, 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 AllowTcpForwarding no 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. ssh remotehost -L 5900:titanium:5900 -g -C when root@remotehost ~?# host titanium Host titanium not found: 3(NXDOMAIN)
Part of CategorySecurity, CategoryNetworking and CategoryErrors
3 pages link to SSHErrors:
