ROOTVG

We have moved telnet from its original port of 23 to another port number for whatever small security gains we can make. We would like to be able to stop and start the telnet daemon during certain processing cycles but the stopsrc and startsrc functions will not work with the port defined as anything other than 23. We are trying to keep rlogin running while taking telnet down so we don't want to use /etc/tcp.clean to stop any network connections. It is like stopsrc and startsrc are not using /etc/services to stop or start the daemon. This machine is currently running AIX 5.1.0.0.

# startsrc -t telnet
0513-087 The  Subsystem has received a request that
it does not understand and could not service.
Contact System Administration.

# stopsrc -t telnet
0513-056 Timeout waiting for command response. If you specified a foreign host
see the /etc/inittab file on the foreign host to verify that the SRC daemon
(srcmstr) was started with the -r flag to accept remote requests.

Thanks,
Pat

I had never used the -t option before. And I see some dangers - on my system - right away. (Other than perhaps with smit.) In other words - great question!  :)

On my system I have two entries for telnet - one from AIX, and one I tcp_wrap.

I double commented out the AIX standard version, and stopped the wrapped one with stopsrc -t telnet and this is what I ended up with in /etc/inetd.conf


# grep telnet /etc/inetd.conf
##  telnet  stream  tcp6    nowait  root    /usr/sbin/telnetd      telnetd -a
#telnet stream  tcp     nowait  root    /usr/local/bin/tcpd telnetd -a


On a startsrc -s telnet directly after this I got:

# grep telnet /etc/inetd.conf
#  telnet  stream  tcp6    nowait  root    /usr/sbin/telnetd      telnetd -a
telnet stream  tcp     nowait  root    /usr/local/bin/tcpd telnetd -a


Notice - one comment character is gone from both lines. I would have to delete the line, or change the keyword - telnet - to stay alive.

So much for the behavior of startsrc/stopsrc -t telnet.

Now the problem with the port number. The three commands AIX provides for manipulating SRC subsystems are: mkssys, chssys and rmssys. Unfortunately there is not an lsssrc.

So, the alturnative is to go to the OBJDIR - or /etc/objrepos and grep in the SRC ODM files for telnet.


# grep -c telnet SRC*                   
SRCextmeth:0
SRCnotify:0
SRCodmlock:0
SRCsubsvr:1
SRCsubsys:0

# odmget SRCsubsvr | grep telnet       
        sub_type = "telnet"

# odmget -q sub_type="telnet" SRCsubsvr

SRCsubsvr:
        sub_type = "telnet"
        subsysname = "inetd"
        sub_code = 23


In an ideal world I would know the chssys command needed to make the change. In this case I would probably make the change using odmchange. I'll leave that to you - but dont hesitate to ask for assistence if you have never used odmget, odmchange, odmdelete, etc..

Michael

The double commenting "##" of lines that you never want uncommented is a good idea, however, I recommend using the "chsubserver" command to edit /etc/inetd.conf automatically, to comment or uncomment a specified line service as follows:

chsubserver -a -p tcp -v telnet   # uncomments to enable
refresh -s inetd                        # and refresh to pick that up

chsubserver -d -p tcp -v telnet   # comments out to disable
refresh -s inetd

The mkssys, chssys and rmssys don't appear to have flags to handle a change of telnet port in the SRCsubsvr ODM object class, and in any event, changing that ODM entry makes no difference when you test it with the telnet service !

It's /etc/services that you need to configure to change the telnet port used:

To change port 23 to 4023 say:
chservices -c  -v 'telnet' -p 'tcp' -n '23' -N '4023'
refresh -s inetd

To restore that to normal:
chservices -c  -v 'telnet' -p 'tcp' -n '4023' -N '23'
refresh -s inetd
                   
If you did also want to edit the ODM, then here's the syntax for that, but take GREAT CARE with it, as you could easily wipe out your ODM file !
odmget -q sub_type="telnet" SRCsubsvr | sed 's/ 23$/ 4023/' > /tmp/odm 
odmchange -q sub_type="telnet" -o SRCsubsvr /tmp/odm

John and Michael,

        Thank you very much for both of your responses. They both contained useful information that I am attempting to put in place. Hopefully, one my attempts will be successful.

Thanks again,

Pat