This isn't debian specific but ...
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user x
can connect from. Some should be allowed to connect from anywhere but some
should only be able to conect
* op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]:
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user x
can connect from. Some should be allowed to connect from anywhere but some
should
Previously martin f krafft wrote:
nope, this isn't possible with the current sshd. an interesting
feature though...
From the sshd manpage:
AllowUsers
This keyword can be followed by a list of user names, separated
by spaces. If specified, login is allowed only
On Tue, 27 Nov 2001, martin f krafft wrote:
* op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]:
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user x
can connect from. Some should be
Petro wrote/napisa[a]/schrieb:
On Mon, Nov 26, 2001 at 12:17:32PM +1100, Steve Smith wrote:
3DES is generally considered strong enough. However, it is slow, and
can effect performance. Try doing large 'scp's and switch between
DES/3DES was designed to be implemented in hardware,
On Tue, Nov 27, 2001 at 12:44:23PM +0100, Janusz A. Urbanowicz wrote:
Petro wrote/napisa?[a]/schrieb:
On Mon, Nov 26, 2001 at 12:17:32PM +1100, Steve Smith wrote:
3DES is generally considered strong enough. However, it is slow, and
can effect performance. Try doing large 'scp's and
* Wichert Akkerman [EMAIL PROTECTED] [2001.11.27 12:23:04+0100]:
The @HOST bit may be new in OpenSSH 3 though.
yes. and it can't take a network, so you'd have to enter one entry per
user/machine permutation...
--
martin; (greetings from the heart of the sun.)
\ echo mailto:
On 27/11/01, martin f krafft wrote:
* op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]:
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user x
can connect from. Some should be allowed to
On Tue, Nov 27, 2001 at 10:23:57AM +0100, op wrote:
This isn't debian specific but ...
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user x
can connect from. Some should be allowed to
I have to find a library that will make me able to use public-key and symmetric-key
crypto functions like RSA or ElGamal algorithm and IDEA or AES ( formerly known as
Rijndael ). And also I have to have a MAC function like SHA but prefer any collision
resistant keyed hash function if it is
Hello Mr. Bacteria/John Doe:
Translation: Homework is hard, and plagiarism is so much easier.
Can someone please do my homework for me?
Go to http://www.openssl.org/, download the source to the library,
and start reading. But be careful! You might learn something from
reading and trying to
John DOE wrote:
Have to code the application in C ( I would prefer visual basic since it is
sometimes hard to tell a professor that this code does it in C especially if you are
in Turkey ) or C++ and of course on GNU Debian Linux.
I'm a bit confused by this statement. First, what's Turkey
Dear .debs,
I'm maintaining a (small-time) group server for our department. In
order to satisfy company policy requirements I need to provide a way
to shutdown the server in case of emergencies. Our network admin was
kind enough to give me two alternatives:
1) provide an on-screen shutdown
Can't you give a group sudo access? If so, just add everyone to a group
and give that group sudo /sbin/halt or sudo /sbin/shutdown or both.
Or you could write your own script which wraps around halt/shutdown and
logs what it's doing via logger or syslog...
On Tue, 2001-11-27 at 17:51, Olaf
Do you have any source of information about the employees? HR
database or something like that? You could cobble together a setuid
Perl or C program that asks them information only they would know to
authenticate them, verifies it, logs it, and then does a shutdown.
Set up a guest account with
unsubscribe [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Blake Barnett [EMAIL PROTECTED] writes:
Can't you give a group sudo access? If so, just add everyone to a group
and give that group sudo /sbin/halt or sudo /sbin/shutdown or both.
That's exactly what my sudo setup does right now. The problem is that
apparently *everyone* needs to be able to
Blake Barnett [EMAIL PROTECTED] writes:
On Tue, 2001-11-27 at 18:58, Olaf Meeuwissen wrote:
Blake Barnett [EMAIL PROTECTED] writes:
Can't you give a group sudo access? If so, just add everyone to a group
and give that group sudo /sbin/halt or sudo /sbin/shutdown or both.
That's
(Sorry for the cross-posting; this is somewhat important)
Versions 1.20-11.2 and 1.20-12 of wdm contain a configuration error that
caused X session authentication data to be stored in a non-existant
directory. In situations like this, the X server falls back to a
security mode which allows
This isn't debian specific but ...
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user x
can connect from. Some should be allowed to connect from anywhere but some
should only be able to conect
* op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]:
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user x
can connect from. Some should be allowed to connect from anywhere but some
should only
Previously martin f krafft wrote:
nope, this isn't possible with the current sshd. an interesting
feature though...
From the sshd manpage:
AllowUsers
This keyword can be followed by a list of user names, separated
by spaces. If specified, login is allowed only
On Tue, 27 Nov 2001, martin f krafft wrote:
* op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]:
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user
x
can connect from. Some should be
Petro wrote/napisał[a]/schrieb:
On Mon, Nov 26, 2001 at 12:17:32PM +1100, Steve Smith wrote:
3DES is generally considered strong enough. However, it is slow, and
can effect performance. Try doing large 'scp's and switch between
DES/3DES was designed to be implemented in hardware,
On Tue, Nov 27, 2001 at 12:44:23PM +0100, Janusz A. Urbanowicz wrote:
Petro wrote/napisa?[a]/schrieb:
On Mon, Nov 26, 2001 at 12:17:32PM +1100, Steve Smith wrote:
3DES is generally considered strong enough. However, it is slow, and
can effect performance. Try doing large 'scp's and
On Tue, Nov 27, 2001 at 01:24:05PM +0200, Wichert Akkerman wrote:
Previously martin f krafft wrote:
nope, this isn't possible with the current sshd. an interesting
feature though...
From the sshd manpage:
AllowUsers
This keyword can be followed by a list of user
* Wichert Akkerman [EMAIL PROTECTED] [2001.11.27 12:23:04+0100]:
The @HOST bit may be new in OpenSSH 3 though.
yes. and it can't take a network, so you'd have to enter one entry per
user/machine permutation...
--
martin; (greetings from the heart of the sun.)
\ echo mailto:
On 27/11/01, martin f krafft wrote:
* op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]:
I specify the users in /ets/ssh/sshd_config who are allowed to connect via
ssh. But I'd like some more control. I'd like to control which subnets user
x
can connect from. Some should be allowed to
(Sorry for the cross-posting; this is somewhat important)
Versions 1.20-11.2 and 1.20-12 of wdm contain a configuration error that
caused X session authentication data to be stored in a non-existant
directory. In situations like this, the X server falls back to a
security mode which allows *all*
I have to find a library that will make me able to use public-key and
symmetric-key crypto functions like RSA or ElGamal algorithm and IDEA or AES (
formerly known as Rijndael ). And also I have to have a MAC function like SHA
but prefer any collision resistant keyed hash function if it is
Hello Mr. Bacteria/John Doe:
Translation: Homework is hard, and plagiarism is so much easier.
Can someone please do my homework for me?
Go to http://www.openssl.org/, download the source to the library,
and start reading. But be careful! You might learn something from
reading and trying to
John DOE wrote:
Have to code the application in C ( I would prefer visual basic since it is
sometimes hard to tell a professor that this code does it in C especially if
you are in Turkey ) or C++ and of course on GNU Debian Linux.
I'm a bit confused by this statement. First, what's
Dear .debs,
I'm maintaining a (small-time) group server for our department. In
order to satisfy company policy requirements I need to provide a way
to shutdown the server in case of emergencies. Our network admin was
kind enough to give me two alternatives:
1) provide an on-screen shutdown
Can't you give a group sudo access? If so, just add everyone to a group
and give that group sudo /sbin/halt or sudo /sbin/shutdown or both.
Or you could write your own script which wraps around halt/shutdown and
logs what it's doing via logger or syslog...
On Tue, 2001-11-27 at 17:51, Olaf
Blake Barnett [EMAIL PROTECTED] writes:
Can't you give a group sudo access? If so, just add everyone to a group
and give that group sudo /sbin/halt or sudo /sbin/shutdown or both.
That's exactly what my sudo setup does right now. The problem is that
apparently *everyone* needs to be able to
On Tue, 2001-11-27 at 18:58, Olaf Meeuwissen wrote:
Blake Barnett [EMAIL PROTECTED] writes:
Can't you give a group sudo access? If so, just add everyone to a group
and give that group sudo /sbin/halt or sudo /sbin/shutdown or both.
That's exactly what my sudo setup does right now. The
Blake Barnett [EMAIL PROTECTED] writes:
On Tue, 2001-11-27 at 18:58, Olaf Meeuwissen wrote:
Blake Barnett [EMAIL PROTECTED] writes:
Can't you give a group sudo access? If so, just add everyone to a group
and give that group sudo /sbin/halt or sudo /sbin/shutdown or both.
That's
How about Cntrl-Alt-Del? That shuts down a debian box without even logging
in. As far as accountablity ... you could do it the old fashioned way and
have a sign in sheet ... one stupid policy deserves another.
-rishi
On 28 Nov 2001, Olaf Meeuwissen wrote:
Blake Barnett [EMAIL
On Wed, Nov 28, 2001 at 09:51:19AM +0900, Olaf Meeuwissen wrote:
I'm maintaining a (small-time) group server for our department. In
order to satisfy company policy requirements I need to provide a way
to shutdown the server in case of emergencies. Our network admin
was kind enough to give
Do you have any source of information about the employees? HR
database or something like that? You could cobble together a setuid
Perl or C program that asks them information only they would know to
authenticate them, verifies it, logs it, and then does a shutdown.
Set up a guest account with
unsubscribe [EMAIL PROTECTED]
41 matches
Mail list logo
