Do you have a question? Post it now! No Registration Necessary. Now with pictures!
February 23, 2007, 3:17 pm
rate this thread
All was working properly this noon.
Sometime this afternoon attempted logins from
remote or loop back from console cause hang.
I found nothing helpful in the logs but I did run
sshd with -d -d -d startup.
I got the following log
1752: debug1: sshd version OpenSSH_3.4p1
1752: debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
1752: debug1: read PEM private key done: type RSA
1752: debug1: private host key: #0 type 1 RSA
1752: debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
1752: debug1: read PEM private key done: type DSA
1752: debug1: private host key: #1 type 2 DSA
1752: Disabling protocol version 1. Could not load host key
1752: debug1: Bind to port 22 on ::.
1752: Server listening on :: port 22.
1752: debug1: Server will not fork when running in debugging mode.
1752: Connection from ::ffff:220.127.116.11 port 2484
1752: debug1: Client protocol version 2.0; client software version
1752: debug1: match: OpenSSH_3.4p1 pat OpenSSH*
1752: Enabling compatibility mode for protocol 2.0
1752: debug1: Local version string SSH-2.0-OpenSSH_3.4p1
1752: debug2: Network child is on pid 1753
1752: debug3: preauth child monitor started
1752: debug3: mm_request_receive entering
1753: debug3: privsep user:group 71:65
1753: debug1: list_hostkey_types: ssh-rsa,ssh-dss
1753: debug3: mm_request_send entering: type 20
1752: debug3: monitor_read: checking request 20
1753: debug3: mm_ssh_gssapi_server_ctx: waiting for
1753: debug3: mm_request_receive_expect entering: type 21
1753: debug3: mm_request_receive entering
I assume it must be a corrupt file someplace, but having no luck
I can ssh from the server to another server and
I can telnet to the server in questions.
Any suggestions appreciated.
Re: sshd failure on Linux (Solved)
Research found that the server (with static address) did not have
dns addresses. We experienced ISP problems during the day,
which I admit I did not mention. Our speculation is that the ISP was
its dns server farm and took the addresses referenced by this server
of service. They were current dns addresses several years ago. As
soon as we changed the server dns addresses to the current batch, the
problem was solved.
- » Port forwarding - different results between using "127.0.0.1" and "localhost"
- — Next thread in » Secure Shell Forum
- » protocol question - issue with exit-status inside unfinished data stream?
- — Newest thread in » Secure Shell Forum