Re: SSH login takes very long time...sometimes
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 first, domain on the `search' list when the nameserver was down, yar which effectively led to another kind of request doubling. yar A similar effect was observed when a `domain' line was specified yar in resolv.conf in place of `search'. yar Is there a real reason to retry with a different domain when the yar nameserver doesn't respond at all? It seems yet another issue. The errors returned by res_querydomain() are not handled uniformity. Please try following patch: It works for me, thanks! -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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
rosti hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
rosti only 60 seconds. Those things are what I've changed to fix the problem.
rosti Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
rosti ftpd options. So if this patch is good, the ftpd(8) manual page and the
rosti default /etc/inetd.conf should also be changed appropriately.
For your ftpd.c.diff, I like your idea to reduce redundant query. It
is enough to query just appropriate address family. In inetd mode, we
know the address family already. So, we don't need to rely on the
-4/-6 option. The following diff is against ftpd.c with your patch
applied:
I finally tried the proposed patches for ftpd and really liked the
idea of reducing the name queries made to only one address family
if it's known. Thank you both!
I've got only one small remark on style, see below.
--- ftpd.c.rosti Sat Feb 25 15:41:52 2006
+++ ftpd.cSat Feb 25 16:01:46 2006
@@ -423,10 +423,6 @@ main(int argc, char *argv[], char **envp
}
}
-#ifdef VIRTUAL_HOSTING
- inithosts(family);
-#endif
-
if (daemon_mode) {
int *ctl_sock, fd, maxfd = -1, nfds, i;
fd_set defreadfds, readfds;
@@ -456,6 +452,10 @@ main(int argc, char *argv[], char **envp
sa.sa_handler = reapchild;
(void)sigaction(SIGCHLD, sa, NULL);
+#ifdef VIRTUAL_HOSTING
+ inithosts(family);
+#endif
+
/*
* Open a socket, bind it to the FTP port, and start
* listening.
@@ -525,6 +525,14 @@ main(int argc, char *argv[], char **envp
syslog(LOG_ERR, getpeername (%s): %m,argv[0]);
exit(1);
}
+
+#ifdef VIRTUAL_HOSTING
+ family = his_addr.su_family;
+ if (his_addr.su_family == AF_INET6
+ IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
+ family = AF_INET;
Perheps a better style here would be to use if/else:
if (his_addr.su_family == AF_INET6
IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
family = AF_INET;
else
family = his_addr.su_family;
+ inithosts(family);
+#endif
}
gotchild:
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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
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 reply timeout
is
rosti only 60 seconds. Those things are what I've changed to fix the
problem.
rosti Two diffs are attached to this email. The ftpd.c.diff extends -4 and
-6
rosti ftpd options. So if this patch is good, the ftpd(8) manual page and
the
rosti default /etc/inetd.conf should also be changed appropriately.
For your ftpd.c.diff, I like your idea to reduce redundant query. It
is enough to query just appropriate address family. In inetd mode, we
know the address family already. So, we don't need to rely on the
-4/-6 option. The following diff is against ftpd.c with your patch
applied:
I finally tried the proposed patches for ftpd and really liked the
idea of reducing the name queries made to only one address family
if it's known. Thank you both!
I've got only one small remark on style, see below.
--- ftpd.c.rostiSat Feb 25 15:41:52 2006
+++ ftpd.c Sat Feb 25 16:01:46 2006
@@ -423,10 +423,6 @@ main(int argc, char *argv[], char **envp
}
}
-#ifdef VIRTUAL_HOSTING
- inithosts(family);
-#endif
-
if (daemon_mode) {
int *ctl_sock, fd, maxfd = -1, nfds, i;
fd_set defreadfds, readfds;
@@ -456,6 +452,10 @@ main(int argc, char *argv[], char **envp
sa.sa_handler = reapchild;
(void)sigaction(SIGCHLD, sa, NULL);
+#ifdef VIRTUAL_HOSTING
+ inithosts(family);
+#endif
+
/*
* Open a socket, bind it to the FTP port, and start
* listening.
@@ -525,6 +525,14 @@ main(int argc, char *argv[], char **envp
syslog(LOG_ERR, getpeername (%s): %m,argv[0]);
exit(1);
}
+
+#ifdef VIRTUAL_HOSTING
+ family = his_addr.su_family;
+ if (his_addr.su_family == AF_INET6
+ IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
+ family = AF_INET;
Perheps a better style here would be to use if/else:
if (his_addr.su_family == AF_INET6
IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
family = AF_INET;
else
family = his_addr.su_family;
+ inithosts(family);
Or even shorter:
if (his_addr.su_family == AF_INET6
IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
inithosts(AF_INET);
else
inithosts(his_addr.su_family);
The 'family' variable isn't used in the inetd mode.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 I've got only one small remark on style, see below. Ah, yes. I had already changed to so locally. :-) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 effectively led to another kind of request doubling.
yar A similar effect was observed when a `domain' line was specified
yar in resolv.conf in place of `search'.
yar Is there a real reason to retry with a different domain when the
yar nameserver doesn't respond at all?
It seems yet another issue. The errors returned by res_querydomain()
are not handled uniformity. Please try following patch:
Index: lib/libc/net/getaddrinfo.c
diff -u -p lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c
--- lib/libc/net/getaddrinfo.c.orig Sun Feb 26 16:04:41 2006
+++ lib/libc/net/getaddrinfo.c Tue Feb 28 16:21:15 2006
@@ -2440,6 +2440,17 @@ res_searchN(name, target)
ret = res_querydomainN(name, NULL, target);
if (ret 0 || trailing_dot)
return (ret);
+ if (errno == ECONNREFUSED) {
+ h_errno = TRY_AGAIN;
+ return (-1);
+ }
+ switch (h_errno) {
+ case NO_DATA:
+ case HOST_NOT_FOUND:
+ break;
+ default:
+ return (-1);
+ }
saved_herrno = h_errno;
tried_as_is++;
}
@@ -2515,6 +2526,14 @@ res_searchN(name, target)
}
}
+ switch (h_errno) {
+ case NO_DATA:
+ case HOST_NOT_FOUND:
+ break;
+ default:
+ goto giveup;
+ }
+
/*
* If the query has not already been tried as is then try it
* unless RES_NOTLDQUERY is set and there were no dots.
@@ -2534,6 +2553,7 @@ res_searchN(name, target)
* else send back meaningless h_errno, that being the one from
* the last DNSRCH we did.
*/
+giveup:
if (saved_herrno != -1)
h_errno = saved_herrno;
else if (got_nodata)
Index: lib/libc/net/res_query.c
diff -u -p lib/libc/net/res_query.c.orig lib/libc/net/res_query.c
--- lib/libc/net/res_query.c.orig Sun Feb 26 16:04:41 2006
+++ lib/libc/net/res_query.cTue Feb 28 16:14:23 2006
@@ -229,6 +229,17 @@ res_search(name, class, type, answer, an
ret = res_querydomain(name, NULL, class, type, answer, anslen);
if (ret 0 || trailing_dot)
return (ret);
+ if (errno == ECONNREFUSED) {
+ h_errno = TRY_AGAIN;
+ return (-1);
+ }
+ switch (h_errno) {
+ case NO_DATA:
+ case HOST_NOT_FOUND:
+ break;
+ default:
+ return (-1);
+ }
saved_herrno = h_errno;
tried_as_is++;
}
@@ -318,6 +329,14 @@ res_search(name, class, type, answer, an
}
}
+ switch (h_errno) {
+ case NO_DATA:
+ case HOST_NOT_FOUND:
+ break;
+ default:
+ goto giveup;
+ }
+
/*
* If the query has not already been tried as is then try it
* unless RES_NOTLDQUERY is set and there were no dots.
@@ -336,6 +355,7 @@ res_search(name, class, type, answer, an
* else send back meaningless h_errno, that being the one from
* the last DNSRCH we did.
*/
+giveup:
if (saved_herrno != -1)
h_errno = saved_herrno;
else if (got_nodata)
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 the yar first, domain on the `search' list when the nameserver was down, yar which effectively led to another kind of request doubling. yar A similar effect was observed when a `domain' line was specified yar in resolv.conf in place of `search'. yar Is there a real reason to retry with a different domain when the yar nameserver doesn't respond at all? It seems yet another issue. The errors returned by res_querydomain() are not handled uniformity. Please try following patch: Thank you! After applaying that additional patch a number of DNS queries to unreachable name servers has decreased. Now, with three unreachable name servers in resolv.conf and previously patched (my and your patches) ftpd(8), I can successfully login to this machine by even not patched ftp(1) from other FreeBSD 6.1-pre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 there are no objection here. So, I've
just committed both into HEAD.
I finally spared some time to test your recent changes and found
that the resolver still would retry using the first, and only the
first, domain on the `search' list when the nameserver was down,
which effectively led to another kind of request doubling.
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?
--
Yar
P.S. Here's the details of what I'm talking about:
Commands:
vpc7# hostname
vpc7
vpc7# cat /etc/resolv.conf
search aaa.ru bbb.ru
nameserver 195.208.208.25
vpc7# ./gethost foo
foo: Host name lookup failure
vpc7# ./gethost foo.zzz.ru
foo.zzz.ru: Host name lookup failure
tcpdump:
=== for ./gethost foo ===
18:01:51.756764 IP 10.1.1.27.51030 195.208.208.25.53: 5443+ A? foo.aaa.ru.
(33)
18:01:56.971187 IP 10.1.1.27.57913 195.208.208.25.53: 5443+ A? foo.aaa.ru.
(33)
18:02:07.071088 IP 10.1.1.27.55508 195.208.208.25.53: 5444+ A? foo. (21)
18:02:12.210384 IP 10.1.1.27.62824 195.208.208.25.53: 5444+ A? foo. (21)
=== for ./gethost foo.zzz.ru ===
18:02:33.509361 IP 10.1.1.27.65031 195.208.208.25.53: 19867+ A?
foo.zzz.ru. (32)
18:02:38.567045 IP 10.1.1.27.55358 195.208.208.25.53: 19867+ A?
foo.zzz.ru. (32)
18:02:48.824136 IP 10.1.1.27.61855 195.208.208.25.53: 19868+ A?
foo.zzz.ru.aaa.ru. (44)
18:02:53.922071 IP 10.1.1.27.49351 195.208.208.25.53: 19868+ A?
foo.zzz.ru.aaa.ru. (44)
Here's ./gethost src. It essentially calls a single gethostbyname()
if given a host name or gethostbyaddr() if given an IP address.
=== gethost.c ===
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include stdio.h
int
main(int argc, char **argv)
{
struct in_addr ia;
struct hostent *hp;
char *name;
char **st;
if (argc 2)
return (2);
name = argv[1];
if (inet_aton(name, ia))
hp = gethostbyaddr((char *)ia, sizeof(ia), AF_INET);
else
hp = gethostbyname(name);
if (hp == NULL) {
herror(name);
return (1);
}
printf(%s\n, hp-h_name);
for (st = hp-h_addr_list; *st; st++)
printf(%s\n, inet_ntoa(*(struct in_addr *)*st));
if (st == hp-h_addr_list)
printf(no address records\n);
return (0);
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 that the client resolver library is willing to wait; the fact that a nameserver didn't answer once isn't a sure sign that it won't answer other questions, or even that it won't answer the same question if you just wait a minute. On the other hand, if you make 100 queries and not hear anything back, perhaps it would be useful to log that information and possibly take action. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 it may take a nameserver longer to respond that the client resolver library is willing to wait; the fact that a nameserver didn't answer once isn't a sure sign that it won't answer other questions, or even that it won't answer the same question if you just wait a minute. Trying different domains isn't intended for fighting against UDP packets loss. To fight against UDP packets loss you have RES_DFLRETRY or options attempts:N retries of the same query. RES_DFLRETRY is defined in resolv.h and options attempts:N is optional parameter of /etc/resolv.conf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 their addresses and compares the rosti.bsd addresses to a local address of connected socket. This way it tries to rosti.bsd find - configuration of what virtual host should be used. There is an rosti.bsd additional comparison that seems like a workaround for misconfigured rosti.bsd virtual host that can be resolved only to IPv4 address and should be rosti.bsd used on IPv4-mapped IPv6 address. If virtual hosts are properly rosti.bsd configured that hack is not needed, IMHO. If you nuke this workaround from both selecthost() and my patch, you need to specify a native IPv4 address and/or an IPv4-mapped IPv6 address into ftphosts appropriately. It will confuse users. So, it is requierd. It will require to specify a virtual host for each address or to use hostname with multiple addresses only once. Specifying a virtual host by a hostname and registering multiple hostname's addresses in /etc/hosts should not be confusing, IMHO. If the addresses are already registered on DNS, the work is even simpler. Even specifying virtual hosts by addresses should not be confusing, because IPv4-mapped IPv6 address and the IPv4-mapped itself are certainly not the same, although they are mapped each to other. Indeed, someone could want to specify different virtual ftp hosts for IPv4 and mapped to it IPv6 addresses. For example to use different motd, welcome or statfile files. rosti.bsd Anyway selecthost() is called with local socket name and it checks a rosti.bsd local address, while his_addr.su_sin6.sin6_addr is a remote address. rosti.bsd Local and remote hosts have same address families but not same rosti.bsd addresses. The his_addr is referred to determine just an address family, here. When a remote address is an IPv4-mapped IPv6 address, a local address is as well. So, it should be okay. When a remote address is an IPv4-mapped IPv6 address, why the local IPv6 address must be of the same type and cannot be any regular IPv6 address? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 addresses in /etc/hosts rosti should not be confusing, IMHO. If the addresses are already registered rosti on DNS, the work is even simpler. rosti Even specifying virtual hosts by addresses should not be confusing, rosti because IPv4-mapped IPv6 address and the IPv4-mapped itself are rosti certainly not the same, although they are mapped each to other. Indeed, rosti someone could want to specify different virtual ftp hosts for IPv4 and rosti mapped to it IPv6 addresses. For example to use different motd, welcome rosti or statfile files. Then, you are already confused. rosti When a remote address is an IPv4-mapped IPv6 address, why the local IPv6 rosti address must be of the same type and cannot be any regular IPv6 address? Because, the connection uses an IPv4 to communicate with each other. There is two representation for one IPv4 address; native IPv4 address and an IPv4-mapped IPv6 address. It is thorny thing. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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. Specifying a virtual host by rosti a hostname and registering multiple hostname's addresses in /etc/hosts rosti should not be confusing, IMHO. If the addresses are already registered rosti on DNS, the work is even simpler. rosti Even specifying virtual hosts by addresses should not be confusing, rosti because IPv4-mapped IPv6 address and the IPv4-mapped itself are rosti certainly not the same, although they are mapped each to other. Indeed, rosti someone could want to specify different virtual ftp hosts for IPv4 and rosti mapped to it IPv6 addresses. For example to use different motd, welcome rosti or statfile files. Then, you are already confused. rosti When a remote address is an IPv4-mapped IPv6 address, why the local IPv6 rosti address must be of the same type and cannot be any regular IPv6 address? Because, the connection uses an IPv4 to communicate with each other. There is two representation for one IPv4 address; native IPv4 address and an IPv4-mapped IPv6 address. It is thorny thing. You may be right and I'm confused. I don't have much experience with IPv6. I just thought that any unicast IPv6 host, even IPv4-mapped IPv6 host, can communicate with any other unicast IPv6 host, including non-IPv4-mapped IPv6 host. Could you please suggest a good comprehensive article on the Web about IPv4-mapped IPv6 addresses and their usage? By the way, why you don't do the address type test in a daemon mode of ftpd? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 addition, you should read RFC 4038: http://www.ietf.org/rfc/rfc4038.txt?number=4038 rosti By the way, why you don't do the address type test in a rosti daemon mode of ftpd? Because, ftpd(8) in daemon mode doesn't accept an IPv4 using an IPv4-mapped IPv6 address by issuing the IPV6_V6ONLY socket option. Please refer socksetup(). In inetd mode, enable/disable use of an IPv4-mapped IPv6 address is depending on how to configure inetd.conf. So, we need to pay attention to an IPv4-mapped IPv6 address in inetd mode. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 people normally try to put usable resolvers into /etc/resolv.conf. However, it's reasonably common that some sort of network problem like a downed network link, firewall, or router would cause all non-local nameservers to become unreachable. It would be nice if local ftp still worked OK if the local machines were in /etc/hosts or otherwise resolvable (YP/NIS? multicast DNS? NetBIOS naming?)... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 sshd to start timing out a connection to it? There
is still your PR open on this issue, so we should see whether
the default for LoginGraceTime needs a change, too. Thanks!
The maximum number of name servers those the resolver will work with is
MAXNS, which currently is 3. With three unreachable name servers in
resolv.conf I successfully connected from other, not patched, FreeBSD
6.1-PRERELEASE by ssh without touching LoginGraceTime. I've got the
password prompt after about 48.5 seconds, according to a stop watch in
my cell phone :-)
I also tested telnet connection and it worked properly in that
situation.
Sounds good! Thanks!
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 problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
getaddrinfo() is called in two places with hints.ai_socktype == 0 and
hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
only 60 seconds. Those things are what I've changed to fix the problem.
Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
ftpd options. So if this patch is good, the ftpd(8) manual page and the
default /etc/inetd.conf should also be changed appropriately.
Could you explain please how your patch would affect ftpd(8) semantics
visible to the user?
Although I changed two getaddrinfo() calls in ftpd.c, only first of
them is really called on default FreeBSD configuration,
when /etc/ftphosts isn't existing yet. So there might be a need of
additional increase of the command reply timeout in ftp.c. Or better if
this timeout could be configurable by some new ftp(1) option, with 120
seconds by default.
--- libexec/ftpd/ftpd.c.orig Wed Feb 8 18:54:05 2006
+++ libexec/ftpd/ftpd.c Sat Feb 25 00:30:26 2006
@@ -239,7 +239,7 @@
}
#ifdef VIRTUAL_HOSTING
-static void inithosts(void);
+static void inithosts(int);
static void selecthost(union sockunion *);
#endif
static void ack(char *);
@@ -424,7 +424,7 @@
}
#ifdef VIRTUAL_HOSTING
- inithosts();
+ inithosts(family);
#endif
if (daemon_mode) {
@@ -663,7 +663,7 @@
*/
static void
-inithosts(void)
+inithosts(int family)
{
int insert;
size_t len;
@@ -689,7 +689,8 @@
memset(hints, 0, sizeof(hints));
hints.ai_flags = AI_CANONNAME;
- hints.ai_family = AF_UNSPEC;
+ hints.ai_family = family;
+ hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(hrp-hostname, NULL, hints, res) == 0)
hrp-hostinfo = res;
hrp-statfile = _PATH_FTPDSTATFILE;
@@ -759,9 +760,10 @@
/* NOTREACHED */
}
- 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 this comment here.
hints.ai_flags = AI_PASSIVE;
+ hints.ai_family = family;
+ hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(vhost, NULL, hints, res) != 0)
goto nextline;
for (ai = res; ai != NULL ai-ai_addr != NULL;
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 hints.ai_socktype == 0 and
rosti hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
rosti only 60 seconds. Those things are what I've changed to fix the problem.
rosti Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
rosti ftpd options. So if this patch is good, the ftpd(8) manual page and the
rosti default /etc/inetd.conf should also be changed appropriately.
For your ftpd.c.diff, I like your idea to reduce redundant query. It
is enough to query just appropriate address family. In inetd mode, we
know the address family already. So, we don't need to rely on the
-4/-6 option. The following diff is against ftpd.c with your patch
applied:
--- ftpd.c.rosti Sat Feb 25 15:41:52 2006
+++ ftpd.cSat Feb 25 16:01:46 2006
@@ -423,10 +423,6 @@ main(int argc, char *argv[], char **envp
}
}
-#ifdef VIRTUAL_HOSTING
- inithosts(family);
-#endif
-
if (daemon_mode) {
int *ctl_sock, fd, maxfd = -1, nfds, i;
fd_set defreadfds, readfds;
@@ -456,6 +452,10 @@ main(int argc, char *argv[], char **envp
sa.sa_handler = reapchild;
(void)sigaction(SIGCHLD, sa, NULL);
+#ifdef VIRTUAL_HOSTING
+ inithosts(family);
+#endif
+
/*
* Open a socket, bind it to the FTP port, and start
* listening.
@@ -525,6 +525,14 @@ main(int argc, char *argv[], char **envp
syslog(LOG_ERR, getpeername (%s): %m,argv[0]);
exit(1);
}
+
+#ifdef VIRTUAL_HOSTING
+ family = his_addr.su_family;
+ if (his_addr.su_family == AF_INET6
+ IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
+ family = AF_INET;
+ inithosts(family);
+#endif
}
gotchild:
family = his_addr.su_family; is really a good idea. But what is the
reason to check if IPv6 address of a remote client is IPv4 mapped and
assign AF_INET to a 'family' when that's true? The inithosts() doesn't
lookup for that address but for the server's hostname and optionally
virtual server's hostnames from /etc/ftphosts. I think it's unnecessary
and can even produce problems. IMHO inithosts(family); could be
called right after the family = his_addr.su_family; line.
For ftp.c.diff, how about considering adding new option for timeout?
That was what I thought about when wrote my previous email. What name
could be good for that option? Is -c seconds (ftp Command reply
timeout in seconds) a good one?
However, I'm still in doubt. I cannot think it is usual situation
that there are unreachable IP addresses in /etc/resolv.conf.
It is unusual situation but it can happen. Otherwise this duscussion
was not started.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
getaddrinfo() is called in two places with hints.ai_socktype == 0 and
hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
only 60 seconds. Those things are what I've changed to fix the problem.
Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
ftpd options. So if this patch is good, the ftpd(8) manual page and the
default /etc/inetd.conf should also be changed appropriately.
Could you explain please how your patch would affect ftpd(8) semantics
visible to the user?
ftpd(8) has -4 and -6 options, which originally are used in daemon mode
only. With my patch they are used in inetd mode too. But Hajimu showed
me that in the inetd mode the 'family' variable could be assigned
according to remote client's address family. Please read my recent reply
to his email.
Although I changed two getaddrinfo() calls in ftpd.c, only first of
them is really called on default FreeBSD configuration,
when /etc/ftphosts isn't existing yet. So there might be a need of
additional increase of the command reply timeout in ftp.c. Or better if
this timeout could be configurable by some new ftp(1) option, with 120
seconds by default.
--- libexec/ftpd/ftpd.c.origWed Feb 8 18:54:05 2006
+++ libexec/ftpd/ftpd.c Sat Feb 25 00:30:26 2006
@@ -239,7 +239,7 @@
}
#ifdef VIRTUAL_HOSTING
-static void inithosts(void);
+static void inithosts(int);
static void selecthost(union sockunion *);
#endif
static void ack(char *);
@@ -424,7 +424,7 @@
}
#ifdef VIRTUAL_HOSTING
- inithosts();
+ inithosts(family);
#endif
if (daemon_mode) {
@@ -663,7 +663,7 @@
*/
static void
-inithosts(void)
+inithosts(int family)
{
int insert;
size_t len;
@@ -689,7 +689,8 @@
memset(hints, 0, sizeof(hints));
hints.ai_flags = AI_CANONNAME;
- hints.ai_family = AF_UNSPEC;
+ hints.ai_family = family;
+ hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(hrp-hostname, NULL, hints, res) == 0)
hrp-hostinfo = res;
hrp-statfile = _PATH_FTPDSTATFILE;
@@ -759,9 +760,10 @@
/* NOTREACHED */
}
- 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 this comment here.
The original code looked like that:
hints.ai_flags = 0;
hints.ai_family = AF_UNSPEC;
hints.ai_flags = AI_PASSIVE;
It looked like someone wanted to say to future developers: if you don't
whant hints.ai_flags = AI_PASSIVE keep the hints.ai_flags = 0.
My comment might be not well formulated or even unnecessary, sorry.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 inithosts() doesn't rosti lookup for that address but for the server's hostname and optionally rosti virtual server's hostnames from /etc/ftphosts. I think it's unnecessary rosti and can even produce problems. IMHO inithosts(family); could be rosti called right after the family = his_addr.su_family; line. No, when a local address of a connection is an IPv4-mapped IPv6 address, selecthost() does test it as a native IPv4 address. So, we need to lookup hostnames as an IPv4 in inithosts(). Please refer selecthost() for detail. For ftp.c.diff, how about considering adding new option for timeout? rosti That was what I thought about when wrote my previous email. What name rosti could be good for that option? Is -c seconds (ftp Command reply rosti timeout in seconds) a good one? I have no idea for now, but ftp(1) is a contrib software from NetBSD. So, we need to discuss with the author of lukemftp. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 this comment here. rosti The original code looked like that: rosti hints.ai_flags = 0; rosti hints.ai_family = AF_UNSPEC; rosti hints.ai_flags = AI_PASSIVE; rosti It looked like someone wanted to say to future developers: if you don't rosti whant hints.ai_flags = AI_PASSIVE keep the hints.ai_flags = 0. rosti My comment might be not well formulated or even unnecessary, sorry. I think it was just a bug. So, we can just nuke this comment. BTW, AI_CANONNAME is set to hints.ai_flags and AI_PASSIVE is not set, just before the getaddrinfo(3) call above like following: hints.ai_flags = AI_CANONNAME; hints.ai_family = family; hints.ai_socktype = SOCK_STREAM; Since ai_canonname is not used later, we don't need to set AI_CANONNAME, here. And, in this usage of getaddrinfo(3), we should set AI_PASSIVE. So, it should be same as lookup for ftphosts like following: hints.ai_flags = AI_PASSIVE; hints.ai_family = family; hints.ai_socktype = SOCK_STREAM; Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 is IPv4 mapped and rosti assign AF_INET to a 'family' when that's true? The inithosts() doesn't rosti lookup for that address but for the server's hostname and optionally rosti virtual server's hostnames from /etc/ftphosts. I think it's unnecessary rosti and can even produce problems. IMHO inithosts(family); could be rosti called right after the family = his_addr.su_family; line. No, when a local address of a connection is an IPv4-mapped IPv6 address, selecthost() does test it as a native IPv4 address. So, we need to lookup hostnames as an IPv4 in inithosts(). Please refer selecthost() for detail. As far as I understand the code of selecthost() it walks through linked lists of known virtual hosts and their addresses and compares the addresses to a local address of connected socket. This way it tries to find - configuration of what virtual host should be used. There is an additional comparison that seems like a workaround for misconfigured virtual host that can be resolved only to IPv4 address and should be used on IPv4-mapped IPv6 address. If virtual hosts are properly configured that hack is not needed, IMHO. Anyway selecthost() is called with local socket name and it checks a local address, while his_addr.su_sin6.sin6_addr is a remote address. Local and remote hosts have same address families but not same addresses. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 socket. This way it tries to rosti.bsd find - configuration of what virtual host should be used. There is an rosti.bsd additional comparison that seems like a workaround for misconfigured rosti.bsd virtual host that can be resolved only to IPv4 address and should be rosti.bsd used on IPv4-mapped IPv6 address. If virtual hosts are properly rosti.bsd configured that hack is not needed, IMHO. If you nuke this workaround from both selecthost() and my patch, you need to specify a native IPv4 address and/or an IPv4-mapped IPv6 address into ftphosts appropriately. It will confuse users. So, it is requierd. rosti.bsd Anyway selecthost() is called with local socket name and it checks a rosti.bsd local address, while his_addr.su_sin6.sin6_addr is a remote address. rosti.bsd Local and remote hosts have same address families but not same rosti.bsd addresses. The his_addr is referred to determine just an address family, here. When a remote address is an IPv4-mapped IPv6 address, a local address is as well. So, it should be okay. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 RES_DFLRETRY decreasing from 4 to 2? Does it need more testing or discussion? rosti But during my tests I've found rosti another form of doubling bug in getaddrinfo(). To test the getaddrinfo() rosti behavior I used a program that is attached to this email. rosti If hints.ai_socktype == 0 then the getaddrinfo() does the lookup twice, rosti even if DNS is reachable. If the latter is the case, returned linked rosti list is twice as large than it should be. The hints.ai_socktype seems rosti to have the same influence when hints.ai_family is PF_INET6 or rosti PF_UNSPEC too. No, it is expected behavior of getaddrinfo(3). If hints.ai_socktype is zero, getaddrinfo(3) returns the entries for all available socktypes. Though getaddrinfo(3) returns doubled linkd list, getaddrinfo(3) does DNS lookup just once for all. If you don't want it, you need to specify appropriate socktype explicitly. Ok. It was just not clear when I read the manual and saw, by tcpdump, two for example 'A? yahoo.com.' requests to a reachable DNS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 there are no objection here. So, I've just committed both into HEAD. IMHO the only principal reservation about changing RES_DFLRETRY was that its effect was unobvious due to the bug you've just fixed. Now all should be OK. Thank you a lot! 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 open on this issue, so we should see whether the default for LoginGraceTime needs a change, too. Thanks! -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 open on this issue, so we should see whether
the default for LoginGraceTime needs a change, too. Thanks!
The maximum number of name servers those the resolver will work with is
MAXNS, which currently is 3. With three unreachable name servers in
resolv.conf I successfully connected from other, not patched, FreeBSD
6.1-PRERELEASE by ssh without touching LoginGraceTime. I've got the
password prompt after about 48.5 seconds, according to a stop watch in
my cell phone :-)
I also tested telnet connection and it worked properly in that
situation.
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 problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
getaddrinfo() is called in two places with hints.ai_socktype == 0 and
hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
only 60 seconds. Those things are what I've changed to fix the problem.
Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
ftpd options. So if this patch is good, the ftpd(8) manual page and the
default /etc/inetd.conf should also be changed appropriately.
Although I changed two getaddrinfo() calls in ftpd.c, only first of
them is really called on default FreeBSD configuration,
when /etc/ftphosts isn't existing yet. So there might be a need of
additional increase of the command reply timeout in ftp.c. Or better if
this timeout could be configurable by some new ftp(1) option, with 120
seconds by default.
--- libexec/ftpd/ftpd.c.origWed Feb 8 18:54:05 2006
+++ libexec/ftpd/ftpd.c Sat Feb 25 00:30:26 2006
@@ -239,7 +239,7 @@
}
#ifdef VIRTUAL_HOSTING
-static void inithosts(void);
+static void inithosts(int);
static void selecthost(union sockunion *);
#endif
static void ack(char *);
@@ -424,7 +424,7 @@
}
#ifdef VIRTUAL_HOSTING
- inithosts();
+ inithosts(family);
#endif
if (daemon_mode) {
@@ -663,7 +663,7 @@
*/
static void
-inithosts(void)
+inithosts(int family)
{
int insert;
size_t len;
@@ -689,7 +689,8 @@
memset(hints, 0, sizeof(hints));
hints.ai_flags = AI_CANONNAME;
- hints.ai_family = AF_UNSPEC;
+ hints.ai_family = family;
+ hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(hrp-hostname, NULL, hints, res) == 0)
hrp-hostinfo = res;
hrp-statfile = _PATH_FTPDSTATFILE;
@@ -759,9 +760,10 @@
/* NOTREACHED */
}
- hints.ai_flags = 0;
- hints.ai_family = AF_UNSPEC;
+ /* If no flag, assign hints.ai_flags to zero! */
hints.ai_flags = AI_PASSIVE;
+ hints.ai_family = family;
+ hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(vhost, NULL, hints, res) != 0)
goto nextline;
for (ai = res; ai != NULL ai-ai_addr != NULL;
--- contrib/lukemftp/src/ftp.c.orig Tue May 17 06:11:25 2005
+++ contrib/lukemftp/src/ftp.c Sat Feb 25 01:42:19 2006
@@ -406,7 +406,7 @@
for (line = 0 ;; line++) {
dig = n = code = 0;
cp = current_line;
- while (alarmtimer(60),((c = getc(cin)) != '\n')) {
+ while (alarmtimer(120),((c = getc(cin)) != '\n')) {
if (c == IAC) { /* handle telnet commands */
switch (c = getc(cin)) {
case WILL:
@@ -447,7 +447,7 @@
if (verbose) {
if (reply_timeoutflag)
fputs(
-421 Service not available, remote server timed out. Connection closed\n,
+421 Service not available, remote server timed out. Connection closed.\n,
ttyout);
else if (reply_abrtflag)
fputs(
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 reply timeout is
rosti only 60 seconds. Those things are what I've changed to fix the problem.
rosti Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
rosti ftpd options. So if this patch is good, the ftpd(8) manual page and the
rosti default /etc/inetd.conf should also be changed appropriately.
For your ftpd.c.diff, I like your idea to reduce redundant query. It
is enough to query just appropriate address family. In inetd mode, we
know the address family already. So, we don't need to rely on the
-4/-6 option. The following diff is against ftpd.c with your patch
applied:
--- ftpd.c.rostiSat Feb 25 15:41:52 2006
+++ ftpd.c Sat Feb 25 16:01:46 2006
@@ -423,10 +423,6 @@ main(int argc, char *argv[], char **envp
}
}
-#ifdef VIRTUAL_HOSTING
- inithosts(family);
-#endif
-
if (daemon_mode) {
int *ctl_sock, fd, maxfd = -1, nfds, i;
fd_set defreadfds, readfds;
@@ -456,6 +452,10 @@ main(int argc, char *argv[], char **envp
sa.sa_handler = reapchild;
(void)sigaction(SIGCHLD, sa, NULL);
+#ifdef VIRTUAL_HOSTING
+ inithosts(family);
+#endif
+
/*
* Open a socket, bind it to the FTP port, and start
* listening.
@@ -525,6 +525,14 @@ main(int argc, char *argv[], char **envp
syslog(LOG_ERR, getpeername (%s): %m,argv[0]);
exit(1);
}
+
+#ifdef VIRTUAL_HOSTING
+ family = his_addr.su_family;
+ if (his_addr.su_family == AF_INET6
+ IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
+ family = AF_INET;
+ inithosts(family);
+#endif
}
gotchild:
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.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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) parameter is useless for reverse rosti resolving. But that doubling of name-IP requests with an empty (or rosti root, according to resolver(5)) domain in the search is still a bug, rosti IMHO. Although it shouldn't affect the sshd. I looked BIND9's resolver, and took the related part into our resolver. However, it seems to me that there is still same issue in BIND9's resolver. So, I change more bit. Please try the following patch and let me know the result: Your patch fixed the problem, thank you. But during my tests I've found another form of doubling bug in getaddrinfo(). To test the getaddrinfo() behavior I used a program that is attached to this email. If hints.ai_socktype == 0 then the getaddrinfo() does the lookup twice, even if DNS is reachable. If the latter is the case, returned linked list is twice as large than it should be. The hints.ai_socktype seems to have the same influence when hints.ai_family is PF_INET6 or PF_UNSPEC too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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() rosti behavior I used a program that is attached to this email. rosti If hints.ai_socktype == 0 then the getaddrinfo() does the lookup twice, rosti even if DNS is reachable. If the latter is the case, returned linked rosti list is twice as large than it should be. The hints.ai_socktype seems rosti to have the same influence when hints.ai_family is PF_INET6 or rosti PF_UNSPEC too. No, it is expected behavior of getaddrinfo(3). If hints.ai_socktype is zero, getaddrinfo(3) returns the entries for all available socktypes. Though getaddrinfo(3) returns doubled linkd list, getaddrinfo(3) does DNS lookup just once for all. If you don't want it, you need to specify appropriate socktype explicitly. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
* 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 has no such capabilities. We're succesfully running openssh-portable from inetd with: ssh stream tcp nowait/0/12 root/usr/local/sbin/sshdsshd -i -f /etc/ssh/sshd_config [EMAIL PROTECTED] grep ssh /var/log/messages Feb 14 02:15:04 lambda inetd[19345]: ssh from 62.81.185.120 exceeded counts/min (limit 12/min) Feb 14 02:15:04 lambda inetd[19345]: ssh from 62.81.185.120 exceeded counts/min (limit 12/min) Feb 14 16:43:15 lambda inetd[19345]: ssh from 220.130.23.134 exceeded counts/min (limit 12/min) ... I'd also recommend pam_af for locking out brute-forcers: http://mbsd.msk.ru/pam_af.html For example we have: host hostname='tin.cn.ee.ccu.edu.tw' attempts9/attempts last_attemptMon Nov 7 15:05:50 2005/last_attempt statuslocked/status /host [EMAIL PROTECTED] sudo pam_af_tool statlist | grep locked | wc -l 363 Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME All the excitement lies in pattern matching. (SPJ et al.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 with an empty (or
rosti root, according to resolver(5)) domain in the search is still a bug,
rosti IMHO. Although it shouldn't affect the sshd.
I looked BIND9's resolver, and took the related part into our
resolver. However, it seems to me that there is still same issue in
BIND9's resolver. So, I change more bit. Please try the following
patch and let me know the result:
Index: lib/libc/net/getaddrinfo.c
diff -u -p lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c
--- lib/libc/net/getaddrinfo.c.orig Sat Jul 23 03:21:28 2005
+++ lib/libc/net/getaddrinfo.c Thu Feb 23 01:43:49 2006
@@ -2405,7 +2405,9 @@ res_searchN(name, target)
HEADER *hp = (HEADER *)(void *)target-answer; /*XXX*/
u_int dots;
int trailing_dot, ret, saved_herrno;
- int got_nodata = 0, got_servfail = 0, tried_as_is = 0;
+ int got_nodata = 0, got_servfail = 0, root_on_list = 0;
+ int tried_as_is = 0;
+ int searched = 0;
char abuf[MAXDNAME];
if ((_res.options RES_INIT) == 0 res_init() == -1) {
@@ -2429,13 +2431,14 @@ res_searchN(name, target)
return (res_queryN(cp, target));
/*
-* If there are dots in the name already, let's just give it a try
-* 'as is'. The threshold can be set with the ndots option.
+* If there are enough dots in the name, let's just give it a
+* try 'as is'. The threshold can be set with the ndots option.
+* Also, query 'as is', if there is a trailing dot in the name.
*/
saved_herrno = -1;
- if (dots = _res.ndots) {
+ if (dots = _res.ndots || trailing_dot) {
ret = res_querydomainN(name, NULL, target);
- if (ret 0)
+ if (ret 0 || trailing_dot)
return (ret);
saved_herrno = h_errno;
tried_as_is++;
@@ -2454,6 +2457,14 @@ res_searchN(name, target)
for (domain = (const char * const *)_res.dnsrch;
*domain !done;
domain++) {
+ searched = 1;
+
+ if (domain[0][0] == '\0' ||
+ (domain[0][0] == '.' domain[0][1] == '\0'))
+ root_on_list++;
+
+ if (root_on_list tried_as_is)
+ continue;
ret = res_querydomainN(name, *domain, target);
if (ret 0)
@@ -2505,11 +2516,11 @@ res_searchN(name, target)
}
/*
-* if we have not already tried the name as is, do that now.
-* note that we do this regardless of how many dots were in the
-* name or whether it ends with a dot.
+* If the query has not already been tried as is then try it
+* unless RES_NOTLDQUERY is set and there were no dots.
*/
- if (!tried_as_is (dots || !(_res.options RES_NOTLDQUERY))) {
+ if ((dots || !searched || !(_res.options RES_NOTLDQUERY))
+ !(tried_as_is || root_on_list)) {
ret = res_querydomainN(name, NULL, target);
if (ret 0)
return (ret);
Index: lib/libc/net/res_query.c
diff -u -p lib/libc/net/res_query.c.orig lib/libc/net/res_query.c
--- lib/libc/net/res_query.c.orig Fri Apr 15 23:42:29 2005
+++ lib/libc/net/res_query.cThu Feb 23 01:43:49 2006
@@ -198,7 +198,9 @@ res_search(name, class, type, answer, an
char tmp[MAXDNAME];
u_int dots;
int trailing_dot, ret, saved_herrno;
- int got_nodata = 0, got_servfail = 0, tried_as_is = 0;
+ int got_nodata = 0, got_servfail = 0, root_on_list = 0;
+ int tried_as_is = 0;
+ int searched = 0;
if ((_res.options RES_INIT) == 0 res_init() == -1) {
h_errno = NETDB_INTERNAL;
@@ -218,13 +220,14 @@ res_search(name, class, type, answer, an
return (res_query(cp, class, type, answer, anslen));
/*
-* If there are dots in the name already, let's just give it a try
-* 'as is'. The threshold can be set with the ndots option.
+* If there are enough dots in the name, let's just give it a
+* try 'as is'. The threshold can be set with the ndots option.
+* Also, query 'as is', if there is a trailing dot in the name.
*/
saved_herrno = -1;
- if (dots = _res.ndots) {
+ if (dots = _res.ndots || trailing_dot) {
ret = res_querydomain(name, NULL, class, type, answer, anslen);
- if (ret 0)
+ if (ret 0 || trailing_dot)
return (ret);
Re: SSH login takes very long time...sometimes
-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 much, so on top of that I got to implement (reinvent the wheel again) a script tailing the auth.log and firewalling bad gyus in order to secure sshd and let my legitimate users in. You could get rid of parsing auth.log and everything and just use pf(4) instead. Look at that: # sshspammer table table sshspammer persist block log quick from sshspammer # sshspammer # more than 6 ssh attempts in 15 seconds will be blocked ;) pass in quick on $ext_if proto tcp to ($ext_if) port ssh $tcp_flags (max-src-con n 10, max-src-conn-rate 6/15, overload sshspammer flush global) 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 has no such capabilities. I believe what you are searching for is indeed the pf(4) stuff mentioned above :) I'd be nice to have something like for instance the sendmail's client and rate connection limits, but I guess this is not the right place to ask. I believe it is. It's about FreeBSD and about Security ;-) regards, Marian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD9YvKgAq87Uq5FMsRAik2AKDMXXj4K0Pb9i0Qc6Cqowtzp6dynwCeIOpn gwk9aMT1skGMWis8tRL1Xtk= =jV8k -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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: 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, would you mind this change being made? No objection, just let me see the patch first. 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? Could you try this change in your system and report the exact results, such as output from tcpdump? That is how we could judge the change in question... Or were the results reported already? Ok, I rebuilded the world and the kernel with this change and tested it with tcpdump and a small program from the bin/62139 PR. During the test I saw two A? yahoo.com. requests, then two A? yahoo.com.lan. requests and that all taked only 30 seconds for gethostbyname() to give up with one unreachable DNS. Now it looks better than before. But I think there is still a bug. If I change hostname from saturn.lan to just saturn I see 4 A? yahoo.com. requests, like in the PR with options attemts:2. Why it tries to repeat the requests when the domain name is empty and so is the search list by default? That is the doubling I had wrote about in the PR. The doubling happens only to name-IP lookups, but not to reverse lookups, according to my observations. Therefore DNS requests by sshd and friends shouldn't be affected. However, sshd will make 3 (!) lookups on the client IP address by itself. I wonder if there is a good reason for that. I also found that the second round of the doubling would use the first domain from `search' line if it is in resolv.conf. The rest of domains specified on `search' line are ignored. Hoping this observation will come useful, should somebody want to fix this bug. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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, 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 time. Judging by the PR mentioned
above it should be at least 2m30s by default. Des, would you mind
this change being made?
No objection, just let me see the patch first.
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?
Could you try this change in your system and report the exact
results, such as output from tcpdump? That is how we could judge
the change in question... Or were the results reported already?
Ok, I rebuilded the world and the kernel with this change and tested it
with tcpdump and a small program from the bin/62139 PR. During the test
I saw two A? yahoo.com. requests, then two A? yahoo.com.lan.
requests and that all taked only 30 seconds for gethostbyname() to give
up with one unreachable DNS. Now it looks better than before.
But I think there is still a bug. If I change hostname from saturn.lan
to just saturn I see 4 A? yahoo.com. requests, like in the PR with
options attemts:2. Why it tries to repeat the requests when the domain
name is empty and so is the search list by default? That is the
doubling I had wrote about in the PR.
The doubling happens only to name-IP lookups, but not to reverse
lookups, according to my observations. Therefore DNS requests by
sshd and friends shouldn't be affected. However, sshd will make 3
(!) lookups on the client IP address by itself. I wonder if there
is a good reason for that.
I forgot that a search resolver(5) parameter is useless for reverse
resolving. But that doubling of name-IP requests with an empty (or
root, according to resolver(5)) domain in the search is still a bug,
IMHO. Although it shouldn't affect the sshd.
This time I used following program with a couple of date(1) to measure
the reverse lookup failure time with one unreachable DNS:
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include stdio.h
int main(int argc, char *argv[])
{
struct hostent *ps_hostent;
struct in_addr b_addr;
if (argc == 2 inet_aton(argv[1], b_addr)) {
ps_hostent = gethostbyaddr((void *)b_addr, 4, AF_INET);
if (ps_hostent != NULL) {
printf(%s\n, ps_hostent-h_name);
} else {
herror(argv[1]);
}
} else {
fputs(No valid argument.\n, stderr);
}
return 0;
}
On my system, builded with RES_DFLRETRY defined as 2, it taked only 15
seconds for gethostbyaddr() to fail, after two DNS requests. To emulate
the old behavior I added options attempts:4 to /etc/resolv.conf. With
that configuration it taked already one minute more (1:15) for
gethostbyaddr() to fail. Therefore three calls of gethostbyaddr(), when
RES_DFLRETRY defined as 2, are better than even one call of the same
function when RES_DFLRETRY defined as 4.
I also found that the second round of the doubling would use the
first domain from `search' line if it is in resolv.conf. The rest
of domains specified on `search' line are ignored. Hoping this
observation will come useful, should somebody want to fix this bug.
Alternatively FreeBSD could switch to a BIND9's resolver, like NetBSD
did in 2004. BIND9 is already in the base system.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 (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, would you mind this change being made? No objection, just let me see the patch first. 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? Could you try this change in your system and report the exact results, such as output from tcpdump? That is how we could judge the change in question... Or were the results reported already? -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 seconds. I use the following
sec.conf file;
Yeah, it does pretty much the same thing I do with a simple script like:
#!/usr/bin/perl
use strict;
my $MAX_TRIES = 5;
my $RULE_BASE = 10100;
my $RULES_MAX = 10;
my $Rule = $RULE_BASE;
my %Match;
sub ip_block # ($ip, $port)
{ my ($ip, $port) = @_;
`ipfw delete $Rule` if `ipfw list $Rule 2/dev/null`;
`ipfw add $Rule deny tcp from $ip to any $port in setup`;
$Rule = $RULE_BASE + (++$Rule - $RULE_BASE) % $RULES_MAX;
}
open LOG, tail -f /var/log/auth.log |;
while (LOG) {
if( /sshd\[\d+\]/ ) {
if( /((Illegal user|Failed password for) \S+|Did not receive
identification string) from (\d+\.\d+\.\d+\.\d+)/ ) {
my $ip = $3;
next if $Match{$ip}++ $MAX_TRIES;
ip_block($ip,22);
undef $Match{$ip};
}
}
}
close F;
And a cron job removes the blocks every hour:
7 * * * * /sbin/ipfw delete 10100 10101 10102 10103 10104 10105 10106
10107 10108 10109
It does the job, but it would be nice for sshd to have some rate-limit
protection built-in. Otherwise, with the increasing number of attacks
nowadays, many people would need similar protection.
Regards,
Atanas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 firewalling bad gyus in order to secure sshd and let my legitimate users in. You could get rid of parsing auth.log and everything and just use pf(4) instead. Look at that: # sshspammer table table sshspammer persist block log quick from sshspammer # sshspammer # more than 6 ssh attempts in 15 seconds will be blocked ;) pass in quick on $ext_if proto tcp to ($ext_if) port ssh $tcp_flags (max-src-con n 10, max-src-conn-rate 6/15, overload sshspammer flush global) Thanks for the suggestion! The pf in 5.x/6.x base and especially its rate-limit capability seems to be a good reason to upgrade my existing 4.x based boxes before RELENG_4's EoL. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 /usr/sbin/sshd -i This will allow 5 connections per min from a single IP. on one of my web servers, I see for example Feb 9 13:34:48 vinyl inetd[124]: ssh from 61.71.72.164 exceeded counts/min (limit 10/min) Feb 9 15:36:22 vinyl inetd[124]: ssh from 61.235.76.190 exceeded counts/min (limit 10/min) Feb 10 05:50:08 vinyl inetd[124]: ssh from 125.246.241.133 exceeded counts/min (limit 10/min) Feb 10 11:11:30 vinyl inetd[124]: ssh from 221.143.43.243 exceeded counts/min (limit 10/min) Feb 10 11:22:21 vinyl inetd[124]: ssh from 221.143.43.243 exceeded counts/min (limit 10/min) Feb 10 14:49:13 vinyl inetd[124]: ssh from 218.246.34.133 exceeded counts/min (limit 10/min) Feb 10 21:40:50 vinyl inetd[124]: ssh from 211.41.229.83 exceeded counts/min (limit 10/min) Feb 11 16:24:36 vinyl inetd[124]: ssh from 211.71.97.26 exceeded counts/min (limit 10/min) Feb 12 05:54:37 vinyl inetd[124]: ssh from 64.71.164.105 exceeded counts/min (limit 10/min) Feb 12 05:54:57 vinyl inetd[124]: ssh from 212.205.97.25 exceeded counts/min (limit 10/min) Feb 12 06:23:52 vinyl inetd[124]: ssh from 61.62.0.139 exceeded counts/min (limit 10/min) Feb 12 11:54:43 vinyl inetd[124]: ssh from 202.64.253.156 exceeded counts/min (limit 10/min) Feb 12 22:19:22 vinyl inetd[124]: ssh from 69.57.160.138 exceeded counts/min (limit 10/min) Feb 13 07:23:41 vinyl inetd[124]: ssh from 61.155.9.172 exceeded counts/min (limit 10/min) Feb 13 07:54:34 vinyl inetd[124]: ssh from 210.0.200.7 exceeded counts/min (limit 10/min) Feb 13 10:12:59 vinyl inetd[124]: ssh from 63.79.13.145 exceeded counts/min (limit 10/min) Feb 13 11:43:05 vinyl inetd[124]: ssh from 64.7.152.228 exceeded counts/min (limit 10/min) Feb 13 14:36:17 vinyl inetd[124]: ssh from 210.117.187.175 exceeded counts/min (limit 10/min) Feb 14 06:51:37 vinyl inetd[124]: ssh from 195.56.96.182 exceeded counts/min (limit 10/min) Its good enough to get make those pesky scripts move along. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 sshd man page: -i Specifies that sshd is being run from inetd(8). sshd is normally not run from inetd because it needs to generate the server key before it can respond to the client, and this may take tens of ^^^ seconds. Clients would have to wait too long if the key was ^^^ regenerated every time. However, with small key sizes (e.g., 512) using sshd from inetd may be feasible. It was my fault not verifying how much time it really takes. I just tested it on a couple of machines, and it seems to be way faster: # time ssh [EMAIL PROTECTED] real0m0.669s user0m0.012s sys 0m0.000s # time ssh [EMAIL PROTECTED] real0m0.374s user0m0.000s sys 0m0.008s # time ssh [EMAIL PROTECTED] real0m0.348s user0m0.000s sys 0m0.008s I ran this multiple times. The first one defaults to 2048-bit key (a 6-STABLE based box), the second one - to 1048 bit (5.4), the third one to a standalone ssh daemon. So what the man page says about the timings could have been true some 10 years ago, but not now. Start up inetd with -wWl -C 5 In inetd.conf ssh stream tcp nowait root /usr/sbin/sshd /usr/sbin/sshd -i This will allow 5 connections per min from a single IP. Yeah, I still use it to run (pro)ftpd, and never had problems with that. It's possible to specify also per entry limits, like: ftp stream tcp nowait/100/60/10 root /usr/libexec/ftpd ftpd -l ssh stream tcp nowait/50/10/5root /usr/sbin/sshd sshd -i 50/10/5 = max-children/max-conn-per-ip-per-minute/max-child-per-ip Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 time. Judging by the PR mentioned above it should be at least 2m30s by default. Des, would you mind this change being made? No objection, just let me see the patch first. 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? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 mentioned above it should be at least 2m30s by default. Des, would you mind this change being made? No objection, just let me see the patch first. DES Just a thought, wouldn't this open a new possibility for denial of service attacks? 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 firewalling bad gyus in order to secure sshd and let my legitimate users in. 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 has no such capabilities. I'd be nice to have something like for instance the sendmail's client and rate connection limits, but I guess this is not the right place to ask. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 directive in sshd_config. The amount of time that an attacker has to open many connections is probably not that important, as you can open a lot of TCP connections in 1 second even with a small link. 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 firewalling bad gyus in order to secure sshd and let my legitimate users in. Are you trying to prevent the ssh scanners that just try well-known combinations of usernames and passwords? It is not clear that you gain much by firewalling these off, other than having fewer log messages. 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 has no such capabilities. You can still run sshd through inetd (or, at least, the -i option is still documented in the sshd man page). If does suggest that you may need to reduce the key size to make this practical (increasing LoginGraceTime here may help too ;-) David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 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 directive in sshd_config. The amount of time that an attacker has to open many connections is probably not that important, as you can open a lot of TCP connections in 1 second even with a small link. 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 firewalling bad gyus in order to secure sshd and let my legitimate users in. Are you trying to prevent the ssh scanners that just try well-known combinations of usernames and passwords? It is not clear that you gain much by firewalling these off, other than having fewer log messages. 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 has no such capabilities. You can still run sshd through inetd (or, at least, the -i option is still documented in the sshd man page). If does suggest that you may need to reduce the key size to make this practical (increasing LoginGraceTime here may help too ;-) David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
-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, but I think he was busy at the time. Judging by the PR mentioned above it should be at least 2m30s by default. Des, would you mind this change being made? No objection, just let me see the patch first. DES Just a thought, wouldn't this open a new possibility for denial of service attacks? 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 firewalling bad gyus in order to secure sshd and let my legitimate users in. 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 has no such capabilities. I'd be nice to have something like for instance the sendmail's client and rate connection limits, but I guess this is not the right place to ask. Regards, Atanas __ 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 tempban-ssh flush global) with appropriate $max_conn_per_ip and $max_conn_rate limits, and expiretable in a cronjob to flush all entries in the tempban-ssh table which are older than predefined period. I hope this helps. - --niki -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD9RS9HNAJ/fLbfrkRAi/bAKCe6T8RIGeVaq/EGkcxFa26jcK5xACeIoES YEQ6LosYdZ824h8dVwwRo7c= =ZhLi -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 can protect against this with the MaxStartups directive in sshd_config. The amount of time that an attacker has to open many connections is probably not that important, as you can open a lot of TCP connections in 1 second even with a small link. These were different types of attacks, primarily originating from single IP addresses: 1. Dictionary attacks taking as much concurrent unauthenticated connections as possible and with speeds as fast as the server can respond. These were happening like a few up to several times a day, sometimes lasting hours. 2. Time based attacks taking again all of the available MaxStartups, but then doing nothing until the LoginGraceTime expires, then again, etc. These were not so frequent, but had the worst impact on the ssh availability. 3. Network scans on machines hosting some hundreds (or in some cases thousands) of IP addresses, causing outages lasting just a few minutes or so. 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 firewalling bad gyus in order to secure sshd and let my legitimate users in. Are you trying to prevent the ssh scanners that just try well-known combinations of usernames and passwords? It is not clear that you gain much by firewalling these off, other than having fewer log messages. All of the above three. It wasn't just a matter of too much log messages. The type 1. for instance, besides the ssh unavailability, and depending on the MaxStartups setting, can bring a server to its knees by dedicating all of its available resources for bouncing unauthenticated ssh requests. I tried setting a 'limit' ipfw firewall rule, something like: ipfw add allow tcp from any to any 22 in setup limit src-addr 5 I already had success with such a rule for a first level SMTP DoS protection before sendmail got its per-client and rate connection limits built in (since 8.13.0), and still keep that on, just in case. But unlike sendmail, ssh instances when hammered with bogus requests are way more CPU intensive. I couldn't afford limiting the ssh connectivity to just one single session per client IP (someone might need multiple ssh sessions while working on something, right?), and in case of multiple sessions enabled, machines would be still vulnerable to CPU overload (i.e. bouncing tons of useless ssh authentication attempts). So the best option for me was to implement a log analyzer script placing temporary blocks on the firewall when necessary. Like after 5 Illegal user or Failed password for or Did not receive identification string events, the script simply denies that IP right away on the firewall for one hour. So far this works well (for about 6 months already) and I no longer see unusual load spikes or ssh connectivity outages like before. 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 has no such capabilities. You can still run sshd through inetd (or, at least, the -i option is still documented in the sshd man page). If does suggest that you may need to reduce the key size to make this practical (increasing LoginGraceTime here may help too ;-) I knew that, but actually never tried it thinking it would be too slow. Now I just ran a ssh-keygen and found that it takes only a few seconds for a 1024-bit and several for 2048-bit key. So it's not that much bad and running it with 512 or 1024-bit key through inetd seems feasible enough. The default ssh key length in FreeBSD-6 however just got doubled from 1024 to 2048-bit. I believe there's a reason for that and don't like the idea of going down. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 tempban-ssh flush global) with appropriate $max_conn_per_ip and $max_conn_rate limits, and expiretable in a cronjob to flush all entries in the tempban-ssh table which are older than predefined period. I hope this helps. Thanks for the tip! I knew that at some point I will have to switch to pf, but unfortunately it wasn't available in FreeBSD-4.x, and I still have plenty of such boxes. Does anybody know whether ipfw (or something else within FreeBSD-4) is capable of setting connection rate limits? Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
[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 (takes seconds and CPU) on every incoming ssh connection, which would be kind of slow and wasteful. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 file; type=SingleWithThreshold ptype=RegExp pattern=Failed password for (\S+) from (\S+) port (\S+) ssh2 desc=SSH attack from $2 action=shellcmd /usr/local/bin/ipfwadd.sh $2 ; pipe 'Failed password for $1 from $2' /usr/bin/mail -s 'SSH Attack from $2' [EMAIL PROTECTED] window=60 thresh=3 type=SingleWithThreshold ptype=RegExp pattern=Illegal user (\S+) from (\S+) desc=SSH attack from $2 action=shellcmd /usr/local/bin/ipfwadd.sh $2 ; pipe 'Illegal user $1 from $2' /usr/bin/mail -s 'SSH Attack from $2' [EMAIL PROTECTED] window=60 thresh=3 - and I'm still using ipfw so ipfwadd.sh looks like this; #!/bin/sh /sbin/ipfw -q add 15 deny ip from $1 to any in via tun0 and run it with sec -conf=/usr/local/etc/sec.conf -input=/var/log/auth.log -pid=/var/run/sec.pid -detach Hope this helps, Carl. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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, would you mind this change being made? No objection, just let me see the patch first. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 true for my current 6.0-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/62139 As a workaround I may suggest addind options attempts:2 or even options attempts:1 line to the /etc/resolver.conf I've often thought that we shouled make the default login timeout longer than our DNS timeout, as it means it is hard (or impossible) to log in to fix your DNS server when your DNS server is down. It is even worse if you don't control some DNS server in the chain between the root and the name you're trying to look up. 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, would you mind this change being made? David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 returns error. And this is by default. All that is still true for my current 6.0-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/62139 As a workaround I may suggest addind options attempts:2 or even options attempts:1 line to the /etc/resolver.conf I've often thought that we shouled make the default login timeout longer than our DNS timeout, as it means it is hard (or impossible) to log in to fix your DNS server when your DNS server is down. It is even worse if you don't control some DNS server in the chain between the root and the name you're trying to look up. 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. I think the RES_DFLRETRY should also be decreased from 4 to 2, as it is defined in most of other systems. By the way, BIND9, that is a part of the FreeBSD base system, has its own resolver, where the RES_DFLRETRY defined as 2 (ses below): grep RES_DFLRETRY /usr/src/contrib/bind9/lib/bind/include/resolv.h #define RES_DFLRETRY2 /* Default #/tries. */ grep RES_DFLRETRY /usr/include/resolv.h #define RES_DFLRETRY4 /* retries per each name server */ And doubling of this number of retries by functions like gethostbyname() is also mysterious for me yet. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 resort; the hostname checks are there for a reason... I know. But using the UseDNS no option could be useful to debug the problem. Well. In fact, it's only one way to debug the problem. The more obvious way is to check wether the DNS is working (forward and reverse lookup) and fix it if possible :) regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 DNS server isn't responding. The other reason for very long waiting is a default configuration of resolver(5). In most other systems RES_DFLRETRY is defined as 2, but in FreeBSD it is 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 true for my current 6.0-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/62139 As a workaround I may suggest addind options attempts:2 or even options attempts:1 line to the /etc/resolver.conf ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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, their dns server isn't *that* slow :P. On 12/25/05, Rostislav Krasny [EMAIL PROTECTED] wrote: 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 DNS server isn't responding. The other reason for very long waiting is a default configuration of resolver(5). In most other systems RES_DFLRETRY is defined as 2, but in FreeBSD it is 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 true for my current 6.0-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/62139 As a workaround I may suggest addind options attempts:2 or even options attempts:1 line to the /etc/resolver.conf ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- James Tanis [EMAIL PROTECTED] http://pycoder.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 data. so when I check your IP and hostname you send me and when this do not match the reverse info I get I can suppose you do not have good intentions or you do not have the knowledge to set your network up. Both cases may not be welcome on my network and you get kicked out. Like you see here the decision is the owner's one who can or not enter his home. If you truly believe one can easily fake their IP then a reverse-lookup is even more irrelevant because it doesnt take a genius to choose an ip and hostname that match. From what your saying falsifying the actual reverse-lookup record need not even be considered. I don't pretend to be any kind of hacker or security professional, I have no idea how involved spoofing a valid (not local-only) ip is or if it is indeed possible, but it seems to me that this ability would only make the reverse-lookup less reliable. so reverse dns is a absolute valid check - what never was so important as today since each newborn already knows how to fake IP's and when your residential Ip provider do not has a correct reverse DNS get yourself a more serious one A good many large ips do not assign a reverse lookup as that would also require a hostname. Since most residential users do not need a host name it isn't necessarily standard procedure to give them one. Isp that assign reverse lookup cause an even bigger problem because no one want to name their computers according to their isp, for instance Charter likes to assign hostnames like: xxx-xxx-xxx-xxx.dhcp.xxx.xx.charter.com Which is very basically a hyphen delimited ip followed by an abbreviated city and state. Nothing wrong with the scheme but I don't really care to name my firewall that, I much prefer loki.pycoder.org. This in itself is not a sign of ill intent. Most residential users, whether they are knowledgeable or not will not all make sure to have their computers all reporting the hostname xxx-xxx-xxx-xxx.dhcp.xxx.xx.charter.com yet they have no ill intent. Clearly then reverse dns lookup is only desireable in specific situations where you know exactly where you'll be getting remote connections from and can accomodate if they do not have properly set reverse-lookup entries. anyway, you are mixing things up since you do not need a valid reverse dns to configure your sshd, the server admin can disable this lookup or use the local host file - or you may like the clever way and forget to set or delete your resolv.conf Exactly the point I was trying to argue. I've been using FreeBSD long enough to know my way around /etc as well as hold my own with BIND.. I was more than able to diagnose/fix the problem. That does not change the fact though that not everyone is able to administer their own dns, not because they do not know how, but because they do not have the right. How does this affect FreeBSD? Not at all, I'd just wish it didn't have to be in the default setup, but I've already lost interest in the subject as its really just an insignificant point that really didn't deserve this long of an email :P. João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- James Tanis [EMAIL PROTECTED] http://pycoder.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 /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 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 resort; the hostname checks are there for a reason... 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. [It doesn't filter anybody out; the DNS lookup will time out and the user can log in anyway.] What it does is helps you to know who you're dealing with. The fact that only the people who are *really* responsible for the IP delegation can control the reverse entry is a feature, not a bug. Most residential ips either have no reverse-lookup or it's set to some long painful textual conglomeration devised by the isp (although at the isp I work at we will set it per some users requests..). It doesn't matter *what* it is, just that there is one. And remember that you are not matching a forward mapping to a reverse one, but the other way around. It's fine if you use a host name that doesn't match your reverse name mapping, as long as the reverse name mapping gives a hostname that in turn points to you. Anyway, to make a long story short, you end up locking out or at the very least delaying (for up to several minutes) the very people who use it. I can definately see the sysadmin side of it though were its used perhaps to remotely access a data center from a satellite location -- you don't much want or care that a residential ip has problems connecting to the server. It just definately doesn't seem to me a last resort option, at the drop of a hat someone can change their hostname to match their reverse dns and back again -- As I explained earlier, that's not the check that is being made. setting up a good packet filter to filter out all but the desired ip ranges seems a much more reliable method. They are not exclusive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SSH login takes very long time...sometimes
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 logged into OBOE and ssh BSD (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed man ssh for time out related stuff, but no luck. Where should I start looking for clues? All machines have had clean installs from newfs'd drive under both 5.4 and 6.0 so I'm sure no left over configs are getting propagated. -- - Dr Michael A. Koerber x3250 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 around one minute before asking for a prompt. However, if I'm logged into OBOE and ssh BSD (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed man ssh for time out related stuff, but no luck. Where should I start looking for clues? Most probably it's a reverse dns issue. You can either check your dns/hosts setup or tcpdump the traffic when you try to login a machine. -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 prompt. However, if I'm logged into OBOE and ssh BSD (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed man ssh for time out related stuff, but no luck. Where should I start looking for clues? All machines have had clean installs from newfs'd drive under both 5.4 and 6.0 so I'm sure no left over configs are getting propagated. Check your DNS (or reverse DNS really) on the laptop (OBOE). Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 prompt. However, if I'm logged into OBOE and ssh BSD (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed man ssh for time out related stuff, but no luck. Where should I start looking for clues? 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). -Kobi. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 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... HTH, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 mode (sshd -d). 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 resort; the hostname checks are there for a reason... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 [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 around one minute before asking for a prompt. However, if I'm logged into OBOE and ssh BSD (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed man ssh for time out related stuff, but no luck. Where should I start looking for clues? All machines have had clean installs from newfs'd drive under both 5.4 and 6.0 so I'm sure no left over configs are getting propagated. -- - Dr Michael A. Koerber x3250 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- James Tanis [EMAIL PROTECTED] http://pycoder.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 painful textual conglomeration devised by the isp (although at the isp I work at we will set it per some users requests..). Anyway, to make a long story short, you end up locking out or at the very least delaying (for up to several minutes) the very people who use it. I can definately see the sysadmin side of it though were its used perhaps to remotely access a data center from a satellite location -- you don't much want or care that a residential ip has problems connecting to the server. It just definately doesn't seem to me a last resort option, at the drop of a hat someone can change their hostname to match their reverse dns and back again -- setting up a good packet filter to filter out all but the desired ip ranges seems a much more reliable method. 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 /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 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 resort; the hostname checks are there for a reason... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- James Tanis [EMAIL PROTECTED] http://pycoder.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
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 either have no reverse-lookup or I guess you are wrong 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 data. so when I check your IP and hostname you send me and when this do not match the reverse info I get I can suppose you do not have good intentions or you do not have the knowledge to set your network up. Both cases may not be welcome on my network and you get kicked out. Like you see here the decision is the owner's one who can or not enter his home. so reverse dns is a absolute valid check - what never was so important as today since each newborn already knows how to fake IP's and when your residential Ip provider do not has a correct reverse DNS get yourself a more serious one anyway, you are mixing things up since you do not need a valid reverse dns to configure your sshd, the server admin can disable this lookup or use the local host file - or you may like the clever way and forget to set or delete your resolv.conf João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
