Has your sshd task always been named SSHD3? In your TCP/IP profile member do
you have another task name defined as reserving port 22?
On Fri, 26 May 2023 18:09:12 -0700, Tom Brennan <t...@tombrennansoftware.com>
wrote:
>Can you change the port from 22 to something over 1023 for a quick test?
>
>On 5/26/2023 6:01 PM, Tom Brennan wrote:
>> This may be way off so ignore if it sounds crazy...
>> Here's a snip of some old server code I wrote in C for Linux:
>>
>> client_sockin.sin_port = htons(port);
>> rc = bind(local_socket,(struct sockaddr
>> *)&client_sockin,sizeof(client_sockin));
>> if (rc != 0) log_msg(0,LM_EXIT,12,"Cannot bind to port %d
>> rc=%d",port,rc);
>>
>> When I run that code (on Linux) and tell it to listen on port 12345 it
>> works just fine. When I specify something under 1024, it fails with the
>> "Cannot bind..." message.
>>
>> However if I specify a port less than 1024 and run it under root uid=0,
>> it works fine. In other words, in Linux (and I think the mainframe USS
>> too) you're not allowed to listen on a port less than 1024 unless you're
>> root.
>>
>> But you already checked that the task is running under uid=0, so that's
>> why I'm confused. However, the message indicated "Bind" so I don't
>> think it has anything to do with certificates. I'm pretty sure any TLS
>> and cert negotiation comes after the bind() in a server program.
>>
>> On 5/26/2023 4:48 PM, Wendell Lovewell wrote:
>>> I've done something wrong that I can't identify, and now SSHD
>>> terminates immediately after starting.
>>>
>>> I'm not getting anything helpful on the console or in the joblog. But
>>> I am getting these msgs in syslog:
>>>
>>> OMVSKERN SSHD3 sshd[67174408]: error: FOTS1442 Bind to port 22 on
>>> :: failed: EDC5111I Permission denied. (errno2=0x744C7246).
>>> OMVSKERN SSHD3 sshd[67174408]: error: FOTS1442 Bind to port 22 on
>>> 0.0.0.0 failed: EDC5111I Permission denied. (errno2=0x744C7246).
>>> OMVSKERN SSHD3 sshd[67174408]: fatal: FOTS1464 Cannot bind any
>>> address.
>>>
>>> I've looked up the 7246 code:
>>> JRPORTACCESSAUTH EQU 29254 * User does not have authority
>>> to access this port.
>>>
>>> OMVSKERN's is UID(0). Has ALTER access to BPX.DAEMON. Port 22 is not
>>> in use, per D TCPIP,,N,SOCKETS
>>>
>>> None of the files in /etc/ssh had changed for 4 years, so I don't
>>> think it's there. (I did set LogLevel to DEBUG3, which didn't help any.)
>>>
>>> The only things I can think of that I might have messed up something
>>> with keys. I did try some weeks ago to set up a certificate to bypass
>>> entering my password when using "ssh user@zos" and didn't get that to
>>> work. And I did install a new CERTAUTH this week for the new IBM
>>> service requirement ("DigiCert Global Root G2"), 'tho I can't imagine
>>> that would matter.
>>>
>>> Any suggestions would really be appreciated...I'm not much good with
>>> entering USS commands via a 3270 screen.
>>>
>>> TIA,
>>> Wendell
>>>
>>> ----------------------------------------------------------------------
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>
>>
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
