North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Proper authentication model

  • From: Kevin
  • Date: Tue Jan 11 15:29:05 2005
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Q2f12EfJOJP4mFQxaH7/koVDYVz/sS11/kzDpTNx34zaVlPoGhCE1GlRd65lqK9Ds1nZJGCXCqWFIfvDLWYNJBUXyDR1qFHEr6TKoJ6o9J75Ivw7g/l1csXzEXWIVyOP1Bmt66Bg387R78n2uOQF5snYDEvg8GghMhTXZoi+aC0=
On Tue, 11 Jan 2005 11:17:55 +0200, Kim Onnel <[email protected]> wrote:
> 
> Hello,
> I'd like everyones 2 cents on the BCP for network management of an ISP
> PoPs, with a non-security oriented NOC,
. . .
> 2) An OpenBSD bastion host(s), where the NOC would ssh in, get
> authenticated from TACACS+ or ssh certs, and then just telnet from
> there all day,

If the OpenBSD host is located in the same physical site as the Cisco
products, you have the additional option of providing serial console
access to the console port on the Cisco devices through the OpenBSD
bastion host.  To take this a step further, you can log all serial
port I/O to disk.

Using the serial console as your management port has one major
drawback (some would call it a feature), you can only have one person
(two with the AUX port) logged into a given router or switch at a
time.

This is very much "out of band" management, and having remote serial
access is great for fault diagnosis and recovery (Not just for Cisco,
Sun, etc).  I've resolved more than a few Cisco switch "halt and catch
fire" failures based on the last gasp fault message dumped to the
console port.