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.

Recent Upstart has these new fancy systemd-like features of starting jobs on incoming connection via socket-bridge. I'd like to start my sshd upon first connection to port 22.

I now have: start on socket PROTO=inet PORT=22 in my ssh.conf and I have upstart-socket-bridge and upstart-udev-bridge jobs running.

The ssh job starts OK when I connect to my box on port 22 but sshd doesn't talk back to me. Its as if it doesn't receive it and cannot accept it. Retrying to connect will not help, even sshd is now running and should be accepting the connections normally. Upstart is still messing with it!

Socket event man pages say:

When an incoming connection is detected, the file descriptor representing the socket is passed to the job in question to allow it to accept(2) the connection. Additionally, the environment variable UPSTART_JOB will contain the name of the event ("socket") and the environment variable UPSTART_FDS will contain the number of the file descriptor corresponding to the listening socket.

Does that mean that to take advantage of this, ssh needs specific support to passing socket FD? IF that is the case, it kinda spoils all the fun :/

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

Using the socket bridge requires a patched daemon that can handle the socket that it is given.

From man socket-event:

When an incoming connection is detected, the file descriptor representing the socket is passed to the job in question to allow it to accept(2) the connection. Additionally, the environment variable UPSTART_JOB will contain the name of the event ("socket") and the environment variable UPSTART_FDS will contain the number of the file descriptor corresponding to the listening socket.

While normally sshd would simply create a socket and run listen() then accept() on it, sshd just needs to read the UPSTART_FDS environment variable and accept() on that.

share|improve this answer
    
OK, so just as I expected and wrote on the question (including the quote :P) –  Tuminoid Feb 21 '12 at 12:32
add comment

I'd strongly recommend running sshd as a normal service instead of launching it on demand. sshd is quite capable of managing connections on its own in all but the most extreme cases.

If you absolutely must launch sshd on-demand, the following commands are helpful for troubleshooting:

  • ps auxw | grep ssh, grep for ssh in the list of running processes.
  • netstat -tlp, gives a list of the TCP ports that a service is currently listening on. SSH should be listed here, if not, sshd isn't configured properly.
  • ssh -vvv (run from the client), detailed debug output from your ssh session, helps pinpoint the failure point.
  • nmap <hostname> (run from a client--requires installation of the nmap package), list open ports on the host. If SSH isn't listed here but is listed in the netstat output, you've probably got a firewall issue.
share|improve this answer
    
ps shows sshd is running, netstat gives me only the upstart socket # netstat -tl Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 1 0 (null):22 (null):* LISTEN and ssh -vvv doesn't output anything useful as it cannot connect and nmap is irrelevant. –  Tuminoid Jan 23 '12 at 8:18
    
Unless your system configuration is very strange, that netstat output indicates sshd is listening on the standard SSH port. This can be verified using the -p argument to netstat, as suggested in my original answer. If this is the case, the output of nmap is highly relevant, because a firewall issue is very likely. –  cqcallaw Jan 23 '12 at 16:44
    
Also, I notice you have (null) listed as the IP address in the netstat output. This would suggest that sshd isn't binding to an address correctly. Here's the output from one of my servers where sshd is running and accepting connections: tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN –  cqcallaw Jan 23 '12 at 16:50
    
That is the problem as originally stated: sshd isn't the one having the socket, but Upstart is. Upstart doesn't hand over the socket to sshd correctly. sshd is technically running, but Upstart holds the socket and sshd cannot get it. –  Tuminoid Jan 24 '12 at 5:36
add comment

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.