SSH on Multiple ports Fedora Core 4

[John Gallagher]

> -----Original Message-----
> From: Christopher K. Johnson [mailto:ckjohnson at gwi.net] 
> Sent: Monday, November 28, 2005 6:07 PM

> You're on the right path for what you want to do.  I don't 
> recommend having ssh so open, even from the inside, but that 
> _is_ your decision.
> The error is probably a red-herring.  Start both ssh daemons 
> then check the lstening ports:
> netstat -atnp | grep ssh
> 
> Chances are all is fine and the issue is that you have ipv6 
> and ipv4 enabled (fc4 default) and ssh is discovering a 
> conflict opening a socket to listen at the designated port on 
> the ipv6 superset of your address, and then another socket to 
> listen at the designated port on the ipv4 address.
> 
> If you don't actually need ipv6 add the following to 
> /etc/modprobe.conf and then reboot:
> alias net-pf-10 off
> 
> Chris



Part of my original post was that I ran this on FC1.  Actually it is running
on FC1, however the same behavior can be seen if you use the service command
to start/stop the one of the processes.  Apparently because the last process
started becomes the PID, the start, stop function of the init script can
effect both processes.

 /var/run/sshd.pid
             Contains the process ID of the sshd listening for connections
(if
             there are several daemons running concurrently for different
             ports, this contains the process ID of the one started last).
             The content of this file is not sensitive; it can be
world-read-
             able.

Does anyone know of a way to change that behavior short of compiling another
binary that uses another PID?

I am also running jailkit on the system so all of the users except a select
few only have full shell access.  The internal login is so users can set up
the rsa keys.  I could not figure out an easy method for users to change
passwords when running in the chroot jail so we settled on using RSA key
pairs for auth on outside connections. 

The system is a jump off box to the internal network.

Thanks for the info, 

John