Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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.

share|improve this question
    
First, Ubuntu uses upstart. Second, what is the problem ? –  bodhi.zazen Feb 6 '13 at 21:27
    
The problem is that he can't stop the ssh service. –  jdthood Feb 6 '13 at 21:56
1  
@jdthood No. I think he just doesn't understand the difference between an ssh server and the ssh client. –  Alex L. Feb 6 '13 at 22:02
    
@Alex: Ah, yes, that's possible. I was assuming that the machine named 'Ubuntu' was the one running sshd. –  jdthood Feb 6 '13 at 22:07
    
The problem is: I can't stop or reload the service, so none of my changes to the sshd_config are being used (i.e. I can't require only key-based access, disabling plaintext password access). –  Matt Senate Feb 6 '13 at 22:12

3 Answers 3

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.

share|improve this answer
    
I suppose I was a bit vague in my description above, but I am specifically talking about the ssh-server because I do, indeed, ssh in to this computer remotely. Specifically, I use ufw to ensure my mode of connections are well-managed, and would like, for instance, to edit my sshd_config to disable plaintext passphrase access, requiring ssh keys. –  Matt Senate Feb 6 '13 at 22:09
    
Also, I changed some of the names to make my commands anonymous. I'm indeed ssh-ing into this box. –  Matt Senate Feb 6 '13 at 22:10
    
@MattSenate Could you edit your question to add a hostname to each of the prompts. It is difficult to tell which commands are getting run on which computers. –  Alex L. Feb 6 '13 at 22:49
    
Clarified above. –  Matt Senate Feb 7 '13 at 0:00

@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
share|improve this answer
    
The problem is that I'm able to log in to the computer in question via ssh (even remotely), but I cannot manage the ssh service since sudo service ssh status or sudo service ssh stop do nothing. –  Matt Senate Feb 6 '13 at 23:59
    
ok, then do a tailf /var/log/syslog in a terminal (as root) and do sudo service ssh stop in another terminal and tell us whai it say in the first terminal. –  maniat1k Feb 7 '13 at 11:11
    
Log said nothing as I did this: $ sudo service ssh stop [sudo] password: stop: Unknown instance: $ sudo service ssh status ssh stop/waiting $ sudo service ssh start ssh stop/pre-start, process 15740 –  Matt Senate Feb 8 '13 at 1:02

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.