I would suggest the following in addition to the answers already present. Ensure you have some way to restore you're firewall after carefully checking its ruleset.
Disclaimer: if this device is an internet facing machine, this will drop all firewall protection from all interfaces, and could lead to your box getting owned.
# iptables --flush
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT
# /etc/init.d/openssh-server restart
Then retry connection via ssh, if that fails check /var/log/auth.log.
You can also use
# lsof -i TCP:22
to see if the ssh port is opened and what IP address it's listening on.
edit:
re: update, that doesn't appear to be ssh related (it seems to be in relation to sudo privilege elevation.
try tail -f /var/log/auth.log while attempting to connect via ssh.
Connection refused mean that the connection was explicitly rejected by either a firewall or the daemon it's self.
A normal connection would look something like this:
Mar 23 13:32:32 <hostname> sshd[20100]: Accepted password for <user> from xxx.xxx.xxx.xxx port xxxxx ssh2
Mar 23 13:32:32 <hostname> sshd[20102]: (pam_unix) session opened for user <user> by (uid=0)
While an authentication failure will look like this:
Mar 23 13:35:54 <hostname> sshd[20177]: Failed password for <user> from xxx.xxx.xxx.xxx port xxxxx ssh2
If it were blocked by sshd for some reason, that will be eluded to in the auth log, if it were blocked by the firewall (note the firewall may be on the host, client or somewhere in between) you'll see nothing.
Get back to us if that's the case, from there it'll be tcp dump on the client, server and any intermediary routers.
I've seen cases where even setting ConnectTimeout doesn't work. This can be particularly annoying when using automated ssh connections to large numbers of servers. My solution is to use a wrapper on the client side that kills the ssh process if it doesn't connect and return quickly enough. Something like this (in perl):
$SshCmd = "ssh server.example.com uname -a";
$TimeOut = 120;
eval {
local $SIG{ALRM} =
sub {
# ignore SIGHUP here so the kill only affects children.
local $SIG{HUP} = 'IGNORE';
kill 1,(-$$);
print STDERR "ssh terminated, max run time of $TimeOut seconds exceeded.\n";
};
alarm $TimeOut;
system ($SshCmd) || die "failed to run $SshCmd: $!";
alarm 0;
};
$SIG{HUP} = 'DEFAULT';
That sets an alarm of $TimeOut
seconds, and kills the child (the ssh command) if the alarm is exceeded.
Best Answer
There is a "secret" keyboard shortcut to force an exit :~) From the frozen session, hit these keys in order: Enter~. The tilde (only after a newline) is recognized as an escape sequence by the ssh client, and the period tells the client to terminate it's business without further ado.
The long-hang behavior on communication issues is not a bug, the SSH session is hanging out hoping the other side will come back. If the network breaks, sometimes even days later you can get an SSH session back. Of course you can specifically tell it to give up and die with the sequence above. There are also various things you can do such as setting keep-alive timeouts in your client so that if it doesn't have an active link for a certain amount of time it shuts off on it's own, but the default behavior is to stay as connected as possible!
Edit: Another useful application of this interrupt key is to get the attention of the local ssh client and background it to get back to your local shell for a minute —say to get something from your history— then forground it to keep working remotely. Enter~ Ctrl+Z to send the ssh client to the background job queue of your local shell, then
fg
as normal to get it back.Edit: When dealing with nested SSH sessions, you can add multiple tilde characters to only break out of one of the SSH sessions in the chain, but retain the others. For example, if you're nested in 3 levels, (i.e. you ssh from local->Machine1->Machine2->Machine3), Enter~. will get you back to your local session, Enter~~. will leave you in Machine1, and Enter~~~. will leave you in Machine2. This works for other escape sequences as well, such as moving the ssh session to background temporarily. The above works for any level of nesting, by just adding more tilde's.
Finally, you can use Enter~? to print a help menu of available escape commands.
TL;DR - the supported escape commands are Supported escape sequences: