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... on
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
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... on
--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 tro
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
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
--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 tro
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
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
> 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
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]
> 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
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
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 ta
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
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 ta
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
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_ke
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
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,
Hauk
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_ke
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 list
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,
Hauk
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
> concern
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 list
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.
i
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
-File-2: ssh-rsa
Encryption: aes256-cbc
Comment: rsa-key-20040118
Public-Lines: 4
...
...
...
...
Private-Lines: 8
...
..
..
..
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 resp
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
> concern
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.
i
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
-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
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 resp
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 clie
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 clie
36 matches
Mail list logo
