Following Fred's point in the comments (and actually reading the error message), I was incorrect and ssh was connecting. I will leave my original response at the bottom and additionally answer the question of not being able to connect to a running ssh.
Another good way to diagnose ssh issues when the sshd server refuses connections, and if the OP is correct nothing is getting logged in
syslog, is to run it on a separate port with debugging enabled (I've picked the arbitrary port of
/full/path/to/sshd -p 44 -d
You can then connect with your ssh client and get further debugging of the issue:
ssh -p 44 firstname.lastname@example.org
Root (as Fred pointed out in his answer) is a user that can potentially be restricted
via the ssh option
PermitRootLogin option in your
sshd_config. Also the types of authentication methods used by your
sshd_config can further restrict how you can access
Look at the man page for sshd_config (
man 5 sshd_config) for more information on those options. Usually most sshds have
PubkeyAuthentication and sometimes
RSAAuthentication is specific to
Protocol 1 and most hosts use
Protocol 2 which uses
PubkeyAuthentication. Both rely on
root having a key file (usually found in
/root/.ssh/authorized_keys), but this location can be overridden by the
AuthorizedKeysFile option. It looks like
PasswordAuthentication is not enabled on your sshd.
For RSA and Pubkey authentication you need a keypair. Which you have generated and they live on your client machine in
/home/mona/.ssh/id_rsa.pub. The public half of these two files (the key contained in /home/mona/.ssh/id_rsa.pub) you would need to put in root's
authorized_key file mentioned above.
Original Answer, referring to a failure to connect remotely to the sshd process
That looks like either TCPWrappers or a firewall closing the initial connection.
syslog files in
/var/log as these may provide some clues as to which is blocking the connection.
TCPwrappers is usually implemented via a
/etc/hosts.allow file and on some unixes an additional or just the
/etc/hosts.deny file (i.e without a hosts.allow file).
Entries are usually of the form:
<service> : <access list> : <allow|deny>
<service> : <access list>
depending on the type of tcp wrapper being used. The format of these files can usually be found with the hosts_access man page
man 5 hosts_access. You may have to add an entry to allow your remote IP access.
sshd : my.ip.address.here : allow
Most distributions with a Linux kernel tend to use
iptables as the main firewall, though some use
ipchains. (I know FreeBSD uses
ipfw which is ported from NetBSD). You service provider may also have a firewall, or router with a firewall in front of your service which is blocking these requests. As to which firewall your hosts uses will need some investigation.
iptables firewall rules can be listed via the
iptables -nvL command (which must be ran as root, or via sudo). the
INPUT chain is the ruleset used to allow/disallow incoming connections your host. You may have to add a rule to allow SSH connections inbound:
iptables -I INPUT -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from all hosts"
You may want to make it only allow connections from a specific IP:
iptables -I INPUT -s 10.10.10.10 -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from the 10.10.10.10 host"
If your service provider blocks port 22, then you will probably need to put the service on a different port (port
2222 is quite popular) via the
Port option in your
sshd_config file (which usually lives in