Re: ssh delays 40 seconds (revisited)
Kevin Kinsey wrote: Robert Marella wrote: luke wrote: also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. Curious and more curious. I updated one of my systems to 5.4 p2 today and just for grins I changed the UseDNS option back to "yes". Then I restarted sshd and there was no delay. I then changed the UseDNS option on all of the other boxes (5.4 REL) to yes and restarted sshd and they all work without delay. So, I am back to where I was before I went to where I got. And everything works like it always did. Any idea why this happened to so many people last weekend. Or should we just smile and go about our merry way. Thanks to all who responded last weekend. Robert Did you get reverse DNS set up in the interceding few days, as you said you thought you might look into when you typed: ] The consensus was ] that I need DNS/named working on my gateway/firewall so I will be ] reading and studying to have that working in the near future. ] just curious, as you are "curious and more curious" :-D Kevin Kinsey Ummm .. no. It was on my list of things to do that I didn't do. You know what they say about curious. :) Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds (revisited)
Robert Marella wrote: luke wrote: also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. Curious and more curious. I updated one of my systems to 5.4 p2 today and just for grins I changed the UseDNS option back to "yes". Then I restarted sshd and there was no delay. I then changed the UseDNS option on all of the other boxes (5.4 REL) to yes and restarted sshd and they all work without delay. So, I am back to where I was before I went to where I got. And everything works like it always did. Any idea why this happened to so many people last weekend. Or should we just smile and go about our merry way. Thanks to all who responded last weekend. Robert Did you get reverse DNS set up in the interceding few days, as you said you thought you might look into when you typed: ] The consensus was ] that I need DNS/named working on my gateway/firewall so I will be ] reading and studying to have that working in the near future. ] just curious, as you are "curious and more curious" :-D Kevin Kinsey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds (revisited)
luke wrote: also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. Curious and more curious. I updated one of my systems to 5.4 p2 today and just for grins I changed the UseDNS option back to "yes". Then I restarted sshd and there was no delay. I then changed the UseDNS option on all of the other boxes (5.4 REL) to yes and restarted sshd and they all work without delay. So, I am back to where I was before I went to where I got. And everything works like it always did. Any idea why this happened to so many people last weekend. Or should we just smile and go about our merry way. Thanks to all who responded last weekend. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds (SOLVED???)
I want to thank everyone else for responding also. The consensus was that I need DNS/named working on my gateway/firewall so I will be reading and studying to have that working in the near future. This is what I ended up having to do today...I tried to do what you did (set 'UseDNS no' in sshd_config), but my problem was that not all of my boxes are 5.3 or 5.4on my 5.2.1 boxes, using the 'UseDNS no' caused sshd not to restart. Same problem on some of my older Linux boxes still running. So I set up some in-addr.arpa records for my internal subnets (which I never bothered to do or needed to do before) , and that seemed to take care of things. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds (SOLVED???)
Kevin Kinsey wrote: Robert Marella wrote: luke wrote: also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. Did something change with 5.4? I don't think so; I've had the problem appear a long time ago from some locations. Looking at the CVS web, it appears that *maybe* this came on when OpenSSH 3.7.1p2 was imported in January, 2004. So maybe you were a little behind on mergemaster ... Hello Kevin I built this gateway in January 2005 with 5.3 CDs. All worked fine so (IIRC) I waited until 5.4 was released to update. There is also a good chance that I did some incremental 5.3 updates but I can't be for sure because all was well on the gateway and I was doing the incremental thing on other boxes. Either way, OpenSSH 3.7.1p2 would have been on the CD. I'm pretty anal about doing the mergemaster dance when updating :) Thanks for the $0.02. Always appreciated. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds (SOLVED???)
Robert Marella wrote: luke wrote: also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. Did something change with 5.4? I don't think so; I've had the problem appear a long time ago from some locations. Looking at the CVS web, it appears that *maybe* this came on when OpenSSH 3.7.1p2 was imported in January, 2004. So maybe you were a little behind on mergemaster ... Kevin Kinsey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds (SOLVED???)
Resending because I did not see it come in ti -questions and I keep having mail bounced sending to "Jonathan Chen <[EMAIL PROTECTED]>". luke wrote: also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. Luke Okay, that takes care of the delay. I had to change it to "no" on all boxes that I ssh into. Does this have any negative ramifications? My firewall excludes all incoming (at this time) so I am not too worried about being compromised. It still leaves the question in my pea brain as to why it has worked for 6 months and just started this nonsense in the last week or so. Did something change with 5.4? Thanks for responding. I want to thank everyone else for responding also. The consensus was that I need DNS/named working on my gateway/firewall so I will be reading and studying to have that working in the near future. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds (SOLVED???)
luke wrote: also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. Luke Okay, that takes care of the delay. I had to change it to "no" on all boxes that I ssh into. Does this have any negative ramifications? My firewall excludes all incoming (at this time) so I am not too worried about being compromised. It still leaves the question in my pea brain as to why it has worked for 6 months and just started this nonsense in the last week or so. Did something change with 5.4? Thanks for responding. I want to thank everyone else for responding also. The consensus was that I need DNS/named working on my gateway/firewall so I will be reading and studying to have that working in the near future. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds
also, you might want to look into the UseDNS option in the sshd_config file. this will cause the server to not perform dns lookups on connecting hosts. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds
Robert Marella wrote: Jonathan Chen wrote: On Sun, Jun 05, 2005 at 04:49:26PM -1000, Robert Marella wrote: Jonathan Chen wrote: [...] It's not the forward case that's the problem. The sshd daemon on the server side attempts to find out where the connection is from by doing a reverse-lookup. If the incoming IP hasn't got a DNS entry, the failing DNS ip-lookup will time out in ~30s. Thanks for responding. In all of my systems /etc/hosts is populated with the name and LAN IP address of all other boxes. My gateway/firewall is a 5.4 Rel computer. I can ping that box "it's called gateway" with ping gateway or ping 10.0.0.1 no problem. What does "dig -x 10.0.0.1" on the ssh-server box give you? Looks like you need to set up a internal DNS server to resolve these sort of problems. Cheers. Jonathan from my gateway box. The 24.25.227.64 is also found in resolv.conf placed there by dhcpd from roadrunner. [EMAIL PROTECTED]:~> dig -x 10.0.0.1 ; <<>> DiG 9.3.1 <<>> -x 10.0.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51746 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.10.in-addr.arpa. IN PTR ;; Query time: 4208 msec ;; SERVER: 24.25.227.64#53(24.25.227.64) ;; WHEN: Sun Jun 5 16:58:13 2005 ;; MSG SIZE rcvd: 39 No ANSWER section. . . seems to prove that the issue is probably reverse DNS, AFAIAC. Should look more like: == #dig -x 192.168.0.1 ; <<>> DiG 9.3.0 <<>> -x 192.168.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50363 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;1.0.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.168.192.in-addr.arpa. 86400 IN PTR archangel.daleco.biz.0.168.192.in-addr.arpa. === I forget which, but one chapter in the handbook deals with running a nameserver; getting reverse DNS should eliminate your delay issue. Kevin Kinsey DaleCo, S.P. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds
Jonathan Chen wrote: On Sun, Jun 05, 2005 at 04:49:26PM -1000, Robert Marella wrote: Jonathan Chen wrote: [...] It's not the forward case that's the problem. The sshd daemon on the server side attempts to find out where the connection is from by doing a reverse-lookup. If the incoming IP hasn't got a DNS entry, the failing DNS ip-lookup will time out in ~30s. Thanks for responding. In all of my systems /etc/hosts is populated with the name and LAN IP address of all other boxes. My gateway/firewall is a 5.4 Rel computer. I can ping that box "it's called gateway" with ping gateway or ping 10.0.0.1 no problem. What does "dig -x 10.0.0.1" on the ssh-server box give you? Looks like you need to set up a internal DNS server to resolve these sort of problems. Cheers. Jonathan from my gateway box. The 24.25.227.64 is also found in resolv.conf placed there by dhcpd from roadrunner. [EMAIL PROTECTED]:~> dig -x 10.0.0.1 ; <<>> DiG 9.3.1 <<>> -x 10.0.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51746 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.10.in-addr.arpa. IN PTR ;; Query time: 4208 msec ;; SERVER: 24.25.227.64#53(24.25.227.64) ;; WHEN: Sun Jun 5 16:58:13 2005 ;; MSG SIZE rcvd: 39 This is from one of the clients on my lan [frankie] ~> dig -x 10.0.0.1 ; <<>> DiG 9.3.1 <<>> -x 10.0.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34691 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.10.in-addr.arpa. IN PTR ;; Query time: 3356 msec ;; SERVER: 24.25.227.64#53(24.25.227.64) ;; WHEN: Sun Jun 5 16:59:51 2005 ;; MSG SIZE rcvd: 39 I hope this helps you help me. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds
On Sun, Jun 05, 2005 at 04:49:26PM -1000, Robert Marella wrote: > Jonathan Chen wrote: [...] > >It's not the forward case that's the problem. The sshd daemon on the > >server side attempts to find out where the connection is from by doing > >a reverse-lookup. If the incoming IP hasn't got a DNS entry, the failing > >DNS ip-lookup will time out in ~30s. > > > > Thanks for responding. In all of my systems /etc/hosts is populated with > the name and LAN IP address of all other boxes. My gateway/firewall is a > 5.4 Rel computer. I can ping that box "it's called gateway" with ping > gateway or ping 10.0.0.1 no problem. What does "dig -x 10.0.0.1" on the ssh-server box give you? Looks like you need to set up a internal DNS server to resolve these sort of problems. Cheers. -- Jonathan Chen <[EMAIL PROTECTED]> -- Vini, vidi, velcro... I came, I saw, I stuck around ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds
Jonathan Chen wrote: On Sun, Jun 05, 2005 at 03:25:08PM -1000, Robert Marella wrote: Robert Huff wrote: Richard J. Valenta writes: I had this problem in the past, and it was due to DNS problems where my IP from the client machine was unable to be resolved... but I think it took longer than 40 seconds. I mentioned this in this list before, a search of the list may help. Affirmed for the general case. "30 second delay, then normal network activity" _screams_ DNS misconfiguration, usually but not always in the client side. Robert Huff Forgive me if I am dense. According to the readout of "ssh -vvv gateway" the connection is made immediately. Does that not indicate that it knew where to go? It's not the forward case that's the problem. The sshd daemon on the server side attempts to find out where the connection is from by doing a reverse-lookup. If the incoming IP hasn't got a DNS entry, the failing DNS ip-lookup will time out in ~30s. Cheers. Jonathan Thanks for responding. In all of my systems /etc/hosts is populated with the name and LAN IP address of all other boxes. My gateway/firewall is a 5.4 Rel computer. I can ping that box "it's called gateway" with ping gateway or ping 10.0.0.1 no problem. I ssh there and it takes 40 seconds to provide me with a request for passphase. Once I'm in there I can ping all other boxes with name or IP. If I ssh from there to any box it takes 40 seconds for that next box to request a password. This happens from any box to any box. It was working perfectly until this week. It might be realted to me updating the gateway box from 5.3 to 5.4 but I know I had accessed it right after upgrade because it is headless and I had to ssh into it to do the world/kernel thing. Other than /etc/hosts and /etc/resolv.conf is there any other config files I should check. Thanks again for your time. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds
On Sun, Jun 05, 2005 at 03:25:08PM -1000, Robert Marella wrote: > Robert Huff wrote: > >Richard J. Valenta writes: > > > > > >>I had this problem in the past, and it was due to DNS problems where my > >>IP from the client machine was unable to be resolved... but I think it > >>took longer than 40 seconds. I mentioned this in this list before, a > >>search of the list may help. > > > > > > Affirmed for the general case. "30 second delay, then normal > >network activity" _screams_ DNS misconfiguration, usually but not > >always in the client side. > > > > > > Robert Huff > > Forgive me if I am dense. According to the readout of "ssh -vvv gateway" > the connection is made immediately. Does that not indicate that it knew > where to go? It's not the forward case that's the problem. The sshd daemon on the server side attempts to find out where the connection is from by doing a reverse-lookup. If the incoming IP hasn't got a DNS entry, the failing DNS ip-lookup will time out in ~30s. Cheers. -- Jonathan Chen <[EMAIL PROTECTED]> -- "I don't want to achive immortality through my works.. I want to achieve it through not dying" - Woody Allen ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh delays 40 seconds
Robert Huff wrote: Richard J. Valenta writes: I had this problem in the past, and it was due to DNS problems where my IP from the client machine was unable to be resolved... but I think it took longer than 40 seconds. I mentioned this in this list before, a search of the list may help. Affirmed for the general case. "30 second delay, then normal network activity" _screams_ DNS misconfiguration, usually but not always in the client side. Robert Huff Forgive me if I am dense. According to the readout of "ssh -vvv gateway" the connection is made immediately. Does that not indicate that it knew where to go? The contents of "/etc/resolv.conf" on all of my systems is the same: [frankie] ~> cat /etc/resolv.conf search hawaii.rr.com nameserver 24.25.227.33 nameserver 24.25.227.66 nameserver 24.25.227.64 I even commented out the other 2 and tried each nameserver one at a time and it was able to resolve www.freebsd.org Am I looking in the wrong place? Again, if I am ignorant, please excuse me. Perhaps, point me to a document. Thanks to all who responded Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ssh delays 40 seconds
Richard J. Valenta writes: > I had this problem in the past, and it was due to DNS problems where my > IP from the client machine was unable to be resolved... but I think it > took longer than 40 seconds. I mentioned this in this list before, a > search of the list may help. Affirmed for the general case. "30 second delay, then normal network activity" _screams_ DNS misconfiguration, usually but not always in the client side. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ssh delays 40 seconds
I had this problem in the past, and it was due to DNS problems where my IP from the client machine was unable to be resolved... but I think it took longer than 40 seconds. I mentioned this in this list before, a search of the list may help. rjv -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phusion Sent: Sunday, June 05, 2005 6:11 PM To: Robert Marella Cc: freebsd-questions@freebsd.org Subject: Re: ssh delays 40 seconds I've noticed this same thing on one of the machines I've built in the last week. The machine is running FreeBSD 5.4-STABLE with OpenSSH 4.0p1. The delay is probably about 30 seconds. Also, the machine isn't being used by anyone at the time. This happens when connecting from one local machine to another local machine on the same LAN. On 6/5/05, Robert Marella <[EMAIL PROTECTED]> wrote: > A little nudge is needed. All of a sudden, my attempts to ssh any of the > other computers in my SOHO take 40 seconds before I am prompted for a > password or pass-phrase. At that time I can log in and all is well. It > is consistent in all directions. > > I have made NO changes to ssh or any other config file. I don't believe > it is dns because I can ping and connect quickly to inside and outside > locations using x.x.x.x or www.blah.org from all computers. > > I have attached the output of ssh -vvv with comments as to were the > delay occurs. I need some help or direction as to what it all means. > > I thank you > > Robert > > P.S I have also attached a network map. > > > [frankie] ~> ssh -vvv gateway > OpenSSH_3.8.1p1 FreeBSD-20040419, OpenSSL 0.9.7e 25 Oct 2004 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to gateway [10.0.0.1] port 22. > debug1: Connection established. > debug1: identity file /home/robert/.ssh/identity type -1 > debug3: Not a RSA1 key file /home/robert/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-BEGIN' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'Proc-Type:' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'DEK-Info:' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-END' > debug3: key_read: missing keytype > debug1: identity file /home/robert/.ssh/id_rsa type 1 > debug1: identity file /home/robert/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 FreeBSD-20040419 > debug1: match: OpenSSH_3.8.1p1 FreeBSD-20040419 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 FreeBSD-20040419 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-dss,ssh-rsa > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-9 6,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-9 6,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-dss > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha
Re: ssh delays 40 seconds
I've noticed this same thing on one of the machines I've built in the last week. The machine is running FreeBSD 5.4-STABLE with OpenSSH 4.0p1. The delay is probably about 30 seconds. Also, the machine isn't being used by anyone at the time. This happens when connecting from one local machine to another local machine on the same LAN. On 6/5/05, Robert Marella <[EMAIL PROTECTED]> wrote: > A little nudge is needed. All of a sudden, my attempts to ssh any of the > other computers in my SOHO take 40 seconds before I am prompted for a > password or pass-phrase. At that time I can log in and all is well. It > is consistent in all directions. > > I have made NO changes to ssh or any other config file. I don't believe > it is dns because I can ping and connect quickly to inside and outside > locations using x.x.x.x or www.blah.org from all computers. > > I have attached the output of ssh -vvv with comments as to were the > delay occurs. I need some help or direction as to what it all means. > > I thank you > > Robert > > P.S I have also attached a network map. > > > [frankie] ~> ssh -vvv gateway > OpenSSH_3.8.1p1 FreeBSD-20040419, OpenSSL 0.9.7e 25 Oct 2004 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to gateway [10.0.0.1] port 22. > debug1: Connection established. > debug1: identity file /home/robert/.ssh/identity type -1 > debug3: Not a RSA1 key file /home/robert/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-BEGIN' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'Proc-Type:' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'DEK-Info:' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-END' > debug3: key_read: missing keytype > debug1: identity file /home/robert/.ssh/id_rsa type 1 > debug1: identity file /home/robert/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 > FreeBSD-20040419 > debug1: match: OpenSSH_3.8.1p1 FreeBSD-20040419 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 FreeBSD-20040419 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-dss,ssh-rsa > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL > PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL > PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL > PROTECTED],hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL > PROTECTED],hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL > PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL > PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL > PROTECTED],hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL > PROTECTED],hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: none,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 129/256 > debug2: bits set: 519/1024 > debug1: S
ssh delays 40 seconds
A little nudge is needed. All of a sudden, my attempts to ssh any of the other computers in my SOHO take 40 seconds before I am prompted for a password or pass-phrase. At that time I can log in and all is well. It is consistent in all directions. I have made NO changes to ssh or any other config file. I don't believe it is dns because I can ping and connect quickly to inside and outside locations using x.x.x.x or www.blah.org from all computers. I have attached the output of ssh -vvv with comments as to were the delay occurs. I need some help or direction as to what it all means. I thank you Robert P.S I have also attached a network map. [frankie] ~> ssh -vvv gateway OpenSSH_3.8.1p1 FreeBSD-20040419, OpenSSL 0.9.7e 25 Oct 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to gateway [10.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/robert/.ssh/identity type -1 debug3: Not a RSA1 key file /home/robert/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /home/robert/.ssh/id_rsa type 1 debug1: identity file /home/robert/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 FreeBSD-20040419 debug1: match: OpenSSH_3.8.1p1 FreeBSD-20040419 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 FreeBSD-20040419 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 129/256 debug2: bits set: 519/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/robert/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'gateway' is known and matches the DSA host key. debug1: Found key in /home/robert/.ssh/known_hosts:1 debug2: bits set: 505/1024 debug1: ssh_dss_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent
