some snmp V3 problems

Post by Sven Herzing
I'm trying to configure the Net-SNMP agent with snmp version 3 support,

Well, I'm no expert on SNMPv3, but I'll try to have a go at this.
Hopefully one of the others will chip in if I go too far off-beam.

Post by Sven Herzing
At first I tried to get the agent working with an non net-snmp client. I
figured out that this client (snmpc from castlerock) like to know the
engineID.

Well, typically an SNMPv3 client should start by "probing" the agent
to determine the engineID.
(i.e. send a dummy request, that will fail but trigger a response
containing the engineID)

Post by Sven Herzing
In the agent man page is explained that the engineID should configured
engineID <STRING>

The agent typically generates an engineID "sort-of-at-random".
There are a number of possible algorithms used to try and ensure
that engineIDs are unique. But in practise, you shouldn't need to
worry about this. Just use what it comes up with.

Post by Sven Herzing
I tried several strings like "public" or "0x2233", but none of these
worked witch snmpc neigther witch snmpget -e <engineID> from net-snmp.
On the other hand is the oldEngineID entry in the persisten data file
every time an other one, so I think it isn't using "my" value.

Yes - that's very likely.

I can't speak for the castlerock client, but certainly as far as
our tools are concerned, you shouldn't need to fiddle with the engineID
at all. As long as you've got the users and access control set up
properly, things will "just work".

Personally I'd start with a homogeneous environment, and only move on to
using a mixture of tools once you're happy things are working.

Post by Sven Herzing
An other thing is that I have to add and remove users who are allowed to
use snmp. In the documentation it is explained that the createUser entry
in the persitent data file will be removed after the agent restarts
and replaced by a corresponding usmUser. In my case the createUser entry
stay's around all the time...

Which file did you put the 'createUser' line in?

Post by Sven Herzing
The other thing is that I havent any idea how to remove useres of change
passwords if the plain text entries will be removed, have anyone an idea??

Have a look at the 'snmpusm' command.
That can be used to delete users, or change their passwords.

Post by Sven Herzing
The last thing I couldn't figure out is about the context. The the vacm
user model the only way to set the context??

Pretty much, yes.
It's only relatively recently that we've started to make any significant
use of contexts. And this is really only relevant if you're wanting
to implement "parallel" OID trees (e.g. for two different systems via
the same agent.

For simple SNMPv3 operation, you can assume the default "" context throughout.

Dave

Sven Herzing

2003-07-09 11:17:03 UTC

Hi,

<snip>

Post by Dave Shield
The agent typically generates an engineID "sort-of-at-random".
There are a number of possible algorithms used to try and ensure
that engineIDs are unique. But in practise, you shouldn't need to
worry about this. Just use what it comes up with.

ok, then I stop try to set it manually. But this leads me to two questions:

- Why is there a chance to set the engineID if the agent ignores it?

- Is there a way to show the current engineID?

<snip>

Post by Dave Shield
Personally I'd start with a homogeneous environment, and only move on to
using a mixture of tools once you're happy things are working.

Which file did you put the 'createUser' line in?

When I create a snmp v3 user I put the entry
rouser <username> in the /etc/snmpd.conf file and the

createUser <username> MD5 <authpassphrase> DES <privpassphrase>

entry in the persistend data file in /var/net-snmp/snmpd.conf

Post by Sven Herzing
The other thing is that I havent any idea how to remove useres of change
passwords if the plain text entries will be removed, have anyone an idea??

Have a look at the 'snmpusm' command.
That can be used to delete users, or change their passwords.

thanks for the hint :)

Post by Sven Herzing
The last thing I couldn't figure out is about the context. The the vacm
user model the only way to set the context??

Pretty much, yes.
It's only relatively recently that we've started to make any significant
use of contexts.

And this is really only relevant if you're wanting

Post by Dave Shield
to implement "parallel" OID trees (e.g. for two different systems via
the same agent.

This is what I have to do. :(

This is the vacm section of my snmpd.conf, please correct if I'm wrong:

#community public for every interface for snmpv3
com2sec internal 0.0.0.0/0 public

group mygroup usm internal

^^^^ this is for snmp v3 users only

access mygroup "mycontext" usm auth exact all all all
^^^^^^^^^^

view all included .1

#EOF

do I have to quote the context in teh snmp<get|walk> commands like
snmpget -v 3 -u sven -n "mycontext" -l authNoPriv -a MD5 -A <passphrase>

or should it work without quotes like
snmpget -v 3 -u sven -n mycontext -l authNoPriv -a MD5 -A <passphrase>

I got it only working if if haven't used the vacm modell.

Thaks for help.

Sven

Post by Dave Shield
For simple SNMPv3 operation, you can assume the default "" context throughout.
Dave
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Dave Shield

2003-07-09 11:57:16 UTC

Post by Sven Herzing
- Why is there a chance to set the engineID if the agent ignores it?

It was probably mostly needed when first developing the SNMPv3 support.
And there's always going to be one or two wierdos who do need to be
able to set this explicitly.
The agent shouldn't be ignoring this option - it's just not typically
necessary to use it.

I actually argued for downgrade this from a top-level single-character
command-line option (bunching all the SNMPv3-related stuff under '-3x'
style options).
But that didn't receive a lot of support. :-(

Post by Sven Herzing
- Is there a way to show the current engineID?

SNMP-FRAMEWORK-MIB::snmpEngineID.0

Post by Dave Shield
Which file did you put the 'createUser' line in?

When I create a snmp v3 user I put the entry
rouser <username> in the /etc/snmpd.conf file and the
createUser <username> MD5 <authpassphrase> DES <privpassphrase>
entry in the persistend data file in /var/net-snmp/snmpd.conf

OK - that looks right.

If you start the agent, then stop it again (cleanly),
the 'createUser' is still in the /var/net-snmp/snmpd.conf file - yes?
It's not replaced by a 'usmUser' line?

Post by Dave Shield
[contexts are] really only relevant if you're wanting
to implement "parallel" OID trees (e.g. for two different systems via
the same agent.

This is what I have to do. :(

Fair enough.
I'd try to get things working with a single context to start with, though.

Post by Sven Herzing
#community public for every interface for snmpv3
com2sec internal 0.0.0.0/0 public
group mygroup usm internal

I presume you've got a proper user "internal" as well?

Post by Sven Herzing
access mygroup "mycontext" usm auth exact all all all

Yup - that looks fine.

Post by Sven Herzing
do I have to quote the context in the snmp<get|walk> commands like
snmpget -v 3 -u sven -n "mycontext" -l authNoPriv -a MD5 -A <passphrase>
or should it work without quotes like
snmpget -v 3 -u sven -n mycontext -l authNoPriv -a MD5 -A <passphrase>

Shouldn't matter in this case.
The quotes are interpreted by the shell.

They're only needed if you've got a multi-word context

snmpget -v 3 -u sven -n "my context" ....

Post by Sven Herzing
I got it only working if if haven't used the vacm model.

What do you mean by "got it working"?
Different contexts, general SNMPv3 access or what?

How are you registering the MIB modules for the non-default context?

Dave

Sven Herzing

2003-07-09 12:49:22 UTC

Hi,

Post by Sven Herzing
- Is there a way to show the current engineID?

SNMP-FRAMEWORK-MIB::snmpEngineID.0

nice :)

Post by Dave Shield
Which file did you put the 'createUser' line in?

When I create a snmp v3 user I put the entry
rouser <username> in the /etc/snmpd.conf file and the
createUser <username> MD5 <authpassphrase> DES <privpassphrase>
entry in the persistend data file in /var/net-snmp/snmpd.conf

OK - that looks right.
If you start the agent, then stop it again (cleanly),
the 'createUser' is still in the /var/net-snmp/snmpd.conf file - yes?
It's not replaced by a 'usmUser' line?

It's not replaced, the createUser line stay's there, and below this line

Post by Dave Shield
[contexts are] really only relevant if you're wanting
to implement "parallel" OID trees (e.g. for two different systems via
the same agent.

This is what I have to do. :(

Fair enough.
I'd try to get things working with a single context to start with, though.

Post by Sven Herzing
#community public for every interface for snmpv3
com2sec internal 0.0.0.0/0 public
group mygroup usm internal

I presume you've got a proper user "internal" as well?

uh...no, I din't. I thought it was just an internal name to have a link
to the line with the group entry.

Does this mean that I can remove the line with the entry
rouser sven

in the snmpd.conf file and use
com2sec sven 0.0.0.0/0 public
instead??

If so, for what can I use the community? Is this only used if I made an
additional group ntry with the same user for snmp v 1 / v2c?

Post by Sven Herzing
access mygroup "mycontext" usm auth exact all all all

Yup - that looks fine.

Shouldn't matter in this case.
The quotes are interpreted by the shell.
They're only needed if you've got a multi-word context
snmpget -v 3 -u sven -n "my context" ....

thanks for the hint.

Post by Sven Herzing
I got it only working if if haven't used the vacm model.

What do you mean by "got it working"?
Different contexts, general SNMPv3 access or what?

I didn't got I working at all. Instead I used "rocommunity <community>"
for snmp v1/2c and rouser for snmp v3

Post by Dave Shield
How are you registering the MIB modules for the non-default context?

I used it without the vacm model, so
snmpget -v 2c -c public <host> system.sysDescr.0
or
snmpget -v 3 -u sven -l authNoPriv -a MD5 -A <passphrase>

worked fine.

Post by Dave Shield
Dave

Sven

Satya

2003-07-10 02:03:02 UTC

I have few questions regarding net-snmp-5.0.8.

1. Which mib module supports the user based security model. For
view-based-access-control module it is vacm_vars, but for USM which module
is available in the net-snmp-5.0.8.

2. If i want to make my agent (not snmpd) v3 enabled how to do that one.
Do i need to set the data store values, if so how to do that one i mean
functions needed to be invoked.

Regds,
Satya

Dave Shield

2003-07-10 06:11:12 UTC

Post by Sven Herzing
When I create a snmp v3 user I put the entry
createUser <username> MD5 <authpassphrase> DES <privpassphrase>
entry in the persistend data file in /var/net-snmp/snmpd.conf

If you start the agent, then stop it again (cleanly),
the 'createUser' is still in the /var/net-snmp/snmpd.conf file - yes?
It's not replaced by a 'usmUser' line?

It's not replaced, the createUser line stay's there, and below this line

"Below this line" ?

I tried this on my setup last night, and confirmed that the 'createUser'
lines *are* removed and replaced by 'usmUser' lines when the agent starts
up. So the basic functionality is working.

Try running the agent using

snmpd -f -Le -Dread-config

Have a look at the output, and see if you can spot anything that looks
suspicious....

Dave

Dave Shield

2003-07-10 06:18:02 UTC

Post by Sven Herzing
#community public for every interface for snmpv3
com2sec internal 0.0.0.0/0 public
group mygroup usm internal

I presume you've got a proper user "internal" as well?

uh...no, I din't. I thought it was just an internal name to have a link
to the line with the group entry.

No.
It would be if you had

com2sec internal 0.0.0.0/0 public
group mygroup v1 internal
group mygroup v2c internal

That creates an pseudo-user "internal", and assigns it to the group
"mygroup" for community-based requests.

But if you have

group mygroup usm internal

Then this is referring to SNMPv3 request with the user "internal",
so you do have to create a proper user for that to work.

But I suspect that you probably want the two community-based group
commands instead....

Post by Sven Herzing
Does this mean that I can remove the line with the entry
rouser sven
in the snmpd.conf file and use
com2sec sven 0.0.0.0/0 public
instead??

There are two alternative approaches to access control.

a) com2sec/group/view/access
(or just group/view/access for SNMPv3)

b) rocommunity/rwcommunity
(or rouser/rwuser for SNMPv3)

I suggest you don't try to mix them.

Please see the FAQ entries
How do I configure access control?
I don't understand the new access control stuff - what does it mean?
for details

Dave

Dave Shield

2003-07-10 06:22:04 UTC

Post by Sven Herzing
I got it only working if if haven't used the vacm model.

I didn't got I working at all. Instead I used "rocommunity <community>"
for snmp v1/2c and rouser for snmp v3

Ah. I see what you mean.
Actually that *does* use the VACM module internally
(which is what was confusing me).

Post by Dave Shield
How are you registering the MIB modules for the non-default context?

snmpget -v 2c -c public <host> system.sysDescr.0
or
snmpget -v 3 -u sven -l authNoPriv -a MD5 -A <passphrase>
worked fine.

No - that's not what I meant. You said you needed to use contexts to
distinguish between parallel OID trees?

That means that you have to register a particular MIB in a particular
context in some way. By default, everything is registered in the
default context. So if you want to use non-default contexts, you've
got to tell the agent this *within* the agent code.

How are you doing this?

Dave

Sven Herzing

2003-07-10 15:41:04 UTC

Post by Sven Herzing
I got it only working if if haven't used the vacm model.

I didn't got I working at all. Instead I used "rocommunity <community>"
for snmp v1/2c and rouser for snmp v3

Ah. I see what you mean.
Actually that *does* use the VACM module internally
(which is what was confusing me).

ok, but why shouldn't I mix it if it internaly use VACM.
But, it's ok for me, it I shouldn't mix it, I wouldn't mix it, the
question was just for understanding it.

Post by Dave Shield
How are you registering the MIB modules for the non-default context?

snmpget -v 2c -c public <host> system.sysDescr.0
or
snmpget -v 3 -u sven -l authNoPriv -a MD5 -A <passphrase>
worked fine.

No - that's not what I meant. You said you needed to use contexts to
distinguish between parallel OID trees?

Ups, maybe I misunderstood it or said what I mean in a wrong way..
so, I didn't have parallel oid trees, just this stupid (non net-snmp)
client like to know the context. Maybe the client make use of it with
parallel view's on the same device with diffrent users.

Post by Dave Shield
That means that you have to register a particular MIB in a particular
context in some way. By default, everything is registered in the
default context. So if you want to use non-default contexts, you've
got to tell the agent this *within* the agent code.

I didn't really wan't to use default contexts, but as long as the "tool"
need to know a context I thought it would the easiest to set the context
to a value I know..

Is the defalut context ""?

Post by Dave Shield
How are you doing this?
Dave
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________
Net-snmp-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Sven

Sven Herzing

2003-07-11 07:36:31 UTC

Post by Sven Herzing
ok, but why shouldn't I mix it if it internaly use VACM.
But, it's ok for me, it I shouldn't mix it, I wouldn't mix it, the
question was just for understanding it.

There's no technical reason not to mix the two styles.
It's purely a matter of following what's happening.
If you're not fully au fait with how the two styles work, it's easier to
think of them as two separate alternatives, and just use one or the other.
But as long as you realise that the single-directive forms will be turned
into full group/view/access settings internally, then there's no real
technical reason not to mix.

now it's clear

Post by Sven Herzing
Ups, maybe I misunderstood it or said what I mean in a wrong way..
so, I didn't have parallel oid trees, just this stupid (non net-snmp)
client like to know the context.

What do you mean by client?

I mean the software which make the get / getnext reqeust at the agent.

Is this a "request generator" - i.e. the equivalent of 'snmpwalk' et al?
In which case you should tell it to use the context ""
Or is it some form of "subagent" that your main agent is passing requests
off to? In which case the interface used to register with the main
agent needs to include the context(s) that it is expecting.

Post by Sven Herzing
Is the defalut context ""?

Yes.
Dave

Sven

Dave Shield

2003-07-11 08:38:20 UTC