On Wed, Mar 01, 2006 at 12:28:14AM +0900, Hajimu UMEMOTO wrote:
Hi,
On Mon, 27 Feb 2006 18:19:54 +0300
Yar Tikhiy [EMAIL PROTECTED] said:
yar I finally spared some time to test your recent changes and found
yar that the resolver still would retry using the first, and only the
yar
On Sat, Feb 25, 2006 at 04:28:50PM +0900, Hajimu UMEMOTO wrote:
On Sat, 25 Feb 2006 02:42:46 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
rosti getaddrinfo() is called in two places with hints.ai_socktype == 0 and
On Wed, 1 Mar 2006 15:45:13 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
On Sat, Feb 25, 2006 at 04:28:50PM +0900, Hajimu UMEMOTO wrote:
On Sat, 25 Feb 2006 02:42:46 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
Hi,
On Wed, 1 Mar 2006 15:45:13 +0300
Yar Tikhiy [EMAIL PROTECTED] said:
yar I finally tried the proposed patches for ftpd and really liked the
yar idea of reducing the name queries made to only one address family
yar if it's known. Thank you both!
I've committed both patches into HEAD.
yar
Hi,
On Mon, 27 Feb 2006 18:19:54 +0300
Yar Tikhiy [EMAIL PROTECTED] said:
yar I finally spared some time to test your recent changes and found
yar that the resolver still would retry using the first, and only the
yar first, domain on the `search' list when the nameserver was down,
yar which
On Wed, 01 Mar 2006 00:28:14 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Mon, 27 Feb 2006 18:19:54 +0300
Yar Tikhiy [EMAIL PROTECTED] said:
yar I finally spared some time to test your recent changes and found
yar that the resolver still would retry using the first, and only
On Sat, Feb 25, 2006 at 02:08:21AM +0900, Hajimu UMEMOTO wrote:
On Fri, 24 Feb 2006 15:51:53 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti Excellent! What about RES_DFLRETRY decreasing from 4 to 2? Does it need
rosti more testing or discussion?
It seems reasonable to me, and
Yar Tikhiy wrote:
[ ... ]
A similar effect was observed when a `domain' line was specified
in resolv.conf in place of `search'.
Is there a real reason to retry with a different domain when the
nameserver doesn't respond at all?
UDP is lossy, and it may take a nameserver longer to respond
Chuck Swiger [EMAIL PROTECTED] wrote:
Yar Tikhiy wrote:
[ ... ]
A similar effect was observed when a `domain' line was specified
in resolv.conf in place of `search'.
Is there a real reason to retry with a different domain when the
nameserver doesn't respond at all?
UDP is lossy, and
On Sun, 26 Feb 2006 09:45:34 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Sun, 26 Feb 2006 01:46:30 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti.bsd As far as I understand the code of selecthost() it walks through
linked
rosti.bsd lists of known virtual hosts and
Hi,
On Sun, 26 Feb 2006 17:40:19 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti It will require to specify a virtual host for each address or to use
rosti hostname with multiple addresses only once. Specifying a virtual host by
rosti a hostname and registering multiple hostname's
On Mon, 27 Feb 2006 02:49:15 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Sun, 26 Feb 2006 17:40:19 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti It will require to specify a virtual host for each address or to use
rosti hostname with multiple addresses only once.
Hi,
On Sun, 26 Feb 2006 22:56:32 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti Could you please suggest a good
rosti comprehensive article on the Web about IPv4-mapped IPv6 addresses and
rosti their usage?
You can find some documents by googling with `IPv4-mapped IPv6
address'.
In
Hi--
Hajimu UMEMOTO wrote:
[ ... ]
For ftp.c.diff, how about considering adding new option for timeout?
However, I'm still in doubt. I cannot think it is usual situation
that there are unreachable IP addresses in /etc/resolv.conf.
Certainly that situation is not usual, in the sense that
On Sat, Feb 25, 2006 at 02:42:46AM +0200, Rostislav Krasny wrote:
On Fri, 24 Feb 2006 20:40:07 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
To Rostislav: Could you do now, with the resolver fixes applied,
the following experiment: find how many dead nameservers in resolv.conf
it takes for
On Sat, 25 Feb 2006 16:28:50 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Sat, 25 Feb 2006 02:42:46 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
rosti getaddrinfo() is called in two places with
On Sat, 25 Feb 2006 17:22:07 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
However I was unable to connect by ftp, even with only one unreachable
name server in resolv.conf. I got following error:
421 Service not available, remote server timed out. Connection closed
I've found the
Hi,
On Sat, 25 Feb 2006 16:46:48 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti family = his_addr.su_family; is really a good idea. But what is the
rosti reason to check if IPv6 address of a remote client is IPv4 mapped and
rosti assign AF_INET to a 'family' when that's true? The
Hi,
On Sat, 25 Feb 2006 17:14:47 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
- hints.ai_flags = 0;
- hints.ai_family = AF_UNSPEC;
+ /* If no flag, assign hints.ai_flags to zero! */
Sorry, but I don't understand the purpose of
On Sun, 26 Feb 2006 01:41:28 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Sat, 25 Feb 2006 16:46:48 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti family = his_addr.su_family; is really a good idea. But what is the
rosti reason to check if IPv6 address of a remote client
Hi,
On Sun, 26 Feb 2006 01:46:30 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti.bsd As far as I understand the code of selecthost() it walks through
linked
rosti.bsd lists of known virtual hosts and their addresses and compares the
rosti.bsd addresses to a local address of connected
On Fri, 24 Feb 2006 11:50:25 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
Hello
On Thu, 23 Feb 2006 23:57:27 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti Your patch fixed the problem, thank you.
Thank you for testing. I'll commit it later.
Excellent! What about
Hi,
On Fri, 24 Feb 2006 15:51:53 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti Excellent! What about RES_DFLRETRY decreasing from 4 to 2? Does it need
rosti more testing or discussion?
It seems reasonable to me, and there are no objection here. So, I've
just committed both into HEAD.
On Sat, Feb 25, 2006 at 02:08:21AM +0900, Hajimu UMEMOTO wrote:
On Fri, 24 Feb 2006 15:51:53 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti Excellent! What about RES_DFLRETRY decreasing from 4 to 2? Does it need
rosti more testing or discussion?
It seems reasonable to me, and
On Fri, 24 Feb 2006 20:40:07 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
To Rostislav: Could you do now, with the resolver fixes applied,
the following experiment: find how many dead nameservers in resolv.conf
it takes for sshd to start timing out a connection to it? There
is still your PR
Hi,
On Sat, 25 Feb 2006 02:42:46 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
rosti getaddrinfo() is called in two places with hints.ai_socktype == 0 and
rosti hints.ai_family == PF_UNSPEC. In the ftp(1) a command
On Thu, 23 Feb 2006 02:08:17 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Wed, 22 Feb 2006 02:44:30 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti On Tue, 21 Feb 2006 19:59:59 +0300
rosti Yar Tikhiy [EMAIL PROTECTED] wrote:
rosti I forgot that a search resolver(5)
Hi,
On Thu, 23 Feb 2006 23:57:27 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti Your patch fixed the problem, thank you.
Thank you for testing. I'll commit it later.
rosti But during my tests I've found
rosti another form of doubling bug in getaddrinfo(). To test the
getaddrinfo()
* Atanas [EMAIL PROTECTED]:
I really miss the inetd features. A setting like nowait/100/20/5
(/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]])
would effectively bounce the bad guys, but AFAIK (correct me if I'm
wrong), ssh is no longer supposed to work via inetd and still
Hi,
On Wed, 22 Feb 2006 02:44:30 +0200
Rostislav Krasny [EMAIL PROTECTED] said:
rosti On Tue, 21 Feb 2006 19:59:59 +0300
rosti Yar Tikhiy [EMAIL PROTECTED] wrote:
rosti I forgot that a search resolver(5) parameter is useless for reverse
rosti resolving. But that doubling of name-IP requests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hej there,
Atanas wrote:
Dag-Erling Smørgrav said the following on 02/15/06 23:35:
David Malone [EMAIL PROTECTED] writes:
Last year I already had to decrease the LoginGraceTime from 120 to 30
seconds on my production boxes, but it didn't help
On Sun, Feb 19, 2006 at 10:57:01PM +0200, Rostislav Krasny wrote:
On Sun, 19 Feb 2006 13:49:12 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote:
On Thu, 16 Feb 2006 08:35:18 +0100
[EMAIL PROTECTED] (Dag-Erling Sm??rgrav) wrote:
On Tue, 21 Feb 2006 19:59:59 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
On Sun, Feb 19, 2006 at 10:57:01PM +0200, Rostislav Krasny wrote:
On Sun, 19 Feb 2006 13:49:12 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:
On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote:
On Thu,
On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote:
On Thu, 16 Feb 2006 08:35:18 +0100
[EMAIL PROTECTED] (Dag-Erling Sm??rgrav) wrote:
David Malone [EMAIL PROTECTED] writes:
I did once mail des@ to ask him if he'd mind me changing the default
login timeout for sshd to be
Carl Makin said the following on 02/16/06 20:07:
Atanas wrote:
Does anybody know whether ipfw (or something else within FreeBSD-4) is
capable of setting connection rate limits?
I'm using SEC to monitor the auth.log file and block any IP addresses
that fail a password 3 times within 60
Marian Hettwer said the following on 02/17/06 00:39:
Atanas wrote:
Last year I already had to decrease the LoginGraceTime from 120 to 30
seconds on my production boxes, but it didn't help much, so on top of
that I got to implement (reinvent the wheel again) a script tailing the
auth.log and
At 09:17 PM 16/02/2006, Atanas wrote:
Does anybody know whether ipfw (or something else within FreeBSD-4)
is capable of setting connection rate limits?
Why not just launch sshd out of inetd ?
Start up inetd with -wWl -C 5
In inetd.conf
ssh stream tcp nowait root /usr/sbin/sshd
Mike Tancsa said the following on 02/17/06 11:50:
At 09:17 PM 16/02/2006, Atanas wrote:
Does anybody know whether ipfw (or something else within FreeBSD-4) is
capable of setting connection rate limits?
Why not just launch sshd out of inetd ?
Primarily because of the big scare sign in the
On Thu, 16 Feb 2006 08:35:18 +0100
[EMAIL PROTECTED] (Dag-Erling Smørgrav) wrote:
David Malone [EMAIL PROTECTED] writes:
I did once mail des@ to ask him if he'd mind me changing the default
login timeout for sshd to be (say) 5 minutes rather than 1 minute,
but I think he was busy at the
Rostislav Krasny [EMAIL PROTECTED] writes:
In conjunction to what David had proposed, what do you think about
decreasing the RES_DFLRETRY from 4 to 2, like in other systems and in
BIND9's resolver?
I have no opinion on that matter.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
Dag-Erling Smørgrav said the following on 02/15/06 23:35:
David Malone [EMAIL PROTECTED] writes:
I did once mail des@ to ask him if he'd mind me changing the default
login timeout for sshd to be (say) 5 minutes rather than 1 minute,
but I think he was busy at the time. Judging by the PR
Just a thought, wouldn't this open a new possibility for denial of
service attacks?
I doubt it. I'm guessing you're thinking of an attack where someone
makes many connections to sshd in a short time and runs you out of
processes? I think you can protect against this with the MaxStartups
Hello,
You should try Xinetd as it has more options to help with this. I beleive
you SSH problem is due to a DNS/RDNS problem.
Regards,
Chris
Just a thought, wouldn't this open a new possibility for denial of
service attacks?
I doubt it. I'm guessing you're thinking of an attack where
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Atanas wrote:
Dag-Erling Smørgrav said the following on 02/15/06 23:35:
David Malone [EMAIL PROTECTED] writes:
I did once mail des@ to ask him if he'd mind me changing the default
login timeout for sshd to be (say) 5 minutes rather than 1 minute,
David Malone said the following on 02/16/06 13:24:
Just a thought, wouldn't this open a new possibility for denial of
service attacks?
I doubt it. I'm guessing you're thinking of an attack where someone
makes many connections to sshd in a short time and runs you out of
processes? I think you
Niki Denev said the following on 02/16/06 16:11:
I solved this for me with the following pf(4) rule :
pass in quick on $ext inet proto tcp from any to any port ssh flags S/SA \
keep state (source-track rule, max-src-conn $max_conn_per_ip,
max-src-conn-rate $max_conn_rate, \
overload
[EMAIL PROTECTED] said the following on 02/16/06 14:49:
Hello,
You should try Xinetd as it has more options to help with this. I beleive
you SSH problem is due to a DNS/RDNS problem.
No, it wasn't a DNS issue. (x)inetd would help, but in such a case sshd
would need to generate a server key
Hi Atanas,
Atanas wrote:
Does anybody know whether ipfw (or something else within FreeBSD-4) is
capable of setting connection rate limits?
I'm using SEC to monitor the auth.log file and block any IP addresses
that fail a password 3 times within 60 seconds. I use the following
sec.conf
David Malone [EMAIL PROTECTED] writes:
I did once mail des@ to ask him if he'd mind me changing the default
login timeout for sshd to be (say) 5 minutes rather than 1 minute,
but I think he was busy at the time. Judging by the PR mentioned
above it should be at least 2m30s by default. Des,
On Sun, Dec 25, 2005 at 06:41:57PM +0200, Rostislav Krasny wrote:
defined as 4. In a case the DNS server isn't responding the
gethostbyname() makes 8 (eight!) reverse resolving attempts for one
(!) non-responding DNS server before it returns error. And this is by
default. All that is still
On 12/27/05, David Malone [EMAIL PROTECTED] wrote:
On Sun, Dec 25, 2005 at 06:41:57PM +0200, Rostislav Krasny wrote:
defined as 4. In a case the DNS server isn't responding the
gethostbyname() makes 8 (eight!) reverse resolving attempts for one
(!) non-responding DNS server before it
Lowell Gilbert wrote:
Marian Hettwer [EMAIL PROTECTED] writes:
alternativly to check out wether it's dns related, you use set the
Option UseDNS no in your sshd_config, so sshd won't try a reverse
dns lookup.
Give it a shoot. Usually ssh timeouts are related to DNS...
That should be a last
Hi,
I had submitted a bin/62139 PR because of the same problem about a
year ago. I still think there is a bug somewhere in a resolver(3)
library or in libc functions like gethostbyname(). Because of this bug
the gethostbyname() doubles the number of its reverse resolving
requests, in a case the
I wouldn't be surprised if there is actually more going on, their were
times before I entered my local network into my hosts file that
authentication would completely time out and drop the client. It
usually only happened when using my ISP's dns server and not my local
caching server, but still,
you can fake your IP and you can fake your hostname, but exactly for security
reasons, since we believe that beeing a a network admin is not because of
luck but knowledge, and we also believe that this person has a certain
responsibility and so he will probably not set up false dns reverse
Don't top-post, please.
James Tanis [EMAIL PROTECTED] writes:
On 23 Dec 2005 09:30:56 -0500, Lowell Gilbert
[EMAIL PROTECTED] wrote:
Marian Hettwer [EMAIL PROTECTED] writes:
Hej there,
Kobi Shmueli wrote:
Try checking /etc/resolv.conf on oboe first, adding a static entry to
All,
I have three machines that have had 5.4 and 6.0 installed. Two of the three
machines have very
well behaved ssh. However, the machine (laptop) named OBOE does not.
Specifically ssh oboe will (most of the time) hang for around one minute
before asking for a
prompt. However, if I'm
On 12/23/05, Michael A. Koerber [EMAIL PROTECTED] wrote:
All,
I have three machines that have had 5.4 and 6.0 installed. Two of the
three machines have very
well behaved ssh. However, the machine (laptop) named OBOE does not.
Specifically ssh oboe will (most of the time) hang for
Michael A. Koerber wrote:
All,
I have three machines that have had 5.4 and 6.0 installed. Two of the three
machines have very
well behaved ssh. However, the machine (laptop) named OBOE does not.
Specifically ssh oboe will (most of the time) hang for around one minute
before asking for a
Michael A. Koerber wrote:
I have three machines that have had 5.4 and 6.0 installed. Two of the
three machines have very
well behaved ssh. However, the machine (laptop) named OBOE does not.
Specifically ssh oboe will (most of the time) hang for around one
minute before asking for a
Hej there,
Kobi Shmueli wrote:
Try checking /etc/resolv.conf on oboe first, adding a static entry to
/etc/hosts of the remote ip/host should speed dns checks as well.
You can also run ssh in verbose mode (ssh -v oboe) or/and run sshd in debug
mode (sshd -d).
alternativly to check out wether
Marian Hettwer [EMAIL PROTECTED] writes:
Hej there,
Kobi Shmueli wrote:
Try checking /etc/resolv.conf on oboe first, adding a static entry to
/etc/hosts of the remote ip/host should speed dns checks as well.
You can also run ssh in verbose mode (ssh -v oboe) or/and run sshd in debug
For whatever reason, I have had a similar problem which was solved by
entering the machines that you are logging in from into the hosts
file. I'm guessing it attempts a reverse lookup and your (as well as
my) dns/hostname does not match its reverse lookup entry.
On 12/23/05, Michael A. Koerber
What reason is that? A reverse-lookup is no longer really a valid way
of filtering out the undesireable unless your lucky enough to be
dealing only with those who have the knowledge and ability to control
those entries. Most residential ips either have no reverse-lookup or
it's set to some long
On Friday 23 December 2005 20:26, James Tanis wrote:
What reason is that? A reverse-lookup is no longer really a valid way
of filtering out the undesireable unless your lucky enough to be
dealing only with those who have the knowledge and ability to control
those entries. Most residential ips
65 matches
Mail list logo
