Having really bizarre behavior with ssh. I have the ssh-server running fine, configured ufw (firewall) fine as well. However, it seems I can't manage ssh as a service or through /etc/init.d/ssh.

I re-installed openssh-server specifically to ensure my minor configuration tweaks to /etc/ssh/sshd_config were not the problem.

Ubuntu:~/$ sudo /etc/init.d/ssh status

Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh status

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the status(8) utility, e.g. status ssh
ssh stop/waiting

and

Ubuntu:~/$ sudo service ssh status
ssh stop/waiting

but I can ssh fine (either from Ubuntu [localhost] or otherComputer [remotely], presume the comp's name is Ubuntu)

otherComputer:~/$ ssh me@Ubuntu
me@Ubuntu's password:
me@Ubuntu:~/$

Very frustrating, unsure what the problem is. I'm running gnome-keyring to manage my ssh-agent and keys, but this shouldn't interfere with ssh-server as a service.

What follows assumes that the computer on which you re-installed openssh-server and from which you are sshing is NOT "Ubuntu", the machine you accessing by means of ssh me@Ubuntu.

I think that your problem is confusion about the difference between the ssh daemon and the ssh client. The ssh daemon (sshd) is the program that allows you or others to ssh into the machine that the daemon is running on. When you run sudo service ssh <whatever> you are giving commands to sshd, i.e. to start or stop or whatever.

The other piece of ssh is the ssh client. This is what you start whenever you run ssh somebody@host.name in a terminal. This is a self-contained program that connects with the ssh daemon running on computer called "host.name". For ssh to work there must be an ssh daemon running on the computer it wants to connect to but there does not need to be one running on its own computer.

What this all means is that your computer is working perfectly fine. You are able to ssh out to a remote server as long as you have networking.

In fact you should probably remove the openssh-server package from your computer as if it is not being used all it would do is be a security risk.

@alex-l answer to me is right:

(as root)

 service ssh status
service ssh stop

then check if the port is up (22)

netstat -nat

that's all

other thing that you can do to check if ereytinh is ok is do from other machine an

ssh -v user@ubuntu-machine

It's worth knowing that as far as I know, the 'service ssh [stop|status]' command, applies to the process identified in /var/run/sshd.pid but the actual process listening can be identified by running 'sudo netstat -lpn |grep ssh' if they don't match, that'll be why the confusion is there.

On my machine this is what I see:-

root@babypuss:/var/www/middletier# ls /var/run/sshd.pid
/var/run/sshd.pid
root@babypuss:/var/www/middletier# cat /var/run/sshd.pid
10959
root@babypuss:/var/www/middletier# ps ax |grep sshd
10959 ? Ss 0:00 /usr/sbin/sshd -D

If the pid's don't match, then (as root) kill the running sshd process and start it again with 'service ssh start' to see what happens.

But as has been said before, if on the Ubuntu machine, you can run 'ps ax |grep sshd' and see nothing running, then check isn't not some kind of xinet type service by asserting via 'netstat -lpn |grep 22' that nothing is listening on port 22. If nothing is really listening, then the most likely problem is that the machine you're connecting to, from somewhere else, isn't the one you're looking at (so check the /etc/hosts file on @otherComputer).

If you're 90% sure it is connecting to the machine you think you are, then double check with 'netstat -n |grep -v ^unix' on each machine, to identify the actual connection, and the shell running on @Ubuntu when it's connected.

If you really can't see the listening service, be afraid. It could be a rootkit. Try shutting down the computer and attempting to reconnect, to be absolutely sure you're connecting to the machine you're worrying about.