Re: ntpd listening on alias interfaces seems non-trivial
Ntp uses its own protocol on top of UDP. Each ntp packet includes source and destination addresses of the communication. The ntpd server uses this data and checks if a answer came from the same host the request was sent to. If this is not the case, it assumes something is wrong. In your setup clients connect to one ip(of the alias) and you send the reply via your main interface. These ip's then don't match. I don't think it is possible to use alias interfaces with ntpd. If you do get it running somehow please let me know. > I have been attempting, without success, to get ntpd listening on an alias > interface on one of my general purpose boxes. It seems that ntpd prefers to > listen on localhost:ntp and eth0addr:ntp. It opens a socket for *:ntp as > well, but does not respond to queries on other addresses. Here is some LSOF > output demonstrating this..: > > # lsof -p 16667 |grep UDP > ntpd16667 root4u IPv44493134 UDP *:ntp > ntpd16667 root5u IPv44493135 UDP localhost:ntp > ntpd16667 root6u IPv44493136 UDP hostname:ntp > > I checked the archives, and it seems another poster had similar trouble in > Dec'02, but there were no apparent follow-up posts. Google has also been > less than revealing on this topic. All suggestions entertained. > > -- > Jeff > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] Marius -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Tracing silent crashes
I have a remote machine running Debian testing and kernel 2.4.21, that operates in headless mode (no keyboard or monitor attached). At random times, it seems to die, at least as far as any network connectivity is concerned (the NICs are SMC 9342 using the epic100 driver). It simply stops responding to any network request. I have a clue (difficult to verify because of the remote location) that the machine doesn't actually crash, and that the local console remains accessible; in other words, it may just be a freeze of the networking stack. There doesn't seem to be any correlation to time of day, and sometimes I'll go weeks without this happening, when other times it may be a daily occurrence. The machine is on a UPS, so it's probably not power glitch related. I've swapped NIC units, though not varieties. And, it's been happening for a while, though I run apt-get dist-upgrade fairly regularly, and across kernel versions, so I don't think it's due to any new software change. Upon reboot things return to normal and there's no trace of anything in the logs to indicate what the problem. I guess I have two questions -- does anyone recognize this problem, and is there any way to capture more data that might give me a clue about what's happening. The normal log files don't yield a clue. Thanks, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SSH Privat key and login as root without a passwort
Hello debian-isp, iam looking for generate a privat SSH-Key. There is a toolthe generates Privat RSA keys. Now i have a privat key generated but where must i put it in the Linux that linux know who ami and i didnt need a passwort for login. That the beginn of the file: PuTTY-User-Key-File-2: ssh-rsa Encryption: aes256-cbc Comment: rsa-key-20040118 Public-Lines: 4 ... ... ... ... Private-Lines: 8 ... .. .. .. . . . . . . . Private-MAC: bf01c4178b5f9ff55f372aa75fa0a50e814a07e0 I didnt wont to paste the hole key-file ;-) Any idea?! -- Best wishes, DWL-Deutsche Webleasing oHG Daniel Holze Offenbacher Landstrasse 387 D-60599 Frankfurt Telefon: +49 (0)69 403 57 990 Telefax: +49 (0)69 403 57 991 http://www.dwleasing.de mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracing silent crashes
Greets, On Sun, 18 Jan 2004, John Ackermann N8UR wrote: > Upon reboot things return to normal and there's no trace of anything in the > logs to indicate what the problem. > > I guess I have two questions -- does anyone recognize this problem, and is > there any way to capture more data that might give me a clue about what's > happening. The normal log files don't yield a clue. This could be, because the buffers don't get synced to the hdd, and therefore you'll see nothing. Try to do some logging over network, if it possible, or tell syslog to sync every write request. If you won't see the error message either, i can only think of a broken utp cable. Anyway, try to connect a display to that machine in these kind of situations :) Oh, never forgot to mention: upgrade your kernel to 2.4.24! People have revealed many and many security flaws in the kernel nowadays. Best regards, -- SZALAY Attila / mrwas at cdata.hu / (20) 416 13 78 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Configuring firewall
Greets,
On Sun, 18 Jan 2004, Chakravarthy Cuddapah wrote:
> I am new to debian. I was using RHL before. It was easy setting up
> firewall there (/etc/sysconfig/iptables). Could not do the same here. Can
> anyone please tell me how to do this in debian. I just want to keep open
> ports 53 and 22.
iptables is the same on rhl & debian.
The debian part is all about:
you setup the firewall,
and if you have finished, you save your settings with iptables-save to
/var/lib/iptables/active. After that, you clean your firewall, flush all
chains, and erase all chains that aren't mandatory. (iptables -F ;
iptables -X) After cleaning, you save this also as
/var/lib/iptables/inactive.
The default debian installation doesn't link /etc/init.d/iptables to the
runlevels, so you have to make an S99iptables symlink in rc2.d pointing
to /etc/init.d/iptables and the corresponding K01iptables in rc{0,6}.d
directories.
My /etc/default/iptables looks like:
iptables_command=iptables
enable_autosave=true
enable_save_counters=true
If these are done, reboot the machine, and you'll see that all your
rules get up after a successful boot.
Best regards,
--
SZALAY Attila / mrwas at cdata.hu / (20) 416 13 78
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracing silent crashes
On Sun Jan 18, 2004 at 08:3302AM -0500, John Ackermann N8UR wrote: > I have a remote machine running Debian testing and kernel 2.4.21, that > operates in headless mode (no keyboard or monitor attached). At random > times, it seems to die, at least as far as any network connectivity is > concerned (the NICs are SMC 9342 using the epic100 driver). It simply > stops responding to any network request. I have a clue (difficult to > verify because of the remote location) that the machine doesn't actually > crash, and that the local console remains accessible; in other words, it > may just be a freeze of the networking stack. > > There doesn't seem to be any correlation to time of day, and sometimes I'll > go weeks without this happening, when other times it may be a daily > occurrence. The machine is on a UPS, so it's probably not power glitch > related. I've swapped NIC units, though not varieties. And, it's been > happening for a while, though I run apt-get dist-upgrade fairly regularly, > and across kernel versions, so I don't think it's due to any new software > change. > > Upon reboot things return to normal and there's no trace of anything in the > logs to indicate what the problem. > > I guess I have two questions -- does anyone recognize this problem, and is > there any way to capture more data that might give me a clue about what's > happening. The normal log files don't yield a clue. Any chance to attach a serial console to the machine? Some serial concentrator in the rack where you could get plugged in at least for fixing that bug? Another box of yours in the same rack? So you could setup this box to support serial console and get all the console output (includung kernel oopses and panics) + magic sysrequest via the serial line. -- Michael Bergbauer <[EMAIL PROTECTED]> use your idle CPU cycles - See http://www.distributed.net for details. Visit our mud Geas at geas.franken.de Port -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get and mounting /tmp with noexec option
On Sun, Jan 18, 2004 at 03:06:07PM +1100, Rob Weir wrote: -snip- > noexec /tmp is NOT supported under Debian. Also, are you aware that it > provides very little protection? Try an experiment: > > $ cp /bin/ls /tmp > $ /tmp/ls > [permission denied] > $ /lib/ld-linux.so.2 /tmp/ls > [directory listing] It does provide some protection against automated attacs, the last apache worm was stopped by this trick. Now what about moving all suid binarys to a dedicated partition, and mounting everything else with nosuid? I understand that for those that admin hundreds of servers, such customizations cause problems. But security is getting more important every day. -- Frode Haugsgjerd Norway -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH Privat key and login as root without a passwort
Hi, put it in /root/.ssh/authorized_keys. I don't know if it works with the key produced by Putty, but with a "ssh-keygen"-generated public key it does. If you need more public keys to log in, simply name the key files /root/.ssh/authorized_keys2, /root/.ssh/authorized_keys3 ... Regards, Hauke -- Stoppt TCPA, das Zensursystem von Microsoft! http://www.againsttcpa.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH Privat key and login as root without a passwort
On January 18, 2004 10:45 am, ournewsletter wrote: > put it in /root/.ssh/authorized_keys. I don't know if it works with the key > produced by Putty, but with a "ssh-keygen"-generated public key it does. If > you need more public keys to log in, simply name the key > files /root/.ssh/authorized_keys2, /root/.ssh/authorized_keys3 ... Putty keys do works with openssh but you must edit them first. Putty keys look rather like the ascii export of a gpg key, you must edit them so that they look like this: ssh-rsa 89yh23wrnhjfdg... #all one line -- Fraser Campbell <[EMAIL PROTECTED]> http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracing silent crashes
Thanks to all who replied. I was able to take a monitor to the machine and discovered that there was an error in the NTP configuration (I'm using a GPS-disciplined oscillator for the timecode, and was using the kernel PPS interface patches) that was causing some sort of meltdown. I've posted a message with the gory details to the NTP mailing list, so I'll spare you here. But thanks in particular for the hints on network syslog and using a console terminal. I'm going to implement some combination of those to make future problems easier to solve. Thanks, John --On Sunday, January 18, 2004 14:45:38 +0100 Michael Bergbauer <[EMAIL PROTECTED]> wrote: On Sun Jan 18, 2004 at 08:3302AM -0500, John Ackermann N8UR wrote: I have a remote machine running Debian testing and kernel 2.4.21, that operates in headless mode (no keyboard or monitor attached). At random times, it seems to die, at least as far as any network connectivity is concerned (the NICs are SMC 9342 using the epic100 driver). It simply stops responding to any network request. I have a clue (difficult to verify because of the remote location) that the machine doesn't actually crash, and that the local console remains accessible; in other words, it may just be a freeze of the networking stack. There doesn't seem to be any correlation to time of day, and sometimes I'll go weeks without this happening, when other times it may be a daily occurrence. The machine is on a UPS, so it's probably not power glitch related. I've swapped NIC units, though not varieties. And, it's been happening for a while, though I run apt-get dist-upgrade fairly regularly, and across kernel versions, so I don't think it's due to any new software change. Upon reboot things return to normal and there's no trace of anything in the logs to indicate what the problem. I guess I have two questions -- does anyone recognize this problem, and is there any way to capture more data that might give me a clue about what's happening. The normal log files don't yield a clue. Any chance to attach a serial console to the machine? Some serial concentrator in the rack where you could get plugged in at least for fixing that bug? Another box of yours in the same rack? So you could setup this box to support serial console and get all the console output (includung kernel oopses and panics) + magic sysrequest via the serial line. -- Michael Bergbauer <[EMAIL PROTECTED]> use your idle CPU cycles - See http://www.distributed.net for details. Visit our mud Geas at geas.franken.de Port -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get and mounting /tmp with noexec option
At 05:06 AM 18-01-2004, you wrote: noexec /tmp is NOT supported under Debian. So it actually is bad practise to mount /tmp noexec? Does it break other things than apt? Also, are you aware that it provides very little protection? Yes, but seeing a server nearly compromised made me very eager to take measures, even ones that are easily circumvented. - Arnoud Warmerdam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considering Debian (currently using Red Hat)
This one time, at band camp, Lucas Albers said: > I have recently started the process of switching my computers from redhat > to debian. > I would very much appreciate step by step directions for creating a local > repository for redistribution of kernel packages and locally built > packages. Just pick a directory that you want to put your local debian packages in, and run dpkg-scanpackages on it. It will create a Packages file, which you then need to gzip. This is my rugh script that updates my directories whenever I add a new package - it does both source and binary, which may be more than you want. It also does seperate stable/unstable trees. Feel free to redo as you need. #!/bin/sh # make_apt, v 0.1 # Make apt-gettable source lines in my debian subdirectory. echo $0 DIR=/home/steve/public_html/debian/ cd $DIR for dist in woody sid; do rm dists/$dist/main/binary-i386/Packages.gz dpkg-scanpackages pool/$dist/main/ indices/override.$dist.main > \ dists/$dist/main/binary-i386/Packages gzip -9 dists/$dist/main/binary-i386/Packages rm dists/$dist/main/source/Sources.gz dpkg-scansources pool/$dist/main > dists/$dist/main/source/Sources gzip -9 dists/$dist/main/source/Sources done override.$dist.main looks something like this: qvcd optionalutils cosmosoptionalx11 and the sources.list entries corresponding to this setup are: Stable sources.list lines: deb http://www.lobefin.net/~steve/debian woody main deb-src http://www.lobefin.net/~steve/debian woody main Unstable sources.list lines: deb http://www.lobefin.net/~steve/debian sid main deb-src http://www.lobefin.net/~steve/debian sid main Remember to let your web or ftp server know to serve the correct directory, or none of this will be much use. > I ran across basic directions on setting up mirror, but nothing about > debianizing a package; if you just want it for a local package. > eg, you don't need the full steps, just enough to convert a tar.gz file to > a .deb file. http://www.debian.org/doc/maint-guide/ has a pretty good starting reference for this. > I run the 2.4.23+ kernels on my servers as it supports the newest > hardware. I don't run stable because they don't have drivers for my newer > network card. I also recompile my kernel with grsecurity security patches. > I am currently only running 4 debian boxes, but I have yet to encounter a > single kernel crash. Using make-kpkg is a good way to build a kernel-image .deb that you can then put in your mirror for redistribution. man make-kpkg for details - it's really pretty straightforward. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: SSH Privat key and login as root without a passwort
> iam looking for generate a privat SSH-Key. There is a toolthe generates > Privat RSA keys. Now i have a privat key generated but where must i put > it in the Linux that linux know who ami and i didnt need a passwort for > login. You put the **private** key on the system you are connecting FROM, (in your case this looks like Putty) and you put the **public** key on the system you are connectiong TO. (in your case this looks like in ~/.ssh/authorized_keys) The docs for putty, ssh, ssh-keygen should be helpful: http://www.tartarus.org/~simon/puttydoc/Contents.html man ssh-keygen man sshd # see end for authorized_keys file info It is worth noting that putty can import/export openssh keys. Also you should check that the system administrator has not disallowed use of public/private keys for ssh authentication. (see /etc/ssh/sshd_config on the system you are connecting TO) On Sun, 18 Jan 2004, Fraser Campbell wrote: > On January 18, 2004 10:45 am, ournewsletter wrote: > > > put it in /root/.ssh/authorized_keys. I don't know if it works with the key > > produced by Putty, but with a "ssh-keygen"-generated public key it does. If > > you need more public keys to log in, simply name the key > > files /root/.ssh/authorized_keys2, /root/.ssh/authorized_keys3 ... > > Putty keys do works with openssh but you must edit them first. Putty keys > look rather like the ascii export of a gpg key, you must edit them so that > they look like this: > > ssh-rsa 89yh23wrnhjfdg... #all one line > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get and mounting /tmp with noexec option
How about running apache chroot'd so what apache thinks is /tmp and what apt-get thinks is /tmp are two different things? fstab would look something like: (untested) # /dev/sdc1 /var/www/tmp/ noexec, blah,blah,blah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ntpd listening on alias interfaces seems non-trivial
On Sun, 2004-01-18 at 23:31, Marius Olsthoorn wrote: > Ntp uses its own protocol on top of UDP. Each ntp packet includes source > and destination addresses of the communication. The ntpd server uses this > data and checks if a answer came from the same host the request was sent > to. If this is not the case, it assumes something is wrong. Whatever the technical reasons, ntp is not happy if the response comes from a different IP to the one the request was sent to (this doesn't require IP's in the packet... the client could be just checking the src/dest IP's match). > In your setup clients connect to one ip(of the alias) and you send the > reply via your main interface. These ip's then don't match. I don't think > it is possible to use alias interfaces with ntpd. If you do get it running > somehow please let me know. The problem is ntpd doesn't respond on the same interface it receives a request on. It responds on the default interface routed to the querying client. I believe there are bug reports on this; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209054 I did see a post that claims this was fixed in one of the latest RH packages, but I'm yet to see confirmation that this is true. > > I have been attempting, without success, to get ntpd listening on an alias > > interface on one of my general purpose boxes. It seems that ntpd prefers to > > listen on localhost:ntp and eth0addr:ntp. It opens a socket for *:ntp as > > well, but does not respond to queries on other addresses. Here is some LSOF > > output demonstrating this..: > > > > # lsof -p 16667 |grep UDP > > ntpd16667 root4u IPv44493134 UDP *:ntp > > ntpd16667 root5u IPv44493135 UDP localhost:ntp > > ntpd16667 root6u IPv44493136 UDP hostname:ntp > > > > I checked the archives, and it seems another poster had similar trouble in > > Dec'02, but there were no apparent follow-up posts. Google has also been > > less than revealing on this topic. All suggestions entertained. The only workaround I know of is to route the ntp responses explicitly via the alias. You can use iproute2 to try and route only ntp responses via this alias, but it is non-trivial as iproute2 rules don't allow port based rule selection. Another possibility is to use NAT to re-map the response on the way out... once again, if anyone gets this working, please post how you did it. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ntpd listening on alias interfaces seems non-trivial
--On Monday, January 19, 2004 12:01:59 +1100 Donovan Baarda <[EMAIL PROTECTED]> wrote: Another possibility is to use NAT to re-map the response on the way out... once again, if anyone gets this working, please post how you did it. I don't know if this is quite you're looking for, but I had no trouble using Linux "ipmasqadm portfwd" to open port 123 for tcp and udp on my firewall. I'm going from a public IP address to a private namespace and that seems to work (or at least, my friend testing on the outside is able to get time from me). John [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ntpd listening on alias interfaces seems non-trivial
On Mon, 2004-01-19 at 12:08, John Ackermann N8UR wrote: > --On Monday, January 19, 2004 12:01:59 +1100 Donovan Baarda > <[EMAIL PROTECTED]> wrote: > > > Another possibility is to use NAT to re-map the response on the way > > out... once again, if anyone gets this working, please post how you did > > it. > > I don't know if this is quite you're looking for, but I had no trouble > using Linux "ipmasqadm portfwd" to open port 123 for tcp and udp on my > firewall. I'm going from a public IP address to a private namespace and > that seems to work (or at least, my friend testing on the outside is able > to get time from me). For those not using ipmasqadm, the following iptables rule run somewhere appropriate during startup on the machine running ntpd should do the trick; $ iptables -t nat -A POSTROUTING -p udp -s -sport ntp \ -j SNAT --to This will only SNAT the outgoing ntp udp packets from the address so they are changed to come from the address. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ntpd listening on alias interfaces seems non-trivial
On Mon, 2004-01-19 at 12:59, Donovan Baarda wrote: > On Mon, 2004-01-19 at 12:08, John Ackermann N8UR wrote: > > --On Monday, January 19, 2004 12:01:59 +1100 Donovan Baarda > > <[EMAIL PROTECTED]> wrote: > > > > > Another possibility is to use NAT to re-map the response on the way > > > out... once again, if anyone gets this working, please post how you did > > > it. > > > > I don't know if this is quite you're looking for, but I had no trouble > > using Linux "ipmasqadm portfwd" to open port 123 for tcp and udp on my > > firewall. I'm going from a public IP address to a private namespace and > > that seems to work (or at least, my friend testing on the outside is able > > to get time from me). > > For those not using ipmasqadm, the following iptables rule run somewhere > appropriate during startup on the machine running ntpd should do the > trick; > > $ iptables -t nat -A POSTROUTING -p udp -s -sport ntp \ > -j SNAT --to > > This will only SNAT the outgoing ntp udp packets from the > address so they are changed to come from the address. Actually, I just tried this and it didn't work. The responses are now coming from the right IP address, but the ntpdate client is still not happy because the UDP packet response must include the original IP address. Back to the drawing board :-( looks like the only way to fix this is by fixing ntp. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ntpd listening on alias interfaces seems non-trivial
Ntp uses its own protocol on top of UDP. Each ntp packet includes source and destination addresses of the communication. The ntpd server uses this data and checks if a answer came from the same host the request was sent to. If this is not the case, it assumes something is wrong. In your setup clients connect to one ip(of the alias) and you send the reply via your main interface. These ip's then don't match. I don't think it is possible to use alias interfaces with ntpd. If you do get it running somehow please let me know. > I have been attempting, without success, to get ntpd listening on an alias > interface on one of my general purpose boxes. It seems that ntpd prefers to > listen on localhost:ntp and eth0addr:ntp. It opens a socket for *:ntp as > well, but does not respond to queries on other addresses. Here is some LSOF > output demonstrating this..: > > # lsof -p 16667 |grep UDP > ntpd16667 root4u IPv44493134 UDP *:ntp > ntpd16667 root5u IPv44493135 UDP localhost:ntp > ntpd16667 root6u IPv44493136 UDP hostname:ntp > > I checked the archives, and it seems another poster had similar trouble in > Dec'02, but there were no apparent follow-up posts. Google has also been > less than revealing on this topic. All suggestions entertained. > > -- > Jeff > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] Marius
Tracing silent crashes
I have a remote machine running Debian testing and kernel 2.4.21, that operates in headless mode (no keyboard or monitor attached). At random times, it seems to die, at least as far as any network connectivity is concerned (the NICs are SMC 9342 using the epic100 driver). It simply stops responding to any network request. I have a clue (difficult to verify because of the remote location) that the machine doesn't actually crash, and that the local console remains accessible; in other words, it may just be a freeze of the networking stack. There doesn't seem to be any correlation to time of day, and sometimes I'll go weeks without this happening, when other times it may be a daily occurrence. The machine is on a UPS, so it's probably not power glitch related. I've swapped NIC units, though not varieties. And, it's been happening for a while, though I run apt-get dist-upgrade fairly regularly, and across kernel versions, so I don't think it's due to any new software change. Upon reboot things return to normal and there's no trace of anything in the logs to indicate what the problem. I guess I have two questions -- does anyone recognize this problem, and is there any way to capture more data that might give me a clue about what's happening. The normal log files don't yield a clue. Thanks, John
SSH Privat key and login as root without a passwort
Hello debian-isp, iam looking for generate a privat SSH-Key. There is a toolthe generates Privat RSA keys. Now i have a privat key generated but where must i put it in the Linux that linux know who ami and i didnt need a passwort for login. That the beginn of the file: PuTTY-User-Key-File-2: ssh-rsa Encryption: aes256-cbc Comment: rsa-key-20040118 Public-Lines: 4 ... ... ... ... Private-Lines: 8 ... .. .. ..
Re: Tracing silent crashes
Greets, On Sun, 18 Jan 2004, John Ackermann N8UR wrote: > Upon reboot things return to normal and there's no trace of anything in the > logs to indicate what the problem. > > I guess I have two questions -- does anyone recognize this problem, and is > there any way to capture more data that might give me a clue about what's > happening. The normal log files don't yield a clue. This could be, because the buffers don't get synced to the hdd, and therefore you'll see nothing. Try to do some logging over network, if it possible, or tell syslog to sync every write request. If you won't see the error message either, i can only think of a broken utp cable. Anyway, try to connect a display to that machine in these kind of situations :) Oh, never forgot to mention: upgrade your kernel to 2.4.24! People have revealed many and many security flaws in the kernel nowadays. Best regards, -- SZALAY Attila / mrwas at cdata.hu / (20) 416 13 78
Re: Configuring firewall
Greets,
On Sun, 18 Jan 2004, Chakravarthy Cuddapah wrote:
> I am new to debian. I was using RHL before. It was easy setting up
> firewall there (/etc/sysconfig/iptables). Could not do the same here. Can
> anyone please tell me how to do this in debian. I just want to keep open
> ports 53 and 22.
iptables is the same on rhl & debian.
The debian part is all about:
you setup the firewall,
and if you have finished, you save your settings with iptables-save to
/var/lib/iptables/active. After that, you clean your firewall, flush all
chains, and erase all chains that aren't mandatory. (iptables -F ;
iptables -X) After cleaning, you save this also as
/var/lib/iptables/inactive.
The default debian installation doesn't link /etc/init.d/iptables to the
runlevels, so you have to make an S99iptables symlink in rc2.d pointing
to /etc/init.d/iptables and the corresponding K01iptables in rc{0,6}.d
directories.
My /etc/default/iptables looks like:
iptables_command=iptables
enable_autosave=true
enable_save_counters=true
If these are done, reboot the machine, and you'll see that all your
rules get up after a successful boot.
Best regards,
--
SZALAY Attila / mrwas at cdata.hu / (20) 416 13 78
Re: Tracing silent crashes
On Sun Jan 18, 2004 at 08:3302AM -0500, John Ackermann N8UR wrote: > I have a remote machine running Debian testing and kernel 2.4.21, that > operates in headless mode (no keyboard or monitor attached). At random > times, it seems to die, at least as far as any network connectivity is > concerned (the NICs are SMC 9342 using the epic100 driver). It simply > stops responding to any network request. I have a clue (difficult to > verify because of the remote location) that the machine doesn't actually > crash, and that the local console remains accessible; in other words, it > may just be a freeze of the networking stack. > > There doesn't seem to be any correlation to time of day, and sometimes I'll > go weeks without this happening, when other times it may be a daily > occurrence. The machine is on a UPS, so it's probably not power glitch > related. I've swapped NIC units, though not varieties. And, it's been > happening for a while, though I run apt-get dist-upgrade fairly regularly, > and across kernel versions, so I don't think it's due to any new software > change. > > Upon reboot things return to normal and there's no trace of anything in the > logs to indicate what the problem. > > I guess I have two questions -- does anyone recognize this problem, and is > there any way to capture more data that might give me a clue about what's > happening. The normal log files don't yield a clue. Any chance to attach a serial console to the machine? Some serial concentrator in the rack where you could get plugged in at least for fixing that bug? Another box of yours in the same rack? So you could setup this box to support serial console and get all the console output (includung kernel oopses and panics) + magic sysrequest via the serial line. -- Michael Bergbauer <[EMAIL PROTECTED]> use your idle CPU cycles - See http://www.distributed.net for details. Visit our mud Geas at geas.franken.de Port
Re: apt-get and mounting /tmp with noexec option
On Sun, Jan 18, 2004 at 03:06:07PM +1100, Rob Weir wrote: -snip- > noexec /tmp is NOT supported under Debian. Also, are you aware that it > provides very little protection? Try an experiment: > > $ cp /bin/ls /tmp > $ /tmp/ls > [permission denied] > $ /lib/ld-linux.so.2 /tmp/ls > [directory listing] It does provide some protection against automated attacs, the last apache worm was stopped by this trick. Now what about moving all suid binarys to a dedicated partition, and mounting everything else with nosuid? I understand that for those that admin hundreds of servers, such customizations cause problems. But security is getting more important every day. -- Frode Haugsgjerd Norway
Re: SSH Privat key and login as root without a passwort
Hi, put it in /root/.ssh/authorized_keys. I don't know if it works with the key produced by Putty, but with a "ssh-keygen"-generated public key it does. If you need more public keys to log in, simply name the key files /root/.ssh/authorized_keys2, /root/.ssh/authorized_keys3 ... Regards, Hauke -- Stoppt TCPA, das Zensursystem von Microsoft! http://www.againsttcpa.com
Re: SSH Privat key and login as root without a passwort
On January 18, 2004 10:45 am, ournewsletter wrote: > put it in /root/.ssh/authorized_keys. I don't know if it works with the key > produced by Putty, but with a "ssh-keygen"-generated public key it does. If > you need more public keys to log in, simply name the key > files /root/.ssh/authorized_keys2, /root/.ssh/authorized_keys3 ... Putty keys do works with openssh but you must edit them first. Putty keys look rather like the ascii export of a gpg key, you must edit them so that they look like this: ssh-rsa 89yh23wrnhjfdg... #all one line -- Fraser Campbell <[EMAIL PROTECTED]> http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux
Re: Tracing silent crashes
Thanks to all who replied. I was able to take a monitor to the machine and discovered that there was an error in the NTP configuration (I'm using a GPS-disciplined oscillator for the timecode, and was using the kernel PPS interface patches) that was causing some sort of meltdown. I've posted a message with the gory details to the NTP mailing list, so I'll spare you here. But thanks in particular for the hints on network syslog and using a console terminal. I'm going to implement some combination of those to make future problems easier to solve. Thanks, John --On Sunday, January 18, 2004 14:45:38 +0100 Michael Bergbauer <[EMAIL PROTECTED]> wrote: On Sun Jan 18, 2004 at 08:3302AM -0500, John Ackermann N8UR wrote: I have a remote machine running Debian testing and kernel 2.4.21, that operates in headless mode (no keyboard or monitor attached). At random times, it seems to die, at least as far as any network connectivity is concerned (the NICs are SMC 9342 using the epic100 driver). It simply stops responding to any network request. I have a clue (difficult to verify because of the remote location) that the machine doesn't actually crash, and that the local console remains accessible; in other words, it may just be a freeze of the networking stack. There doesn't seem to be any correlation to time of day, and sometimes I'll go weeks without this happening, when other times it may be a daily occurrence. The machine is on a UPS, so it's probably not power glitch related. I've swapped NIC units, though not varieties. And, it's been happening for a while, though I run apt-get dist-upgrade fairly regularly, and across kernel versions, so I don't think it's due to any new software change. Upon reboot things return to normal and there's no trace of anything in the logs to indicate what the problem. I guess I have two questions -- does anyone recognize this problem, and is there any way to capture more data that might give me a clue about what's happening. The normal log files don't yield a clue. Any chance to attach a serial console to the machine? Some serial concentrator in the rack where you could get plugged in at least for fixing that bug? Another box of yours in the same rack? So you could setup this box to support serial console and get all the console output (includung kernel oopses and panics) + magic sysrequest via the serial line. -- Michael Bergbauer <[EMAIL PROTECTED]> use your idle CPU cycles - See http://www.distributed.net for details. Visit our mud Geas at geas.franken.de Port -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get and mounting /tmp with noexec option
At 05:06 AM 18-01-2004, you wrote: noexec /tmp is NOT supported under Debian. So it actually is bad practise to mount /tmp noexec? Does it break other things than apt? Also, are you aware that it provides very little protection? Yes, but seeing a server nearly compromised made me very eager to take measures, even ones that are easily circumvented. - Arnoud Warmerdam
Re: Considering Debian (currently using Red Hat)
This one time, at band camp, Lucas Albers said: > I have recently started the process of switching my computers from redhat > to debian. > I would very much appreciate step by step directions for creating a local > repository for redistribution of kernel packages and locally built > packages. Just pick a directory that you want to put your local debian packages in, and run dpkg-scanpackages on it. It will create a Packages file, which you then need to gzip. This is my rugh script that updates my directories whenever I add a new package - it does both source and binary, which may be more than you want. It also does seperate stable/unstable trees. Feel free to redo as you need. #!/bin/sh # make_apt, v 0.1 # Make apt-gettable source lines in my debian subdirectory. echo $0 DIR=/home/steve/public_html/debian/ cd $DIR for dist in woody sid; do rm dists/$dist/main/binary-i386/Packages.gz dpkg-scanpackages pool/$dist/main/ indices/override.$dist.main > \ dists/$dist/main/binary-i386/Packages gzip -9 dists/$dist/main/binary-i386/Packages rm dists/$dist/main/source/Sources.gz dpkg-scansources pool/$dist/main > dists/$dist/main/source/Sources gzip -9 dists/$dist/main/source/Sources done override.$dist.main looks something like this: qvcd optionalutils cosmosoptionalx11 and the sources.list entries corresponding to this setup are: Stable sources.list lines: deb http://www.lobefin.net/~steve/debian woody main deb-src http://www.lobefin.net/~steve/debian woody main Unstable sources.list lines: deb http://www.lobefin.net/~steve/debian sid main deb-src http://www.lobefin.net/~steve/debian sid main Remember to let your web or ftp server know to serve the correct directory, or none of this will be much use. > I ran across basic directions on setting up mirror, but nothing about > debianizing a package; if you just want it for a local package. > eg, you don't need the full steps, just enough to convert a tar.gz file to > a .deb file. http://www.debian.org/doc/maint-guide/ has a pretty good starting reference for this. > I run the 2.4.23+ kernels on my servers as it supports the newest > hardware. I don't run stable because they don't have drivers for my newer > network card. I also recompile my kernel with grsecurity security patches. > I am currently only running 4 debian boxes, but I have yet to encounter a > single kernel crash. Using make-kpkg is a good way to build a kernel-image .deb that you can then put in your mirror for redistribution. man make-kpkg for details - it's really pretty straightforward. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpW1DBceezTa.pgp Description: PGP signature
Re: SSH Privat key and login as root without a passwort
> iam looking for generate a privat SSH-Key. There is a toolthe generates > Privat RSA keys. Now i have a privat key generated but where must i put > it in the Linux that linux know who ami and i didnt need a passwort for > login. You put the **private** key on the system you are connecting FROM, (in your case this looks like Putty) and you put the **public** key on the system you are connectiong TO. (in your case this looks like in ~/.ssh/authorized_keys) The docs for putty, ssh, ssh-keygen should be helpful: http://www.tartarus.org/~simon/puttydoc/Contents.html man ssh-keygen man sshd # see end for authorized_keys file info It is worth noting that putty can import/export openssh keys. Also you should check that the system administrator has not disallowed use of public/private keys for ssh authentication. (see /etc/ssh/sshd_config on the system you are connecting TO) On Sun, 18 Jan 2004, Fraser Campbell wrote: > On January 18, 2004 10:45 am, ournewsletter wrote: > > > put it in /root/.ssh/authorized_keys. I don't know if it works with the key > > produced by Putty, but with a "ssh-keygen"-generated public key it does. If > > you need more public keys to log in, simply name the key > > files /root/.ssh/authorized_keys2, /root/.ssh/authorized_keys3 ... > > Putty keys do works with openssh but you must edit them first. Putty keys > look rather like the ascii export of a gpg key, you must edit them so that > they look like this: > > ssh-rsa 89yh23wrnhjfdg... #all one line > >
Re: apt-get and mounting /tmp with noexec option
How about running apache chroot'd so what apache thinks is /tmp and what apt-get thinks is /tmp are two different things? fstab would look something like: (untested) # /dev/sdc1 /var/www/tmp/ noexec, blah,blah,blah
Re: ntpd listening on alias interfaces seems non-trivial
On Sun, 2004-01-18 at 23:31, Marius Olsthoorn wrote: > Ntp uses its own protocol on top of UDP. Each ntp packet includes source > and destination addresses of the communication. The ntpd server uses this > data and checks if a answer came from the same host the request was sent > to. If this is not the case, it assumes something is wrong. Whatever the technical reasons, ntp is not happy if the response comes from a different IP to the one the request was sent to (this doesn't require IP's in the packet... the client could be just checking the src/dest IP's match). > In your setup clients connect to one ip(of the alias) and you send the > reply via your main interface. These ip's then don't match. I don't think > it is possible to use alias interfaces with ntpd. If you do get it running > somehow please let me know. The problem is ntpd doesn't respond on the same interface it receives a request on. It responds on the default interface routed to the querying client. I believe there are bug reports on this; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209054 I did see a post that claims this was fixed in one of the latest RH packages, but I'm yet to see confirmation that this is true. > > I have been attempting, without success, to get ntpd listening on an alias > > interface on one of my general purpose boxes. It seems that ntpd prefers to > > listen on localhost:ntp and eth0addr:ntp. It opens a socket for *:ntp as > > well, but does not respond to queries on other addresses. Here is some LSOF > > output demonstrating this..: > > > > # lsof -p 16667 |grep UDP > > ntpd16667 root4u IPv44493134 UDP *:ntp > > ntpd16667 root5u IPv44493135 UDP localhost:ntp > > ntpd16667 root6u IPv44493136 UDP hostname:ntp > > > > I checked the archives, and it seems another poster had similar trouble in > > Dec'02, but there were no apparent follow-up posts. Google has also been > > less than revealing on this topic. All suggestions entertained. The only workaround I know of is to route the ntp responses explicitly via the alias. You can use iproute2 to try and route only ntp responses via this alias, but it is non-trivial as iproute2 rules don't allow port based rule selection. Another possibility is to use NAT to re-map the response on the way out... once again, if anyone gets this working, please post how you did it. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/
Re: ntpd listening on alias interfaces seems non-trivial
--On Monday, January 19, 2004 12:01:59 +1100 Donovan Baarda <[EMAIL PROTECTED]> wrote: Another possibility is to use NAT to re-map the response on the way out... once again, if anyone gets this working, please post how you did it. I don't know if this is quite you're looking for, but I had no trouble using Linux "ipmasqadm portfwd" to open port 123 for tcp and udp on my firewall. I'm going from a public IP address to a private namespace and that seems to work (or at least, my friend testing on the outside is able to get time from me). John [EMAIL PROTECTED]
Re: ntpd listening on alias interfaces seems non-trivial
On Mon, 2004-01-19 at 12:08, John Ackermann N8UR wrote: > --On Monday, January 19, 2004 12:01:59 +1100 Donovan Baarda > <[EMAIL PROTECTED]> wrote: > > > Another possibility is to use NAT to re-map the response on the way > > out... once again, if anyone gets this working, please post how you did > > it. > > I don't know if this is quite you're looking for, but I had no trouble > using Linux "ipmasqadm portfwd" to open port 123 for tcp and udp on my > firewall. I'm going from a public IP address to a private namespace and > that seems to work (or at least, my friend testing on the outside is able > to get time from me). For those not using ipmasqadm, the following iptables rule run somewhere appropriate during startup on the machine running ntpd should do the trick; $ iptables -t nat -A POSTROUTING -p udp -s -sport ntp \ -j SNAT --to This will only SNAT the outgoing ntp udp packets from the address so they are changed to come from the address. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/
Re: ntpd listening on alias interfaces seems non-trivial
On Mon, 2004-01-19 at 12:59, Donovan Baarda wrote: > On Mon, 2004-01-19 at 12:08, John Ackermann N8UR wrote: > > --On Monday, January 19, 2004 12:01:59 +1100 Donovan Baarda > > <[EMAIL PROTECTED]> wrote: > > > > > Another possibility is to use NAT to re-map the response on the way > > > out... once again, if anyone gets this working, please post how you did > > > it. > > > > I don't know if this is quite you're looking for, but I had no trouble > > using Linux "ipmasqadm portfwd" to open port 123 for tcp and udp on my > > firewall. I'm going from a public IP address to a private namespace and > > that seems to work (or at least, my friend testing on the outside is able > > to get time from me). > > For those not using ipmasqadm, the following iptables rule run somewhere > appropriate during startup on the machine running ntpd should do the > trick; > > $ iptables -t nat -A POSTROUTING -p udp -s -sport ntp \ > -j SNAT --to > > This will only SNAT the outgoing ntp udp packets from the > address so they are changed to come from the address. Actually, I just tried this and it didn't work. The responses are now coming from the right IP address, but the ntpdate client is still not happy because the UDP packet response must include the original IP address. Back to the drawing board :-( looks like the only way to fix this is by fixing ntp. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/
