Ghosted logins in w/who
I recently upgraded to FreeBSD 9.1-STABLE, and there was a strange added side effect. Users that telnet into the machine seem to have their logins forever ghosted in who/w. If a user connects via telnet, then logs out, their login still remains in the w/who. If another user logins in with the pty they had, whatever they do also shows up in the ghosted w/who of the previous user using that pty. For example: User X logs in, runs BitchX. Detaches the process and logs out.User Y logs in, gets assigned User X's previous pty, who/w now reports that user is running BitchX. That user has no access to the BitchX session or anything, it's just being displayed weird in who/w. I seem to remember this problem like a decade ago and I had written a script or there was a script that passed around called clearlogin. Any ideas? Thanks all!Damon [Sorry for the cross-post. Mods feel free to delete/move as necessary. Thx.] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: does toor have passwd or not? According to logins -p: yes
On Wed, Dec 30, 2009 at 02:11:13PM +0100, Erik Trulsson wrote: On Wed, Dec 30, 2009 at 12:33:41PM +, Anton Shterenlikht wrote: I was checking for passwordless accounts with 'logins -p'. None was found. However, I understand toor doesn't have passwd by default, and I never touched it, so I expected logins -p to show toor, but it didn't. Just to check I also tried to su toor with root passwd - no access. Please can somebody clarify if toor does indeed have passwd. toor, like many other system accounts, by default has its password entry set to '*' which indicates that password authenictation is disabled for that account. (See the passwd(5) manpage for details.) This means that unless you set a password for toor you cannot login as toor, so the mere presence of that account is not a security problem. my mistake was due to looking at passwd(1) instead of passwd(5). many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
does toor have passwd or not? According to logins -p: yes
I was checking for passwordless accounts with 'logins -p'. None was found. However, I understand toor doesn't have passwd by default, and I never touched it, so I expected logins -p to show toor, but it didn't. Just to check I also tried to su toor with root passwd - no access. Please can somebody clarify if toor does indeed have passwd. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: does toor have passwd or not? According to logins -p: yes
On Wed, Dec 30, 2009 at 12:33:41PM +, Anton Shterenlikht typed: I was checking for passwordless accounts with 'logins -p'. None was found. However, I understand toor doesn't have passwd by default, and I never touched it, so I expected logins -p to show toor, but it didn't. Just to check I also tried to su toor with root passwd - no access. Please can somebody clarify if toor does indeed have passwd. toor:*:0:0::0:0:Bourne-again Superuser:/root: (from master.passwd) As you can see, the password is not empty; it's a '*'. Nothing hashes to *. Ruben ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: does toor have passwd or not? According to logins -p: yes
On Wed, Dec 30, 2009 at 12:33:41PM +, Anton Shterenlikht wrote: I was checking for passwordless accounts with 'logins -p'. None was found. However, I understand toor doesn't have passwd by default, and I never touched it, so I expected logins -p to show toor, but it didn't. Just to check I also tried to su toor with root passwd - no access. Please can somebody clarify if toor does indeed have passwd. toor, like many other system accounts, by default has its password entry set to '*' which indicates that password authenictation is disabled for that account. (See the passwd(5) manpage for details.) This means that unless you set a password for toor you cannot login as toor, so the mere presence of that account is not a security problem. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: does toor have passwd or not? According to logins -p: yes
Anton Shterenlikht wrote: I was checking for passwordless accounts with 'logins -p'. None was found. However, I understand toor doesn't have passwd by default, and I never touched it, so I expected logins -p to show toor, but it didn't. Just to check I also tried to su toor with root passwd - no access. Please can somebody clarify if toor does indeed have passwd. By default, the account is locked. Look at /etc/master.passwd -- the toor entry probably looks like this: toor:*:0:0::0:0:Bourne-again Superuser:/root: That '*' in the second field means there's simply no possibility of login using a password. In this case, everything is fine. If it's a string of dollar signs and alphanumerics like this: $1$salt$qJH7.N4xYta3aEG/dfqo/0 then the account does have a real password. This is probably OK, if you want to be able to log in as toor directly. [Before anyone gets excited and tries to break into any of my machines, no that isn't a real crypted password from my master.passwd file. It's created like this: % perl -le 'print crypt(password, \$1\$salt\$)' ] If there's nothing in the second field, then you have a problem, as that means the account has a NULL password (ie. just hit return when prompted for a password -- this is what 'logins -p' detects). That may or may not actually work to get into the toor account depending on how you're trying to authenticate and on various other security settings eg. in /etc/pam.d, but even so it is something that should be fixed pronto. Use vipw(8) to edit master.passwd and insert a * -- vipw will regenerate /etc/passwd and pwd.db automatically for you. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: does toor have passwd or not? According to logins -p: yes
On Wed, 30 Dec 2009, Matthew Seaman wrote: Anton Shterenlikht wrote: I was checking for passwordless accounts with 'logins -p'. None was found. However, I understand toor doesn't have passwd by default, and I never touched it, so I expected logins -p to show toor, but it didn't. Just to check I also tried to su toor with root passwd - no access. Please can somebody clarify if toor does indeed have passwd. If there's nothing in the second field, then you have a problem, as that means the account has a NULL password (ie. just hit return when prompted for a password -- I've been wrong before, but I think you do not get a password prompt at all, at least not on login. You enter the login: name and you are off to motd and a command prompt. this is what 'logins -p' detects). That may or may not actually work to get into the toor account depending on how you're trying to authenticate and on various other security settings eg. in /etc/pam.d, but even so it is something that should be fixed pronto. Use vipw(8) to edit master.passwd and insert a * -- vipw will regenerate /etc/passwd and pwd.db automatically for you. -- Lars Eighner http://www.larseighner.com/index.html 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: does toor have passwd or not? According to logins -p: yes
Lars Eighner wrote: On Wed, 30 Dec 2009, Matthew Seaman wrote: If there's nothing in the second field, then you have a problem, as that means the account has a NULL password (ie. just hit return when prompted for a password -- I've been wrong before, but I think you do not get a password prompt at all, at least not on login. You enter the login: name and you are off to motd and a command prompt. It depends on what application you're using to authenticate yourself. Login on the console doesn't ask for a password. sshd(8) does (IIRC). I can't remember what su(1) does. ftpd(8) always asks for a password. xdm(1) and that ilk have fields for username and password in one panel, and generally you just ignore the password field. That's for access to a non-root account: as I said, root or other super-user accounts such as toor may not permit root login at all, or may not permit login without a password. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: does toor have passwd or not? According to logins -p: yes
The handbook has documentation on this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/security.html#TOOR-ACCOUNT -jgh On Wed, Dec 30, 2009 at 05:05:35PM +, Matthew Seaman thus spake: Lars Eighner wrote: On Wed, 30 Dec 2009, Matthew Seaman wrote: If there's nothing in the second field, then you have a problem, as that means the account has a NULL password (ie. just hit return when prompted for a password -- I've been wrong before, but I think you do not get a password prompt at all, at least not on login. You enter the login: name and you are off to motd and a command prompt. It depends on what application you're using to authenticate yourself. Login on the console doesn't ask for a password. sshd(8) does (IIRC). I can't remember what su(1) does. ftpd(8) always asks for a password. xdm(1) and that ilk have fields for username and password in one panel, and generally you just ignore the password field. That's for access to a non-root account: as I said, root or other super-user accounts such as toor may not permit root login at all, or may not permit login without a password. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to block NIS logins via ssh?
enough time and resources, any password can be cracked. I really do not when enough time is somehow like lifetime of a star ;) (unless you choose bad passwords). understand why so many users insist on using passwords anyway. 2 reasons: - It's the default - Less hassle getting access from a new account. It's the first thing I disable as well. I have machines I don't even know my local password for. Key on a flash card so I can get access from any new machine with an USB port. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to block NIS logins via ssh?
On Thursday 11 December 2008 12:40:10 Jerry wrote: On Thu, 11 Dec 2008 09:11:26 +0100 Mel fbsd.questi...@rachie.is-a-geek.net wrote: 6) Disable password based logins and use keys only. Personally, I have always used 'keys' instead of passwords. Given enough time and resources, any password can be cracked. I really do not understand why so many users insist on using passwords anyway. 2 reasons: - It's the default - Less hassle getting access from a new account. It's the first thing I disable as well. I have machines I don't even know my local password for. Key on a flash card so I can get access from any new machine with an USB port. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to block NIS logins via ssh?
On Thursday 11 December 2008 08:10:09 Dan Mahoney, System Admin wrote: Given, there's several solutions to this: 1) The Kluge as above. 2) A pam module to check /etc/group (this is standard login behavior, and historically supported, and available on other platforms, adding a module, even to ports, is trivial. 3) A patch to openssh to do /etc/shells checking (I'll note that openSSH has the UseLogin option, which may also do this. 4) An option to pam_unix to check this. Differs from #2 in that it's a change to an existing module instead of one in ports. 5) Use AllowGroups/AllowUsers and/or their Deny equivalent in sshd_config. 6) Disable password based logins and use keys only. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to block NIS logins via ssh?
On Thu, 11 Dec 2008 09:11:26 +0100 Mel [EMAIL PROTECTED] wrote: On Thursday 11 December 2008 08:10:09 Dan Mahoney, System Admin wrote: Given, there's several solutions to this: 1) The Kluge as above. 2) A pam module to check /etc/group (this is standard login behavior, and historically supported, and available on other platforms, adding a module, even to ports, is trivial. 3) A patch to openssh to do /etc/shells checking (I'll note that openSSH has the UseLogin option, which may also do this. 4) An option to pam_unix to check this. Differs from #2 in that it's a change to an existing module instead of one in ports. 5) Use AllowGroups/AllowUsers and/or their Deny equivalent in sshd_config. 6) Disable password based logins and use keys only. Personally, I have always used 'keys' instead of passwords. Given enough time and resources, any password can be cracked. I really do not understand why so many users insist on using passwords anyway. -- Jerry [EMAIL PROTECTED] A sadist is a masochist who follows the Golden Rule. signature.asc Description: PGP signature
How to block NIS logins via ssh?
Hello all, I'm noticing that when following the directions given here: http://www.freebsd.org/doc/en/books/handbook/network-nis.html For how to disable logins, the recommended action is to set the shell to /sbin/nologin. However, this is sloppy as it allows the user to log in, get the motd, do everything short of getting a shell. I've tried starring out the password in the +: entry, (and putting in a bad password, like x), and those don't seem to work. I am still able to connect via sshd and prove that the account works. What's happening here? -Dan -- Wrin quick, somebody tell me the moon phase please? Dan_Wood Wrin: Plummeting. -Undernet #reboot, 9/11/01 (day of the WTC bombing) Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to block NIS logins via ssh?
On Wed, 10 Dec 2008, Dan Nelson wrote: In the last episode (Dec 10), Dan Mahoney, System Admin said: I'm noticing that when following the directions given here: http://www.freebsd.org/doc/en/books/handbook/network-nis.html For how to disable logins, the recommended action is to set the shell to /sbin/nologin. However, this is sloppy as it allows the user to log in, get the motd, do everything short of getting a shell. I've tried starring out the password in the +: entry, (and putting in a bad password, like x), and those don't seem to work. I am still able to connect via sshd and prove that the account works. By default, the passwd field is ignored in an NIS + or - line. It looks like if you rebuild libc with PW_OVERRIDE_PASSWD=1, you will get the behaviour you're looking for (see the compat_set_template function in src/lib/libc/gen/getpwent.c). Okay, let's look at it from an alternate tack then -- what else renders an account invalid? Is there a pam knob to check /etc/shells? Or an sshd option? I found these: http://osdir.com/ml/linux.admin.managers/2003-08/msg00016.html for a user who had a similar problem, but freebsd doesn't appear to have the requisite module. This could also be implemented as an option to pam_unix (which could check either /etc/shells or the NIS equivalent, since it already has the NIS hooks.) I'll make a separate post to -hackers requesting this. it's probably pretty trivial to port, but I'm leery to do so not-being a c-coder. -Dan -- Of course she's gonna be upset! You're dealing with a woman here Dan, what the hell's wrong with you? -S. Kennedy, 11/11/01 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to block NIS logins via ssh?
In the last episode (Dec 10), Dan Mahoney, System Admin said: On Wed, 10 Dec 2008, Dan Nelson wrote: In the last episode (Dec 10), Dan Mahoney, System Admin said: I'm noticing that when following the directions given here: http://www.freebsd.org/doc/en/books/handbook/network-nis.html For how to disable logins, the recommended action is to set the shell to /sbin/nologin. However, this is sloppy as it allows the user to log in, get the motd, do everything short of getting a shell. I've tried starring out the password in the +: entry, (and putting in a bad password, like x), and those don't seem to work. I am still able to connect via sshd and prove that the account works. By default, the passwd field is ignored in an NIS + or - line. It looks like if you rebuild libc with PW_OVERRIDE_PASSWD=1, you will get the behaviour you're looking for (see the compat_set_template function in src/lib/libc/gen/getpwent.c). Okay, let's look at it from an alternate tack then -- what else renders an account invalid? Is there a pam knob to check /etc/shells? Or an sshd option? There's a pam_exec module which launches a program of your choice. You could look up the user's shell from there using whatever script you're comfortable with. Or, if all your NIS users are members of a certain group, you could use the pam_group module to deny them. I found these: http://osdir.com/ml/linux.admin.managers/2003-08/msg00016.html for a user who had a similar problem, but freebsd doesn't appear to have the requisite module. This could also be implemented as an option to pam_unix (which could check either /etc/shells or the NIS equivalent, since it already has the NIS hooks.) It looks like our pam_unix module has a local_pass option, whch claims to disallow NIS logins. Have you tried that? I'll make a separate post to -hackers requesting this. it's probably pretty trivial to port, but I'm leery to do so not-being a c-coder. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to block NIS logins via ssh?
On Wed, 10 Dec 2008, Dan Nelson wrote: In the last episode (Dec 10), Dan Mahoney, System Admin said: On Wed, 10 Dec 2008, Dan Nelson wrote: In the last episode (Dec 10), Dan Mahoney, System Admin said: I'm noticing that when following the directions given here: http://www.freebsd.org/doc/en/books/handbook/network-nis.html For how to disable logins, the recommended action is to set the shell to /sbin/nologin. However, this is sloppy as it allows the user to log in, get the motd, do everything short of getting a shell. I've tried starring out the password in the +: entry, (and putting in a bad password, like x), and those don't seem to work. I am still able to connect via sshd and prove that the account works. By default, the passwd field is ignored in an NIS + or - line. It looks like if you rebuild libc with PW_OVERRIDE_PASSWD=1, you will get the behaviour you're looking for (see the compat_set_template function in src/lib/libc/gen/getpwent.c). Okay, let's look at it from an alternate tack then -- what else renders an account invalid? Is there a pam knob to check /etc/shells? Or an sshd option? There's a pam_exec module which launches a program of your choice. You could look up the user's shell from there using whatever script you're comfortable with. Or, if all your NIS users are members of a certain group, you could use the pam_group module to deny them. I found these: http://osdir.com/ml/linux.admin.managers/2003-08/msg00016.html for a user who had a similar problem, but freebsd doesn't appear to have the requisite module. This could also be implemented as an option to pam_unix (which could check either /etc/shells or the NIS equivalent, since it already has the NIS hooks.) It looks like our pam_unix module has a local_pass option, whch claims to disallow NIS logins. Have you tried that? No, I'm using netgroups -- i.e. allow one user (or, rather, allow the @STAFF group, import the whole map, disallow the rest from logging in.) Actually, I just found the answer to this...instead of putting nologin in, put in something bogus (I'm using /nonexistent)...and the password will just loop. This is something sshd does internally. Given, there's several solutions to this: 1) The Kluge as above. 2) A pam module to check /etc/group (this is standard login behavior, and historically supported, and available on other platforms, adding a module, even to ports, is trivial. 3) A patch to openssh to do /etc/shells checking (I'll note that openSSH has the UseLogin option, which may also do this. 4) An option to pam_unix to check this. Differs from #2 in that it's a change to an existing module instead of one in ports. -Dan -- The first annual 5th of July party...have you been invited? It's a Jack Party. Okay, so Long Island's been invited. --Cali and Gushi, 6/23/02 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Upgrade to imap-uw 2006j Breaks Logins
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Marcus Clarke Sent: Sunday, September 30, 2007 10:42 PM To: [EMAIL PROTECTED] Cc: FreeBSD Mailing List Subject: Re: Upgrade to imap-uw 2006j Breaks Logins On Sun, 2007-09-30 at 23:50 -0500, Tim Daneliuk wrote: As part of a portupgrade, one of my servers just picked up the latest version of imap-uw (2006j). Now users can no longer login as imapd claims they are providing incorrect passwords. I manually copied the version I was using (2004g) to /usr/local/libexec/imapd, and all is well, so it is definitely the new release. I did try manually reinstalling the imap-uw and cclient ports using the make option to enable both SSL and plain text passwords. Still no joy. 'Anyone else seeing this/have a workaround? Try the fix I just committed. It's now working for me. I don't get it. In the g version, linkage.c only existed for the Mac and tops OS's not unix - why was it loaded under FreeBSD by the old Makefile? Your explanation in the port makes no sense as to why it was removed - I can't understand why it was included in the first place. I'm interested in the issue because a while ago I tried compiling a webmail program under FreeBSD that used the c-client libraries, and I got it built but the program could not authenticate using the c-client libraries. This was using the g version. Was something broken in uw-imap then that they fixed in the j version, which we had hacked around in the g version by including linkage.c? Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrade to imap-uw 2006j Breaks Logins
As part of a portupgrade, one of my servers just picked up the latest version of imap-uw (2006j). Now users can no longer login as imapd claims they are providing incorrect passwords. I manually copied the version I was using (2004g) to /usr/local/libexec/imapd, and all is well, so it is definitely the new release. I did try manually reinstalling the imap-uw and cclient ports using the make option to enable both SSL and plain text passwords. Still no joy. 'Anyone else seeing this/have a workaround? -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrade to imap-uw 2006j Breaks Logins
On Sun, 2007-09-30 at 23:50 -0500, Tim Daneliuk wrote: As part of a portupgrade, one of my servers just picked up the latest version of imap-uw (2006j). Now users can no longer login as imapd claims they are providing incorrect passwords. I manually copied the version I was using (2004g) to /usr/local/libexec/imapd, and all is well, so it is definitely the new release. I did try manually reinstalling the imap-uw and cclient ports using the make option to enable both SSL and plain text passwords. Still no joy. 'Anyone else seeing this/have a workaround? Try the fix I just committed. It's now working for me. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Setting up INN to handle user logins
I'm moving my INN server from an old BSD/OS box (yes, there are still a few of them) to FreeBSD. A few people connect to the nntp server from random places on the net and log in with a user and password. In the old version on BSD/OS the logins and passwords are in a text file, but in the current version that part has been rewritten so it's got a zillion wonderful options, none of which I appear to want. Does anyone have a current INN config I could steal that does this? In case it's not clear, these logins are unrelated to the /etc/passwd ones, they're just for news. TIA. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
require pam_deny in auth chain causes logins to fail
pam.d/README says: Note that having a sufficient module as the last entry for a particular service and module type may result in surprising behaviour. To get the intended semantics, add a required entry listing the pam_deny module at the end of the chain. But in fact auth sufficient pam_unix.so auth required pam_deny.so always fails, because (from the PAM article): The second exception is that pam_setcred(3) treats binding and sufficient modules as if they were required which means the final decision drops through to pam_deny even if pam_unix succeeds. Other than the obvious (make pam_unix, or whatever is the last module in the auth chain, required rather than sufficient, and leave out the required pam_deny) is there another solution to this? Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: incorrect logins
On Sun, 2006-02-12 at 04:39, Playnet wrote: Hello FreeBSD, I see many records as Feb 10 21:08:55 sstand sshd[84600]: Failed password for root from 61.218.130.20 port 46356 ssh2 How can i block these IP, who try root as login? Have any soft in ports? In the default setup of SSH, root login is disabled. Check the manual for ssh. As for blocking Ips check hosts_deny and hosts_allow. I would recommend that you block the ssh port at you firewall for stop remote logons via ssh etc. Rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: incorrect logins
Robert Slade wrote: On Sun, 2006-02-12 at 04:39, Playnet wrote: Hello FreeBSD, I see many records as Feb 10 21:08:55 sstand sshd[84600]: Failed password for root from 61.218.130.20 port 46356 ssh2 How can i block these IP, who try root as login? Have any soft in ports? In the default setup of SSH, root login is disabled. Check the manual for ssh. As for blocking Ips check hosts_deny and hosts_allow. I would recommend that you block the ssh port at you firewall for stop remote logons via ssh etc. Rob Either you 1 configure SSH to only allow logins from certain hostnames or IP addresses or for certain users, and/or 2 install a program to watch your logfiles and modify your firewall rules dynamically according to specified triggers, like /usr/ports/security/denyhosts, and/or 3 choose strong passwords or -phrases and not care ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: incorrect logins
lars wrote: Either you 1configure SSH to only allow logins from certain hostnames or IP addresses or for certain users, and/or 2install a program to watch your logfiles and modify your firewall rules dynamically according to specified triggers, like /usr/ports/security/denyhosts, and/or 3choose strong passwords or -phrases and not care You forgot: 4Use SSH key based auth exclusively. Turn off all of the password stuff in sshd_config. Laugh at the poor fools trying to break in. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
RE: incorrect logins
This last week the subject of failed ssh logins was covered in 2 different threads and was answered in full. Please check the archives for your answers before asking the same question over again. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Playnet Sent: Saturday, February 11, 2006 11:39 PM To: FreeBSD Mailing List Subject: incorrect logins Hello FreeBSD, I see many records as Feb 10 21:08:55 sstand sshd[84600]: Failed password for root from 61.218.130.20 port 46356 ssh2 How can i block these IP, who try root as login? Have any soft in ports? -- Best regards, Playnet mailto:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
incorrect logins
Hello FreeBSD, I see many records as Feb 10 21:08:55 sstand sshd[84600]: Failed password for root from 61.218.130.20 port 46356 ssh2 How can i block these IP, who try root as login? Have any soft in ports? -- Best regards, Playnet mailto:[EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: incorrect logins
I see many records as Feb 10 21:08:55 sstand sshd[84600]: Failed password for root from 61.218.130.20 port 46356 ssh2 How can i block these IP, who try root as login? Have any soft in ports? There are some ports that do it. One thing I didn't like about the ports (at least the ones I looked at) was that the app managed removing the firewall rules itself. Which means that if the app crashes right after you lock yourself out for some reason, thoes firewall rules are never going to get reset. http://www.pjkh.com/wiki/ssh_monitor Is my own little perl script and associated crontab entries to get around it. But if it were me, I'd check the ports out too as some of them do more than what I wanted to do. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Not allowing SSH logins without a public key?
I have created a public/private key set with putty and managed to add the public key to my .ssh directory. I have also verified that it works as desired. I'm not too confident in configuring the SSHD so some help is much appreciated. I would like to not allow a ssh connection to the server for users that hasn't provided a public key. Thanks in advance, Joe ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Not allowing SSH logins without a public key?
Edit the file /etc/ssh/sshd_config and change the following two parameters to NO PasswordAuthentication no ChallengeResponseAuthentication no Make sure that RSAAuthentication yes remains set. Then sighup the ssh-daemon by invoking the following command kill -HUP `cat /avr/run/sshd.pid` That's it! By the way a very good decision to set it up this way! ;) Greetz, Ice Joachim Dagerot schrieb: I have created a public/private key set with putty and managed to add the public key to my .ssh directory. I have also verified that it works as desired. I'm not too confident in configuring the SSHD so some help is much appreciated. I would like to not allow a ssh connection to the server for users that hasn't provided a public key. Thanks in advance, Joe ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Frank Mueller eMail: [EMAIL PROTECTED] Mobil: +49.177.6858655 Fax: +49.951.3039342 emendis GmbH Hofmannstr. 89, 91052 Erlangen, Germany Fon: +49.9131.817361 Fax: +49.9131.817386 Geschaeftsfuehrer: Gunter Kroeber, Volker Wiesinger Sitz Erlangen, Amtsgericht Fuerth HRB 10116 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Not allowing SSH logins without a public key?
Frank Mueller - emendis GmbH wrote: Edit the file /etc/ssh/sshd_config and change the following two parameters to NO PasswordAuthentication no ChallengeResponseAuthentication no Make sure that RSAAuthentication yes remains set. Then sighup the ssh-daemon by invoking the following command kill -HUP `cat /avr/run/sshd.pid` Assuming 5.X or later, the better way to restart any service is to use its script in /etc/rc.d (or /usr/local/etc/rc.d for most ports). In this case sh /etc/rc.d/sshd reload Services that don't accept reload will take restart. see rc(8). --Alex PS depending on the scale of the system you run, and the exact restrictions you want, you might find AllowUsers to be useful as well. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Not allowing SSH logins without a public key?
On 2005-09-13 23:27, Joachim Dagerot [EMAIL PROTECTED] wrote: I have created a public/private key set with putty and managed to add the public key to my .ssh directory. I have also verified that it works as desired. I'm not too confident in configuring the SSHD so some help is much appreciated. I would like to not allow a ssh connection to the server for users that hasn't provided a public key. You can explicitly allow (or disallow) authentication methods by editing your ``/etc/ssh/sshd_config'' file. For details, please refer to sshd_config(5): % man sshd_config Some of the relevant options in the unmodified sshd_config I have here are the following: #RSAAuthentication yes #PubkeyAuthentication yes #RhostsRSAAuthentication no #HostbasedAuthentication no #PasswordAuthentication no #ChallengeResponseAuthentication yes #KerberosAuthentication no #GSSAPIAuthentication no In general, the options whose name contains ``Authentication'' are authentication methods, and you can enable or disable each one separately. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:SSH root logins using public key only confusion
ref: http://lists.freebsd.org/pipermail/freebsd-questions/2005-August/095052.html With a default sshd_config but PermitRootLogin set to 'without-password' I find that root is still allowed to login with a user/pass what about turning PasswordAuthentication off? greetz wmiuser/u at netbeisser.de E7AC 1E9B 87D8 5BD2 E2F2 6F4A 3177 ED68 8185 480C ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
SSH root logins using public key only confusion
I've always preferred setting PermitRootLogin without-password in my sshd_config in order to allow root logins using a public key only. I'm sure the above directive was all I needed to change in the past in order to achieve this, however it now seems something has changed either in the default sshd_config file or PAM's configuration itself. The man page warns about several other directives i'm simply not sure of ( ChallengeResponseAuthentication, PasswordAuthentication and pam_unix within /etc/pam.d/sshd ) so I would appreciate some help on how to reach my goal. I am very confused! With a default sshd_config but PermitRootLogin set to 'without-password' I find that root is still allowed to login with a user/pass. A feeble attempt at understanding the sshd_config man page led me to disable ChallengeResponseAuthentication and enable PasswordAuthentication left me with no direct root access at all ( password or public key ). I have verified that my public key works correctly. There are several local users who prefer authentication with passwords, so I just want root to require the public key. This is a FreeBSD 5.4 box. My sshd_config is now default again ( except requirement of SSH2 ), here is my /etc/pam.d/sshd in case it is causing the problem. - # # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ # # PAM configuration for the sshd service # # auth authrequiredpam_nologin.so no_warn authsufficient pam_opie.so no_warn no_fake_prompts authrequisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass authrequiredpam_unix.so no_warn try_first_pass # account #accountrequiredpam_krb5.so account requiredpam_login_access.so account requiredpam_unix.so # session #sessionoptionalpam_ssh.so session requiredpam_permit.so # password #password sufficient pam_krb5.so no_warn try_first_pass passwordrequiredpam_unix.so no_warn try_first_pass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: autoblocking many ssh failed logins from the same IP....
John Cholewa wrote: Jun 30 10:36:05 phantom sshd[70478]: Failed password for news from 212.88.182.121 port 51218 ssh2 Jun 30 10:36:16 phantom sshd[70500]: Failed password for sshd from 212.88.182.121 port 51608 ssh2 Jun 30 10:36:39 phantom sshd[70569]: Failed password for root from 212.88.182.121 port 52297 ssh2 I get the above a lot in my logs (except more of it). Each day, a couple hundred failed attempts to log in from one or sometimes two IP addresses shows up. I don't have anything like ipf running, and since this machine is about fifteen hundred miles away from me, I don't want to experiment with software firewalling right now. That known, is there any way to tell sshd (or some more powerful daemon) to stop accepting login attempts from a given IP if it tries and fails to log in too many times in a limited duration (like in the same minute)? I suppose, now that I'm thinking about it, that it'd be best to actually just read the man pages and figure out how to get sshd to ignore any attempt to attach from ports other than 22. I mean, why are other machines trying to ssh in at ports over fifty thousand anyway? -- -JC http://www.livejournal.com/users/jcholewa/ PS: Oh, yeah ... FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 ; openssh-3.6.1_5 ; openssl-0.9.7d_1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] I had this on my FreeBSD 4.10 box as well. sshd can be configured to only allow logins for specific users. Edit /etc/sshd_config to add the following AllowUsers USER_NAME You can have multiple AllowUsers entries if you want more than one user to be able to ssh in. This has worked pretty well for me, although I still get an occasional (once every couple of days) failed login attempt on the one valid user name I've set up. I guess I could use a less guessable user id. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
autoblocking many ssh failed logins from the same IP....
Jun 30 10:36:05 phantom sshd[70478]: Failed password for news from 212.88.182.121 port 51218 ssh2 Jun 30 10:36:16 phantom sshd[70500]: Failed password for sshd from 212.88.182.121 port 51608 ssh2 Jun 30 10:36:39 phantom sshd[70569]: Failed password for root from 212.88.182.121 port 52297 ssh2 I get the above a lot in my logs (except more of it). Each day, a couple hundred failed attempts to log in from one or sometimes two IP addresses shows up. I don't have anything like ipf running, and since this machine is about fifteen hundred miles away from me, I don't want to experiment with software firewalling right now. That known, is there any way to tell sshd (or some more powerful daemon) to stop accepting login attempts from a given IP if it tries and fails to log in too many times in a limited duration (like in the same minute)? I suppose, now that I'm thinking about it, that it'd be best to actually just read the man pages and figure out how to get sshd to ignore any attempt to attach from ports other than 22. I mean, why are other machines trying to ssh in at ports over fifty thousand anyway? -- -JC http://www.livejournal.com/users/jcholewa/ PS: Oh, yeah ... FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 ; openssh-3.6.1_5 ; openssl-0.9.7d_1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: autoblocking many ssh failed logins from the same IP....
Below (and atached) is a script I wrote do exactly what you are talking about.
It's commented, so edit to your taste. I have been using to for about 4 months.
Since I am using PF as my firewall, it is customized for that. If you
are using something other then PF, again... edit to your taste.
-Erik-
#!/usr/bin/perl
# created by [EMAIL PROTECTED] 03/05
my $time=localtime();
use strict;
use Time::localtime;
use Mail::Send;
my $hostname=domain.orIP.com;
#The white list that contains either the account or host.
my $whilelist=/home/user/scripts/sshwhitelist;
#LOG to search on
my $logfile=/var/log/auth.log;
#Where to read the current list of blackhole address.
my $blacklist=/etc/pf.blackholes;
#Name of the table in your pf.conf
my $tablename=blackhole;
#Where to store the cache file. This is removed and updated daily
my $cache=/root/.sshprotect.cache;
#Where to log actions taken.
my $log=/root/sshprotect.log;
#Command you want to run in response of a potential attack.
my $command=whois;
my $useip=1; #useful in conjunction with $command which will do
something with the IP.
#comment out if not needed.
#Max attempts a host can have until blocked.
my $attempts=5;
# Set this to run the $command or print a report or email the report,
# also update will update the $blacklist and reload the blackholes table.
# abuse will try to find and email the offending network about the attack
# These can be combind to run all actions:
#my $action=run print;
#my $action=print;
my $action=email run update abuse;
#my $action=print email update;
#my $action=print email;
#Email setup;
my $to=[EMAIL PROTECTED];
my $from=[EMAIL PROTECTED];
my $cc=;
my $subject=Excesssive login attempts;
my $debug=0;
my $host;
my @logs;
my @whtlst;
my %track;
my @blacklist;
my $block=1;
my @abuse;
my @cache;
my $currentcache;
my @runoutput;
my $version=1.2.1beta;
print Version: $version\n if $debug;
#find todays datemask
use vars qw($yr $mon $day $today $mday);
$yr=localtime-year() + 1900;
$mon=localtime-mon() + 1;
$mday=localtime-mday();
if ($mon != /\d\d/) {$mon=0$mon;}
if ($mday 10) {$mday=0$mday;}
$today=$yr$mon$mday;
print $today\n if $debug;
#no Time::localtime;
open (WRITELOG, $log) || die $log $!\n;
open (BLACK,$blacklist) || die $blacklist $!\n;
while (BLACK) {
chomp;
push (@blacklist, $_);
}
close BLACK;
open (WHITE, $whilelist) || die $whilelist $!\n;
while (WHITE) {
chomp;
push (@whtlst,$_);
}
close WHITE;
open (READCACHE, $cache) || print $cache $!\n;
while (READCACHE) {
chomp;
push (@cache, $_);
}
close READCACHE;
open (WRITECACHE, $cache) || print $cache $!\n;
if (@cache[0] $today) {
close WRITECACHE;
system (rm -f $cache);
open (WRITECACHE, $cache) || print $cache $!\n;
print Cache file is out of date @cache[0] $today\n if $debug;
@cache=();
print WRITECACHE $today\n
}
open (LOG, $logfile) || die logfile $!;
while (LOG) {
chomp;
if (
/Failed password for illegal user (.*) from (.*) port/
|| /Failed password for (.*) from (.*) port/
|| /Illegal user (.*) from (.*)/
|| /Did not (receive) identification string from (.*)/
) {
my $account=$1;
my $host=$2;
ckwhtlst($account, $host);
if ($block == 0 ) { next; }
ckcache($host);
if ($block == 0 ) { next; }
ckblklst($host);
if ($block == 0 ) { next; }
$block=1;
if ($track{$host}) {
$track{$host}=$track{$host}+1;
print $host is now $track{$host} user=$account\n if $debug;
} else { $track{$host}=1; }
}
}
close LOG;
for my $host (%track) {
if (!$host) {print Nothing Found\n; exit;}
if ($track{$host} = $attempts) {
push (@abuse,$host);
ckcache($host);
print WRITECACHE $host\n if !$block == 0;
if ($action =~ /print/) { print Host $host, past $attempts
attempted logins\n; }
if ($action =~ /run/ $useip) { (@runoutput=`$command $host`); }
if ($action =~ /run/ !$useip) { (@runoutput=`$command`); }
if ($action =~ /update/) { update($host); }
}
}
#Sends emails
if ($action !~/email/) {
exit;
} elsif (@abuse) {
send_email(@abuse);
}
if ($action !~/abuse/) {
exit;
} elsif (@abuse) {
abuse_email(@abuse);
}
sub ckwhtlst {
(my $account, my $host)[EMAIL PROTECTED];
foreach (@whtlst) {
if (!/$account|$host/) {
$block=1;
return;
} else {
print $host or $account is on the while list.\n if $debug;
$block=0;
return;
}
}
}
sub ckblklst {
my [EMAIL PROTECTED];
foreach (@blacklist) {
if (/$host/) {
print $host $_ is already blacklisted\n if $debug;
$block=0;
return;
} else { $block=1; } #print $host is NOT blacklisted\n if $debug; }
}
}
sub ckcache {
my [EMAIL PROTECTED];
if ([EMAIL PROTECTED]) { $block=1; return;}
foreach (@cache) {
if (/$host/) {
$block=0;
print $host is already cached\n if $debug;
return;
} else { $block=1; } #print $host is not found in cache\n if $debug; }
}
}
sub update {
open (OUT
RE: autoblocking many ssh failed logins from the same IP....
they are originating from the high ports, arriving on port 22 at your box. this is normal. in a default setup sshd only listens on port 22. -- John Brooks [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Cholewa Sent: Friday, July 01, 2005 8:43 AM To: freebsd-questions@freebsd.org Subject: autoblocking many ssh failed logins from the same IP Jun 30 10:36:05 phantom sshd[70478]: Failed password for news from 212.88.182.121 port 51218 ssh2 Jun 30 10:36:16 phantom sshd[70500]: Failed password for sshd from 212.88.182.121 port 51608 ssh2 Jun 30 10:36:39 phantom sshd[70569]: Failed password for root from 212.88.182.121 port 52297 ssh2 I get the above a lot in my logs (except more of it). Each day, a couple hundred failed attempts to log in from one or sometimes two IP addresses shows up. I don't have anything like ipf running, and since this machine is about fifteen hundred miles away from me, I don't want to experiment with software firewalling right now. That known, is there any way to tell sshd (or some more powerful daemon) to stop accepting login attempts from a given IP if it tries and fails to log in too many times in a limited duration (like in the same minute)? I suppose, now that I'm thinking about it, that it'd be best to actually just read the man pages and figure out how to get sshd to ignore any attempt to attach from ports other than 22. I mean, why are other machines trying to ssh in at ports over fifty thousand anyway? -- -JC http://www.livejournal.com/users/jcholewa/ PS: Oh, yeah ... FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 ; openssh-3.6.1_5 ; openssl-0.9.7d_1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: autoblocking many ssh failed logins from the same IP....
he is using 4.8, unless things have changed, pf is not available on 4.x PS: Oh, yeah ... FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 ; openssh-3.6.1_5 ; openssl-0.9.7d_1 -- John Brooks [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hornet Sent: Friday, July 01, 2005 9:10 AM To: John Cholewa Cc: freebsd-questions@freebsd.org Subject: Re: autoblocking many ssh failed logins from the same IP Below (and atached) is a script I wrote do exactly what you are talking about. It's commented, so edit to your taste. I have been using to for about 4 months. Since I am using PF as my firewall, it is customized for that. If you are using something other then PF, again... edit to your taste. -Erik- snip ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: autoblocking many ssh failed logins from the same IP....
Defending Against Attacks A firewall is your first line of defense, But if you allow public access to ports 22, SSH (secure shell), 23, Telnet, or 21, FTP these ports can be bombarded with login attempts using common ID/PW combinations probing for access. In the case of port 80, Web server it can be bombarded with access requests designed to consume server resources resulting in a denial of service to legitimate user requests. To the firewall these all look like legitimate packets. Know Who Your Attacker is All most 98 percent of the attackers are script kiddies. Their attacks are all most totally based on indiscriminate rolling through a range of sequential IP address. (IE: They never use DNS to lookup your domain name.) You were found by plain bad luck. They run scripts that only address the know ports listened on by those services. You use this knowledge to defend against this type of attack. The simplest defense is to change the port numbers these services use. The /etc/services is where SSH, Telnet, and FTP port numbers are defined and where you would change them at. For Apache web server you specify the access port number in httpd.conf definitions. Remote clients who want to access your public services on the alternate port number will have to enter the alternate port number as part of the login command. After setting up alternate port numbers you can have your firewall log all access to ports 21,22,23,or 80 and report the abuse to the ISP owner of the sending IP address using the FreeBSD port ppars-1.0 Or if you don't want to use the automated Abuse reporting system you can take the sending IP address from your firewall log and do manual whois command to find the ISP owner of the offending IP address along with the ISP's abuse reporting email address and send your own email to them about their client sending you attack packets. Stopping Login Attacks Using the customary port numbers or alternate port numbers for SSH, FTP, or Telnet all failed logins are logged to /var/log/auth.log file. In most cases the sending IP address is the real IP address of the attacker. In the long term the solution is to do whois on the attackers IP address and report him to the ISP who owns the IP address. In the short term to stop the login attack in progress many people will add a deny this IP address rule to their firewall rule set file. Yes this will stop the attack immediately, but when a firewall keeps all these special deny this IP address rules the firewall becomes very hard to maintain as that list of denied IP address rules grows longer. A far better solution is to separate the denied IP address list from the firewall rule set. This can be done using the routed blackhole command. Example: To Add use route add -host attacker_ip 127.0.0.1 -blackhole To Delete use route delete -host attacker_ip 127.0.0.1 -blackhole To List use netstat -nr|grep 127 This is executed in the IP stack and is faster than in the firewall when you have over 20 of those special deny this IP address rules in the firewall. The attacker_ip in found in the log records in /var/log/auth.log file. You can create a script (route_blackholed_ip.sh) containing route commands for all the IP address that have attacked you in the past and save it to /usr/local/etc/rc.d/ so it will be run at boot time. The same process used by the abuse reporting system to process the /var/log/security log file can be modified by you to automate the processing of the /var/log/auth.log file to create the route blackhole commands on the fly while the attack is occurring. Stopping Web Server attacks Web server attacks are denial of service (Dos) attacks. There is no trigger that will notify you when this occurs. Most likely your first warning something is wrong is when people start asking you why is your web server down. When you have reason to suspect your web server is under attack you can check /var/log/hpptd-access.log file. This log file gets a log record for every file accessed by your web server. Part of the log record is the requesting IP address or it's DNS name. When you see a lot of log records (in the hundreds) from the same IP address, that is your attacker. In most all cases the requesting IP address is spoofed. Spoofed means the IP address is a real public internet routable IP address belonging to a legitimate user that unknown to him, the attacker has used to hide his real identity. Like with Login attacks you can add a special deny this IP address rule to your firewall rule set file or use the routed blackhole command. The same process used by the abuse reporting system to process the /var/log/security log file can be modified by you to automate the processing of the /var/log/hpptd-access.log file to create the route blackhole commands on the fly while the attack is occurring. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Cholewa Sent: Friday, July 01, 2005 9:43 AM
where are failed logins logged at
For SSH, telnet and FTP where are the failed login attempts logged at? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where are failed logins logged at
On Fri, Jun 03, 2005 at 05:42:54PM -0400, fbsd_user wrote: For SSH, telnet and FTP where are the failed login attempts logged at? Probably at /var/log/auth.log. Take a look at /etc/syslog.conf, you can configure things to your tastes from there. Nathan pgpzFntat5dUR.pgp Description: PGP signature
Re: HELP!! sshd permitting password free logins
On Sun, Feb 13, 2005 at 11:54:15PM -0600, Gene wrote: snip - problem: sshd apparently allowing passwordless logins Also, check to make sure your ssh client is not sending an RSA key for authentication. I think that one is enabled by default. If you want to force passwords, make sure you aren't using RSA keys. If disable RSA keys in the config file, but the problem persists. How about running the client in verbose mode, or perhpas the server, too. I don't know what sort of verbosity options putty has, but the standard openssh client can take a -v argument (repeated up to 3 times for maximum verbosity. The server can also be launced in the foregroud with debugging option -d, which like the client can be specified up to 3 times. The messages that come are displayed for both the client and server are a bit cryptic sometimes, but they are human readable and may well give you a place to start looking. Nathan pgpdXg4Er6pCU.pgp Description: PGP signature
HELP!! sshd permitting password free logins
I'm running version 5.3 of freebsd. I'm not sure what I did - I was experimenting in sshd_config. sshd began to permit logins without benefit of password. When logging in (I'm using putty from a local windows machine) I enter the user name. I'm presented with the challenge and the password prompt. If hit enter I get the second password prompt with echo on. If I enter anything else to the first password prompt, or anything (or just the enter key) to the second prompt, I find myself logged on. The allow groups directive in the config file works, only members of grp1 get logged on, but without passwords. This was working correctly before I started fooling around - any ideas? Cinfig file follows: #$OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $ #$FreeBSD: src/crypto/openssh/sshd_config,v 1.33 2003/09/24 19:20:23 des Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. # Note that some of FreeBSD's defaults differ from OpenBSD's, and # FreeBSD has a few additional options. #VersionAddendum FreeBSD-20030924 #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 3600 #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin no #StrictModes yes #RSAAuthentication yes PubkeyAuthentication no AuthorizedKeysFile.ssh/authorized_keys AllowGroups grp1 # rhosts authentication should not be used #RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no PermitEmptyPasswords no # Change to no to disable PAM authentication ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #AFSTokenPassing no # Kerberos TGT Passing only works with the AFS kaserver #KerberosTgtPassing no #X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes KeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #MaxStartups 10 # no default banner path #Banner /some/path #VerifyReverseMapping no # override default of no subsystems Subsystemsftp/usr/libexec/sftp-server ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HELP!! sshd permitting password free logins
On February 13, 2005 04:10 pm, Gene wrote: I'm running version 5.3 of freebsd. I'm not sure what I did - I was experimenting in sshd_config. sshd began to permit logins without benefit of password. When logging in (I'm using putty from a local windows machine) I enter the user name. I'm presented with the challenge and the password prompt. If hit enter I get the second password prompt with echo on. If I enter anything else to the first password prompt, or anything (or just the enter key) to the second prompt, I find myself logged on. I'm not sure what you mean by a second password prompt. I've never seen SSH provide 2 password prompts. The allow groups directive in the config file works, only members of grp1 get logged on, but without passwords. This was working correctly before I started fooling around - any ideas? Check to make sure the user you are logging in as has a password. Also, check to make sure your ssh client is not sending an RSA key for authentication. I think that one is enabled by default. If you want to force passwords, make sure you aren't using RSA keys. Cinfig file follows: #$OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $ #$FreeBSD: src/crypto/openssh/sshd_config,v 1.33 2003/09/24 19:20:23 des Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. # Note that some of FreeBSD's defaults differ from OpenBSD's, and # FreeBSD has a few additional options. #VersionAddendum FreeBSD-20030924 #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 3600 #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin no #StrictModes yes #RSAAuthentication yes PubkeyAuthentication no AuthorizedKeysFile.ssh/authorized_keys AllowGroups grp1 # rhosts authentication should not be used #RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no PermitEmptyPasswords no # Change to no to disable PAM authentication ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #AFSTokenPassing no # Kerberos TGT Passing only works with the AFS kaserver #KerberosTgtPassing no #X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes KeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #MaxStartups 10 # no default banner path #Banner /some/path #VerifyReverseMapping no # override default of no subsystems Subsystemsftp/usr/libexec/sftp-server ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Ean Kingston E-Mail: ean AT hedron DOT org URL: http://www.hedron.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HELP!! sshd permitting password free logins
Ean Kingston wrote: On February 13, 2005 04:10 pm, Gene wrote: I'm running version 5.3 of freebsd. I'm not sure what I did - I was experimenting in sshd_config. sshd began to permit logins without benefit of password. When logging in (I'm using putty from a local windows machine) I enter the user name. I'm presented with the challenge and the password prompt. If hit enter I get the second password prompt with echo on. If I enter anything else to the first password prompt, or anything (or just the enter key) to the second prompt, I find myself logged on. I'm not sure what you mean by a second password prompt. I've never seen SSH provide 2 password prompts. Login accounts use opie. Once the user name is entered, a challenge is displayed followed by a password prompt. Entered passwords at this prompt do not echo. Normally, if you enter just a return, another prompt appears with the notation [echo on] and the entered password is echoed as it is entered. The allow groups directive in the config file works, only members of grp1 get logged on, but without passwords. This was working correctly before I started fooling around - any ideas? Check to make sure the user you are logging in as has a password. Also, check to make sure your ssh client is not sending an RSA key for authentication. I think that one is enabled by default. If you want to force passwords, make sure you aren't using RSA keys. If disable RSA keys in the config file, but the problem persists. Cinfig file follows: #$OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $ #$FreeBSD: src/crypto/openssh/sshd_config,v 1.33 2003/09/24 19:20:23 des Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. # Note that some of FreeBSD's defaults differ from OpenBSD's, and # FreeBSD has a few additional options. #VersionAddendum FreeBSD-20030924 #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 3600 #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin no #StrictModes yes RSAAuthentication no PubkeyAuthentication no AuthorizedKeysFile.ssh/authorized_keys AllowGroups grp1 # rhosts authentication should not be used #RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no PermitEmptyPasswords no # Change to no to disable PAM authentication ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #AFSTokenPassing no # Kerberos TGT Passing only works with the AFS kaserver #KerberosTgtPassing no #X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes KeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #MaxStartups 10 # no default banner path #Banner /some/path #VerifyReverseMapping no # override default of no subsystems Subsystemsftp/usr/libexec/sftp-server ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: limiting ssh logins
dave wrote: Hello, I'm wondering if it's possible to use pam or perhaps tcp_wrappers to limit how many ssh logins can be atempted? I'd like to kick off a user who tries to log in repeatedly with the wrong password or tries x times within a minute, my purpose is to slow down hacking atempts in situations where public key authentication is not possible. Thanks. Dave. # man login.conf | grep -A 5 -B 5 retries login_prompt string The login prompt given by login(1) login-backoffnumber3 The number of login attempts allowed before the backoff delay is inserted after each subsequent attempt. login-retriesnumber10The number of login attempts allowed before the login fails. passwd_formatstringmd5 The encryption format that new or changed passwords will use. Valid values include des, md5 and blf. NIS clients using a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
limiting ssh logins
Hello, I'm wondering if it's possible to use pam or perhaps tcp_wrappers to limit how many ssh logins can be atempted? I'd like to kick off a user who tries to log in repeatedly with the wrong password or tries x times within a minute, my purpose is to slow down hacking atempts in situations where public key authentication is not possible. Thanks. Dave. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: limiting ssh logins
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dave Sent: Saturday, November 13, 2004 9:22 To: [EMAIL PROTECTED] Cc: Drew Tomlinson Subject: limiting ssh logins Hello, I'm wondering if it's possible to use pam or perhaps tcp_wrappers to limit how many ssh logins can be atempted? I'd like to kick off a user who tries to log in repeatedly with the wrong password or tries x times within a minute, my purpose is to slow down hacking atempts in situations where public key authentication is not possible. Thanks. Dave. If you are using ipfw as your firewall, you can simply add a limit rule to port 22 (or whichever port ssh runs on). Refer to man ipfw. Regards S. Subhro Sankha Kar Block AQ-13/1, Sector V Salt Lake City PIN 700091 India smime.p7s Description: S/MIME cryptographic signature
RE: limiting ssh logins
See the MaxStartups parameter in the sshd_confg. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of dave Sent: Friday, November 12, 2004 7:52 PM To: [EMAIL PROTECTED] Cc: Drew Tomlinson Subject: limiting ssh logins Hello, I'm wondering if it's possible to use pam or perhaps tcp_wrappers to limit how many ssh logins can be atempted? I'd like to kick off a user who tries to log in repeatedly with the wrong password or tries x times within a minute, my purpose is to slow down hacking atempts in situations where public key authentication is not possible. Thanks. Dave. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
passwordless ssh logins _STILL_ not working - help needed.
I am trying to allow _all users_ on CLIENT to login to SERVER without a password. IMPORTANT: I am not interested in user keys _at all_ - at no point in this process should I ever be dealing with any keys in /home/user/.ssh - I am only interested in doing this with HOST keys - where I copy one key between SERVER and CLIENT, and _all_ users on CLIENT can login to SERVER without a password. Don't even mention user keys. My /etc/sshd/sshd_config is exactly the same on both SERVER and CLIENT: #VersionAddendum FreeBSD-20020629 #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # Authentication: IgnoreRhosts yes #RhostsRSAAuthentication no HostbasedAuthentication yes IgnoreUserKnownHosts yes ChallengeResponseAuthentication no Further, SERVER has CLIENT in its /etc/hosts.equiv, and CLIENT has SERVER in its /etc/hosts.equiv Finally, I have copied the output of /etc/sshd/ssh_host_rsa_key.pub on each system to /etc/ssh/known_hosts on the other system. The permissions on /etc/ssh/known_hosts on each system are: 2 -rw-r--r-- 1 root wheel So that's it. The options are set in sshd_config, the keys have been exchanged, hosts.equiv are populated and permissions are correct. SO now I go to CLIENT and run: ssh [EMAIL PROTECTED] and I get a password prompt!!! So what am I doing wrong ? Again - NO user keys are used and I am not interested in user keys _AT ALL_. DOn't even mention the /home/user/.ssh directory. The goal here is to share one public key between SERVER and CLIENT and allow _all_ users on CLIENT to log into SERVER without a password. So what am I doing wrong ? thanks. ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passwordless ssh logins _STILL_ not working - help needed.
ssh [EMAIL PROTECTED] and I get a password prompt!!! You have to press enter ;) FreeBSD still asks for a password even if it's empty, unlike Linux. Cheers, Jorn. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Where'd it go (restricting remote logins)
In version 4.7, there was a conf file where individual users could be granted or denied the ability to log in remotely. Since 5.2, I can no longer find the file (I don't recall its name). Anyone know which file it was? Does the ability still exist? Thanks _ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Logins without full password!
On Mon, Aug 27, 2001 at 02:15:22AM -0500, default wrote: Is this normal? It's the expected behaviour for legacy DES passwords (only useful if you need to share the same password file with other UNIX systems, which isn't likely) How does one disable this? There's a login capability for setting the default password format (MD5 is the one you want) -- see login.conf(5). Kris pgphsn6BSVPvT.pgp Description: PGP signature
Re: increasing failed sshd logins/clearing breadcrumb trails
Date: Wed, 15 Sep 2004 12:21:29 +0930 From: Tim Aslat [EMAIL PROTECTED] Subject: Re: increasing failed sshd logins/clearing breadcrumb trails To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Tim Aslat [EMAIL PROTECTED] once said: In the immortal words of Glenn Sieb [EMAIL PROTECTED]... I've been getting this for weeks. They're all under APNIC, and emails to [EMAIL PROTECTED] involved networks has gone unanswered. I've been getting these as well, but from a multitude of address spaces. Not just APNIC. The easiest way to protect this is to check your sshd_config and set: PermitRootLogin no Interestingly, this option did not exist in my config file (I added it), but all other options were commented out. Is this the default? Is it wise to leave it this way? Agreed. However if you 'Absolutely' require something to be done remotely as root, make it a pub/priv key sequence and limit the command using the keys. ie: change sshd_config to PermitRootLogin without-password and set up command=/usr/local/bin/rsync --server --daemon . ssh-dss snip actual key in the authorized_keys file. This limits the abilities of the remoe login to just running the rsync command with the specified switches. Anything else just doesn't work. Which, if you're exposed to the 'Net would be a sane practice--force people to log in as themselves and su (or sudo or sudoscript) to root. Very sane practice Indeed. Admittedly, I am not sure about the rest of your posting. When I run last, (on 4.10-STABLE) it shows logins back to the 1st of September. It is possible that the box was compromised and the utmp/wtmp log removed/edited/etc, and I would start looking immediately for other traces of a possible intrusion. My current wtmp log, which dates from today back to Aug 30, is quite small and shows only two logins... I've logged in twice since reporting this incident to the list. There exists no utmp file in /var/log/. I'm really starting to feel as if the machine were compromised, or at least perused, and my utter lack of security knowledge has become glaringly apparent. What other traces could I look for; what other files might give me a clue? And where would I begin looking for files that might have been planted on the machine (scripts, server threads)? Cheers good luck Thanks, but it doesn't seem any luck I've got at this point would be good Tim ~John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing failed sshd logins/clearing breadcrumb trails
John DeStefano said the following on 9/16/2004 10:40 AM: The easiest way to protect this is to check your sshd_config and set: PermitRootLogin no Interestingly, this option did not exist in my config file (I added it), but all other options were commented out. Is this the default? Is it wise to leave it this way? Yes--it's in man sshd_config: PermitRootLogin Specifies whether root can login using ssh(1). The argument must be ``yes'', ``without-password'', ``forced-commands-only'' or ``no''. The default is ``no''. Note that if ChallengeResponseAuthentication is ``yes'', the root user may be allowed in with its password even if PermitRootLogin is set to ``without-password''. If this option is set to ``without-password'' password authenti- cation is disabled for root. If this option is set to ``forced-commands-only'' root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed). All other authentication methods are disabled for root. If this option is set to ``no'' root is not allowed to login. Best, Glenn -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. ~Benjamin Franklin, Historical Review of Pennsylvania, 1759 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
increasing failed sshd logins/clearing breadcrumb trails
I've noticed a few posts over the past week or so regarding users' servers being probed by remote ssh attempts. Coincidentally (or perhaps not so), around that time, I began getting quite a few records of such attempts to my server, at the rate of about 3 tries per IP, and about three IPs per night. Unfortunately, last night (Mon Sep 13), this attack was much more concentrated and persistent: someone from (or spoofing from) one IP (211.250.185.100) hammered my server with login attempts over a 20-minute period. The last report I got was a final, failed root password at 20:22:13 Eastern Time (GMT-5:00). I just read this record and logged into my server, and ran last, which gave me a blank record, saying only: wtmp begins Tue Sep 14 22:01:55 EDT 2004 ...which happened to be the exact time I just logged into my server. I'm wondering if it is a normal clean-up occurrance for the 'last' log to turn over at a certain time/date, or if this ssh-er finally got into my system and cleaned up his/her tracks? I realize the power of one who has root privelages, but what logs would they have wiped out to remain invisible, and what others might I have a possible chance of looking at to determine what happened? ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing failed sshd logins/clearing breadcrumb trails
John DeStefano said the following on 9/14/2004 10:15 PM: I've noticed a few posts over the past week or so regarding users' servers being probed by remote ssh attempts. Coincidentally (or perhaps not so), around that time, I began getting quite a few records of such attempts to my server, at the rate of about 3 tries per IP, and about three IPs per night. Unfortunately, last night (Mon Sep 13), this attack was much more concentrated and persistent: someone from (or spoofing from) one IP (211.250.185.100) hammered my server with login attempts over a 20-minute period. The last report I got was a final, failed root password at 20:22:13 Eastern Time (GMT-5:00). I've been getting this for weeks. They're all under APNIC, and emails to [EMAIL PROTECTED] involved networks has gone unanswered. The easiest way to protect this is to check your sshd_config and set: PermitRootLogin no Which, if you're exposed to the 'Net would be a sane practice--force people to log in as themselves and su (or sudo or sudoscript) to root. Admittedly, I am not sure about the rest of your posting. When I run last, (on 4.10-STABLE) it shows logins back to the 1st of September. Best, Glenn ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing failed sshd logins/clearing breadcrumb trails
In the immortal words of Glenn Sieb [EMAIL PROTECTED]... I've been getting this for weeks. They're all under APNIC, and emails to [EMAIL PROTECTED] involved networks has gone unanswered. I've been getting these as well, but from a multitude of address spaces. Not just APNIC. The easiest way to protect this is to check your sshd_config and set: PermitRootLogin no Agreed. However if you 'Absolutely' require something to be done remotely as root, make it a pub/priv key sequence and limit the command using the keys. ie: change sshd_config to PermitRootLogin without-password and set up command=/usr/local/bin/rsync --server --daemon . ssh-dss snip actual key in the authorized_keys file. This limits the abilities of the remoe login to just running the rsync command with the specified switches. Anything else just doesn't work. Which, if you're exposed to the 'Net would be a sane practice--force people to log in as themselves and su (or sudo or sudoscript) to root. Very sane practice Admittedly, I am not sure about the rest of your posting. When I run last, (on 4.10-STABLE) it shows logins back to the 1st of September. It is possible that the box was compromised and the utmp/wtmp log removed/edited/etc, and I would start looking immediately for other traces of a possible intrusion. Cheers good luck Tim -- Tim Aslat [EMAIL PROTECTED] Spyderweb Consulting http://www.spyderweb.com.au Phone: +61 0401088479 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing failed sshd logins/clearing breadcrumb trails
Tim Aslat said the following on 9/14/2004 10:51 PM: In the immortal words of Glenn Sieb [EMAIL PROTECTED]... I've been getting this for weeks. They're all under APNIC, and emails to [EMAIL PROTECTED] involved networks has gone unanswered. I've been getting these as well, but from a multitude of address spaces. Not just APNIC. I should have been clearer--the ones coming in on *my* server have all been from APNIC :-/ Agreed. However if you 'Absolutely' require something to be done remotely as root, make it a pub/priv key sequence and limit the command using the keys. *nod* But I really can't think of any reason to have an exposed machine allow a direct-root login... Probably I just haven't had that particular need or experience yet... But with protected machines? Sure--at my old job (at Lumeta) we had our one trusted machine which was allowed to ssh as root (using keys only) to our internal machines. For purposes of pushes/pulls/upgrades/stuff along those lines. Very sane practice *nod* I'd like to think Tal rubbed off on me a bit :) It is possible that the box was compromised and the utmp/wtmp log removed/edited/etc, and I would start looking immediately for other traces of a possible intrusion. *nod* Hopefully he wasn't hacked--that would be major suckage :-/ Best, Glenn -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. ~Benjamin Franklin, Historical Review of Pennsylvania, 1759 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
logging all logins with periodic
I'm currently running FreeBSD 4.10 on a machine at home. Since it is exposed to the internet (and since I am the only one who should be logging into it), I would like to have a summary log of all logins (both failed and successful). periodic shows the the failed logins in the daily summary, but I would also like a summary of the successful logins. I've google-ed, checked the list archives, and looked at the period.conf man page, but I can't seem to find a way to do what I want. However, I'm sure I'm not the first person to want this functionality. Can periodic be used to get a summary of successful logins? Is there a different utility that exists? Thanks in advance. Mike Eads ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: logging all logins with periodic
On Thu, Sep 02, 2004 at 03:34:25PM +, [EMAIL PROTECTED] wrote: I'm currently running FreeBSD 4.10 on a machine at home. Since it is exposed to the internet (and since I am the only one who should be logging into it), I would like to have a summary log of all logins (both failed and successful). periodic shows the the failed logins in the daily summary, but I would also like a summary of the successful logins. I've google-ed, checked the list archives, and looked at the period.conf man page, but I can't seem to find a way to do what I want. However, I'm sure I'm not the first person to want this functionality. Can periodic be used to get a summary of successful logins? Is there a different utility that exists? I don't think the periodic scripts have that capability. However, it's fairly simple to get a list of all logins on the system (except, for some unknown reason those logins via xdm(1) and similar graphical login managers). The command to use is last(1) -- note by default that reads /var/log/wtmp which is recycled each month via newsyslog(8). You can edit the /etc/daily.local script to get that output included in your daily e-mails. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp8KyFCdYeIL.pgp Description: PGP signature
Re: logging all logins with periodic
On 2004-09-02 17:41, Matthew Seaman [EMAIL PROTECTED] wrote: On Thu, Sep 02, 2004 at 03:34:25PM +, [EMAIL PROTECTED] wrote: Can periodic be used to get a summary of successful logins? Is there a different utility that exists? The command to use is last(1) -- note by default that reads /var/log/wtmp which is recycled each month via newsyslog(8). You can edit the /etc/daily.local script to get that output included in your daily e-mails. Hint: $ last | grep $(date '+%b %e') giorgos ttyv1 Thu Sep 2 22:07 still logged in toor ttyv0 Thu Sep 2 22:06 still logged in toor ttyv0 Thu Sep 2 08:39 - shutdown (02:11) $ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
logins
I've beend getting the sshd login attempts, like everyone else so I've been watching the logs close, this is the first time to see this item in /var/log/messages. Aug 14 04:15:00 chillico su: _secure_path: /nonexistent/.login_conf is not owned by uid 65534 I've looked in the passwd file and groups, there is not a uid of 65534 listed. I installed rsync last week to backup some windows computers during the weekend, this would have been during one of the backups, but the other five would have triggered the same msg, just thinking outloud here. Any idea what would have made this entry?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: logins
Mark [EMAIL PROTECTED] writes: I've beend getting the sshd login attempts, like everyone else so I've been watching the logs close, this is the first time to see this item in /var/log/messages. Aug 14 04:15:00 chillico su: _secure_path: /nonexistent/.login_conf is not owned by uid 65534 The machine doesn't have a '/nonexistent/' directory, does it? It is important security-wise that such a directory must *not* exist. I've looked in the passwd file and groups, there is not a uid of 65534 listed. There *should* be; it's nobody. And it shouldn't be in the wheel group. I installed rsync last week to backup some windows computers during the weekend, this would have been during one of the backups, but the other five would have triggered the same msg, just thinking outloud here. Unless /nonexistent got created during the process... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: logins
On Tue, Aug 17, 2004 at 11:17:46AM -0400, Lowell Gilbert wrote: Mark [EMAIL PROTECTED] writes: I've beend getting the sshd login attempts, like everyone else so I've been watching the logs close, this is the first time to see this item in /var/log/messages. Aug 14 04:15:00 chillico su: _secure_path: /nonexistent/.login_conf is not owned by uid 65534 The machine doesn't have a '/nonexistent/' directory, does it? It is important security-wise that such a directory must *not* exist. It was there but is now gone. I've looked in the passwd file and groups, there is not a uid of 65534 listed. There *should* be; it's nobody. And it shouldn't be in the wheel group. You are right nobody does have that uid and it's not in the wheel group. I installed rsync last week to backup some windows computers during the weekend, this would have been during one of the backups, but the other five would have triggered the same msg, just thinking outloud here. Unless /nonexistent got created during the process... thanks, After deleteing the nonexistent dir, I thought about the creation date and time stamp. =( __ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- -- ** The information contained in this communication is confidential, private, proprietary, or otherwise privileged and is intended only for the use of the addressee. Unauthorized use, disclosure, distribution or copying is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately. ** == ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FTP (not anonymous) logins fail
I have FreeBSD 5.2.1-RELEASE-p3 installed on my system. For testing purposes, I have been temporarily suspending my ipfw firewall, then reenabling it when I take a break from testing. I have enabled ftp (IPV4 only) in inetd.conf. FTP connections and authentication from the localhost to itself always work. FTP connections made from the outside work, but authentication always fails. The user in question has tcsh as his shell, which is listed in /etc/shells. The user is NOT listed in /etc/ftpusers. I have not changed anything in PAM (which I still don't understand how to configure yet). The full path of the user's home directory is accessible to them. I have not done anything with groups. Does a user have to be in a magic ftpusers group in order to authenticate from the outside? My question for the group is: What else do I need to do to enable FTP logins for normal users (i.e., I don't want anonymous FTP) out-of-the-box? I could install ProFTP, but would like to try to use the default FTPd that comes with FreeBSD. I suspect that PAM is the reason why my authentications from the outside always fail, but authentications from localhost always succeed. Is PAM out-of-the-box set to deny all outside FTP connections? If so, what modifications to /etc/pam.d/ftpd do I need to make to allow FTP authentication from the outside to work? But, if you suspect something other than PAM, don't let me send you down the wrong path... Many thanks to anyone that can offer help. I've spent 4 days on this and combed google and the archives of this listserv for the answer, but have come up empty. TIA, Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: S/KEY ftp logins
On Mon, 8 Mar 2004 15:31:50 - , in local.freebsd.questions you wrote: Is there some way to tell if ftp logins are successfully using S/KEY or falling back to cleartext? Is there some way to require S/KEY only? I believe the password prompt includes required if a static password would not be accepted. As I recall if you create /etc/skey.access then everything which is *not* mentioned in that file will require s/key. I think this also applies to shell logins so you need to be careful. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
S/KEY ftp logins
Is there some way to tell if ftp logins are successfully using S/KEY or falling back to cleartext? Is there some way to require S/KEY only? Cliff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Grumpy 'xdm' won't take logins
John Mills [EMAIL PROTECTED] writes: I just finished a fairly lightweight ftp installation of 5.1-Release and want to offer an X11 login screen. Basic XF86 seems to work fine. I followed the 'Configuring xdm' instructions in Greg Lehey's _Complete_FreeBSD_, ch.17, but didn't get quite all the way home. I get the X11 login screen, mouse moves OK, but I never seem to focus the username or password entry panels so that my keystrokes are seen. Neither can I change to one of the other vt's (though I get 'bell' sounds on those which should exist). The server seems to have gone both modal and deaf. Hmm. I'm pretty rusty on configuring X, but my first reaction is: What happens when you try to start X with startx? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Grumpy 'xdm' won't take logins
Freebies - I just finished a fairly lightweight ftp installation of 5.1-Release and want to offer an X11 login screen. Basic XF86 seems to work fine. I followed the 'Configuring xdm' instructions in Greg Lehey's _Complete_FreeBSD_, ch.17, but didn't get quite all the way home. I get the X11 login screen, mouse moves OK, but I never seem to focus the username or password entry panels so that my keystrokes are seen. Neither can I change to one of the other vt's (though I get 'bell' sounds on those which should exist). The server seems to have gone both modal and deaf. Suggestions appreciated. TIA. - John Mills [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Setting Default Execution Path for ssh Logins using Bash
Martin McCormick [EMAIL PROTECTED] writes: Where is the default execution path set for ssh logins who get a bash shell? Originally from login capabilities; it can be modified in a number of other places as described in the bash(1) manual. I thought I knew the answer until I tried to change it on a system that is giving everyone a path that needs /usr/local/etc in it. I *think* you're saying that the users don't have that directory in their path, but you'd like them to. The handbook mentions login.conf which I did modify with no effect. You ran cap_mkdb(1)? I think, in the past, I modified the .bash_profile or maybe the skeleton bash profile, but there should be a way to give all new logins and new accounts the correct path but I can't seem to find anything in the handbook that looks promising or anything that, when modified changes the path. That depends on whether the shells are login shells or not. I think you can set up ssh to handle it either way. If they are, then you can put configuration in /etc/profile (I think that's the file, anyway). But the login database should be the way to do it. Good luck. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Restricting logins by terminal
I would like to restrict user login based on the terminal where the login request originates. Ideally, I want Root, and ONLY Root, to be able to log in at the console. The system is already running SSHD, so I want to be able to check logins via SSH. Root should not be allowed to log in from a remote terminal and SU should be disabled for any remote terminal. Is there something in the ports collection that I've missed that will do this? Maybe I'm just blind and haven't yet seen something like this in the manual. THanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Restricting logins by terminal
On Wed, Jul 09, 2003 at 01:14:06PM -0400, Charley wrote: I would like to restrict user login based on the terminal where the login request originates. Ideally, I want Root, and ONLY Root, to be able to log in at the console. The system is already running SSHD, so I want to be able That's more than possible. Take a look at /etc/login.access and /etc/login.conf. In login.access a simple: -:ALL EXCEPT root # taken from the examples near the end (which actual use groups) should do the trick. to check logins via SSH. Root should not be allowed to log in from a remote That's all defined in your sshd config (by default root cannot login via sshd). If you're really paranoid, the second example in login.access: -:root:ALL EXCEPT LOCAL # instead of considering root, the ``wheel'' group might be better. terminal and SU should be disabled for any remote terminal. Is there By default, only members of the wheel group can su to root. something in the ports collection that I've missed that will do this? Maybe I'm just blind and haven't yet seen something like this in the manual. Well, I don't know exactly what you want to do... but ``su'' is setuid root, so you could unset that and use the ``sudo'' command. Take a look at security/sudo in the ports collection. That'd be quite contrived though. Best wishes, -lewiz. P.S. Some of my examples might not work -- I didn't test them and I'm shocking for getting things to work first time. -- Why was I born with such contemporaries? -- Oscar Wilde -| msn:[EMAIL PROTECTED] | jab:[EMAIL PROTECTED] | url:http://lewiz.net |- pgp0.pgp Description: PGP signature
strange messages in /var/log and all logins refused ...
Hey *, this morning I tried to log into my freebsd 4.6 release box and was refused (SSH 2.9 sent back the passwd prompt and denied me). I called someone else and they tried, and were refused too. I got in via the console and reset my user and the root passwd and could ssh in successfully. I'm thinking that the /etc/master.passwd file may have been corrupted. Is there any way to check this? Also, I found some strange output in /var/log/messages.0.gz on the machine that locked up. There is an identical machine (same hardware and config) that did *not* have any of this stuff. The last line in the message below (the Device not configured) is repeated hundreds of times. I've pasted it below ... does anyone know what this indicates? I tried google, but found nothing conclusive. Jul 3 10:00:00 mas02 newsyslog[14137]: logfile turned over Jul 3 10:50:32 mas02 /kernel: (da0:ahc0:0:0:0): Invalidating pack Jul 3 10:51:29 mas02 /kernel: (da0:ahc0:0:0:0): SCB 0x11 - timed out Jul 3 10:51:29 mas02 /kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x9 Jul 3 10:51:29 mas02 /kernel: ACCUM = 0x0, SINDEX = 0xa, DINDEX = 0xe4, ARG_2 = 0x0 Jul 3 10:51:29 mas02 /kernel: HCNT = 0x0 SCBPTR = 0x18 Jul 3 10:51:29 mas02 /kernel: SCSISEQ = 0x12, SBLKCTL = 0xa Jul 3 10:51:29 mas02 /kernel: DFCNTRL = 0x0, DFSTATUS = 0x89 Jul 3 10:51:29 mas02 /kernel: LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80 Jul 3 10:51:29 mas02 /kernel: SSTAT0 = 0x0, SSTAT1 = 0x8 Jul 3 10:51:29 mas02 /kernel: SCSIPHASE = 0x0 Jul 3 10:51:29 mas02 /kernel: STACK == 0x3, 0x108, 0x160, 0x0 Jul 3 10:51:29 mas02 /kernel: SCB count = 80 Jul 3 10:51:29 mas02 /kernel: Kernel NEXTQSCB = 23 Jul 3 10:51:29 mas02 /kernel: Card NEXTQSCB = 23 Jul 3 10:51:29 mas02 /kernel: QINFIFO entries: Jul 3 10:51:29 mas02 /kernel: Waiting Queue entries: Jul 3 10:51:29 mas02 /kernel: Disconnected Queue entries: 18:17 Jul 3 10:51:29 mas02 /kernel: QOUTFIFO entries: Jul 3 10:51:29 mas02 /kernel: Sequencer Free SCB List: 24 3 27 28 15 10 9 22 19 17 5 8 11 12 26 14 1 6 4 2 20 16 31 25 21 23 7 30 13 29 0 Jul 3 10:51:29 mas02 /kernel: Sequencer SCB Info: 0(c 0x60, s 0x17, l 0, t 0xff) 1(c 0x60, s 0x17, l 0, t 0xff) 2(c 0x60, s 0x17, l 0, t 0xff) 3(c 0x60, s 0x17 , l 0, t 0xff) 4(c 0x60, s 0x17, l 0, t 0xff) 5(c 0x60, s 0x17, l 0, t 0xff) 6(c 0x60, s 0x17, l 0, t 0xff) 7(c 0x60, s 0x17, l 0, t 0xff) 8(c 0x60, s 0x17, l 0 , t 0xff) 9(c 0x60, s 0x17, l 0, t 0xff) 10(c 0x60, s 0x17, l 0, t 0xff) 11(c 0x60, s 0x17, l 0, t 0xff) 12(c 0x60, s 0x17, l 0, t 0xff) 13(c 0x60, s 0x17, l 0, t 0xff) 14(c 0x60, s 0x17, l 0, t 0xff) 15(c 0x60, s 0x17, l 0, t 0xff) 16(c 0x60, s 0x17, l 0, t 0xff) 17(c 0x60, s 0x17, l 0, t 0xff) 18(c 0x66, s 0x7, l 0, t 0x11) 19(c 0x60, s 0x17, l 0, t 0xff) 20(c 0x60, s 0x17, l 0, t 0xff) 21(c 0x60, s 0x17, l 0, t 0xff) 22(c 0x60, s 0x17, l 0, t 0xff) 23(c 0x60, s 0x17, l 0, t 0xff) 24(c 0x60, s 0x17, l 0, t 0xff) 25(c 0x60, s 0x17, l 0, t 0xff) 26(c 0x60, s 0x17, l 0, t 0xff) 27(c 0x60, s 0x17, l 0, t 0xff) 28(c 0x60, s 0x17, l 0, t 0xff) 29(c 0x60, s 0x17, l 0, t 0xff) 30(c 0x60, s 0x17, l 0, t 0xff) 31(c 0x60, s 0 Jul 3 10:51:29 mas02 /kernel: , t 0xff) Jul 3 10:51:29 mas02 /kernel: Pending list: 17(c 0x62, s 0x7, l 0) Jul 3 10:51:29 mas02 /kernel: Kernel Free SCB list: 10 38 57 62 20 12 7 16 27 11 28 19 40 56 33 43 36 47 48 13 45 21 78 58 64 49 69 18 5 22 55 39 51 65 52 59 6 66 2 37 25 4 41 14 35 29 68 34 61 54 30 60 3 42 15 79 46 53 31 63 0 32 26 24 44 67 9 50 8 1 77 76 75 74 73 72 71 70 Jul 3 10:51:29 mas02 /kernel: sg[0] - Addr 0x188dc000 : Length 4096 Jul 3 10:51:29 mas02 /kernel: sg[1] - Addr 0x2d11d000 : Length 4096 Jul 3 10:51:29 mas02 /kernel: sg[2] - Addr 0x24ede000 : Length 4096 Jul 3 10:51:29 mas02 /kernel: sg[3] - Addr 0x1615f000 : Length 4096 Jul 3 10:51:29 mas02 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jul 3 10:51:29 mas02 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 34a Jul 3 10:51:32 mas02 /kernel: (da0:ahc0:0:0:0): Invalidating pack Jul 3 12:00:02 mas02 /kernel: Connection attempt to TCP 127.0.0.1:25 from 127.0.0.1:1388 Jul 3 13:00:00 mas02 /kernel: Connection attempt to TCP 127.0.0.1:25 from 127.0.0.1:1389 Jul 3 14:00:00 mas02 /kernel: Connection attempt to TCP 127.0.0.1:25 from 127.0.0.1:1390 Jul 3 15:00:00 mas02 /kernel: Connection attempt to TCP 127.0.0.1:25 from 127.0.0.1:1391 Jul 3 16:14:40 mas02 last message repeated 17 times Jul 3 16:16:51 mas02 last message repeated 30 times Jul 3 20:15:00 mas02 /usr/sbin/cron[14546]: login_getclass: retrieving class information: Device not configured = --- Emo is what happens when the glee club goes punk. --- __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: strange messages in /var/log and all logins refused ...
On Mon, 7 Jul 2003, twig les wrote:
Also, I found some strange output in /var/log/messages.0.gz on
the machine that locked up. There is an identical machine (same
hardware and config) that did *not* have any of this stuff. The
last line in the message below (the Device not configured) is
repeated hundreds of times. I've pasted it below ... does
anyone know what this indicates? I tried google, but found
nothing conclusive.
Jul 3 10:00:00 mas02 newsyslog[14137]: logfile turned over
[...snip]
Jul 3 10:51:32 mas02 /kernel: (da0:ahc0:0:0:0): Invalidating
pack
Jul 3 12:00:02 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1388
Jul 3 13:00:00 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1389
Jul 3 14:00:00 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1390
Jul 3 15:00:00 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1391
Jul 3 16:14:40 mas02 last message repeated 17 times
Jul 3 16:16:51 mas02 last message repeated 30 times
Jul 3 20:15:00 mas02 /usr/sbin/cron[14546]: login_getclass:
retrieving class information: Device not configured
Your disk has died and the kernel has turned it off. This is bad
because it seems to be your root disk.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange messages in /var/log and all logins refused ...
I did a mount -a, then a fsck -y, then manually changed the
passwords back to what they were and the machine seems ok. df
-h shows both disks working fine and I can access the root and
all partitions. I hope this was just some stupid disk problem
that is *not* the harbinger of another disk death. Thnx.
BTW, what exactly pointed to a disk failure and why? I'm not a
programmer by profession (which is good bc I'm pretty bad at
it).
--- Andy Farkas [EMAIL PROTECTED] wrote:
On Mon, 7 Jul 2003, twig les wrote:
Also, I found some strange output in /var/log/messages.0.gz
on
the machine that locked up. There is an identical machine
(same
hardware and config) that did *not* have any of this stuff.
The
last line in the message below (the Device not configured)
is
repeated hundreds of times. I've pasted it below ... does
anyone know what this indicates? I tried google, but found
nothing conclusive.
Jul 3 10:00:00 mas02 newsyslog[14137]: logfile turned over
[...snip]
Jul 3 10:51:32 mas02 /kernel: (da0:ahc0:0:0:0):
Invalidating
pack
Jul 3 12:00:02 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1388
Jul 3 13:00:00 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1389
Jul 3 14:00:00 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1390
Jul 3 15:00:00 mas02 /kernel: Connection attempt to TCP
127.0.0.1:25 from 127.0.0.1:1391
Jul 3 16:14:40 mas02 last message repeated 17 times
Jul 3 16:16:51 mas02 last message repeated 30 times
Jul 3 20:15:00 mas02 /usr/sbin/cron[14546]: login_getclass:
retrieving class information: Device not configured
Your disk has died and the kernel has turned it off. This is
bad
because it seems to be your root disk.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow local logins when YP/NIS server unavailable.
On Sat, Jan 04, 2003 at 07:57:03PM -0500, Bill Moran wrote: If you set the laptop up as a NIS backup server, you'll be able to log in just fine, even when not connected to the network. It should circumvent the delays, as you'll have everything the login system is looking for. Yeah, I'd considered this myself and was going to implement it but after mentioning it in FreeBSD-mobile I got response saying it was a bit overkill (which, it would have been). Right now I've just got that code commented out in my login.c. The comment above the code says something along the lines of ``PAM may allocate more groups'' - I think that means that it provides the membership to all of the required groups. For me (at the moment) this is not an issue so I have now just compiled with that code disabled. It works perfectly but I really want to know what it's doing exactly, and whether it _should_ be causing a hang. Many thanks for your response, -lewiz. -- Misery loves company, but company does not reciprocate. --|| url: http://lewiz.info/ | http://www.westwood.karoo.net/pgpkey ||-- msg14300/pgp0.pgp Description: PGP signature
Slow local logins when YP/NIS server unavailable.
Hi,
I've been having problems recently trying to login as a local user
when my YP/NIS server is unavailable. This is essentially to me as the
machine in question is a laptop and is required to work without the
network.
I have a local user (lewiz2) and a NIS/YP user (lewiz). When I am
away from the network I use lewiz2, which has a homedir synchronized
with lewiz. When I return I resynchronize. This works perfectly.
However, I have come to find a problem in some code in login.c
(usr.bin/login). I have an up-to-date login.c (from 1859 today
(04/01/03)) and the code is from line 598 to line 601. It reads:
if (setusercontext(lc, pwd, pwd-pw_uid, LOGIN_SETGROUP) != 0) {
syslog(LOG_ERR, setusercontext() failed - exiting);
exit(1);
}
This means nothing to me but I have found that it causes local logins
(which have _nothing_ to do with NIS/YP whatsoever) to hang for a long
time. I am wondering if there is any way I can work around this problem
(without commenting out the code) and if this could be considered a
``bug''?
Any help on this matter would be greatly appreciated as it's been
causing me problems for ages ;)
Many thanks,
-lewiz.
--
When all other means of communication fail, try words.
--|| url: http://lewiz.info/ | http://www.westwood.karoo.net/pgpkey ||--
msg14245/pgp0.pgp
Description: PGP signature
Re: Slow local logins when YP/NIS server unavailable.
From: lewiz [EMAIL PROTECTED]
Hi,
I've been having problems recently trying to login as a local user
when my YP/NIS server is unavailable. This is essentially to me as the
machine in question is a laptop and is required to work without the
network.
I have a local user (lewiz2) and a NIS/YP user (lewiz). When I am
away from the network I use lewiz2, which has a homedir synchronized
with lewiz. When I return I resynchronize. This works perfectly.
However, I have come to find a problem in some code in login.c
(usr.bin/login). I have an up-to-date login.c (from 1859 today
(04/01/03)) and the code is from line 598 to line 601. It reads:
if (setusercontext(lc, pwd, pwd-pw_uid, LOGIN_SETGROUP) != 0) {
syslog(LOG_ERR, setusercontext() failed - exiting);
exit(1);
}
This means nothing to me but I have found that it causes local logins
(which have _nothing_ to do with NIS/YP whatsoever) to hang for a long
time. I am wondering if there is any way I can work around this problem
(without commenting out the code) and if this could be considered a
``bug''?
Any help on this matter would be greatly appreciated as it's been
causing me problems for ages ;)
I don't have the answer to your question, but I may be able to suggest
a workaround.
If you set the laptop up as a NIS backup server, you'll be able to log
in just fine, even when not connected to the network. It should
circumvent the delays, as you'll have everything the login system is
looking for.
Hope this helps,
Bill
_
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: disabling root logins
For console: edit /etc/ttys change secure to insecure for each tty that you wish to keep root out of. On Fri, 2002-11-15 at 01:54, Ian Barnes wrote: Hi, I would like to disable root logins, both at console and through ssh ... where should I start ? thanks for the help Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Matt Smith [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
disabling root logins
Hi, I would like to disable root logins, both at console and through ssh ... where should I start ? thanks for the help Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: disabling root logins
On Fri, 15 Nov 2002, Ian Barnes wrote: Hi, I would like to disable root logins, both at console and through ssh ... where should I start ? thanks for the help Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message http://www.onlamp.com/pub/a/bsd/2002/08/08/FreeBSD_Basics.html?page=2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
pam_radius and logins (2nd request for help)
Hello, I am attempting to centralize login credentials via RADIUS, as opposed to the current [evil] NIS. Currently, a telnet to my RADIUS authenticated [PAM] host goes like this: su-2.05a# telnet localhost Trying 127.0.0.1... Connected to localhost.mfn.org. Escape character is '^]'. Trying SRA secure login: User (root): test Password: --- RADIUS PW is accepted according [ SRA accepts you ] to logs. FreeBSD/i386 (STEELMILL) (ttyp1) RADIUS password:--- RADIUS again sends an accept, but... Login incorrect login: It looks to me like telnetd is getting it right, but the login process is missing it. I have tried many variation of the default pam.conf with no changes. I have noticed that if I place a passwd entry for test, using * for the password, auth works. This led me to try using template_user=nobody, without success. Does anybody have RADIUS auth working for direct logins? (The NAS are fine, it's just telnet/login/ssh on the BSD boxen themselves that are borked... Please copy me directly, as I am not currently subscribed. P.S. How's 5.0 looking for the targeted release date? Inquiring daemons want to know! -- Yours, J.A. Terranson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
