Fortunately, I'm barely smart enough to follow this detailed and instructive thread!
I'll just go with the Debian Defaults: rsyslogd with TLS. I think this is the key to my small success ;-) When everyone in the room is smarter than you, it's good to have a system in place for whose advice you follow. Thanx All. -- Joe Golden /_\ www.Triangul.us /_\ websites with class On 12/13/2012 09:28 PM, Sam Hooker wrote: > Madonna mia. Call me. > > xoxo > > -sth > > sam hooker|[email protected]|http://www.noiseplant.com > > "I have not failed, I've just found 10,000 ways that won't work." > Thomas Edison > > ----- Original Message ----- > >> From: "Shawn T Carroll" <[email protected]> >> To: [email protected] >> Sent: Thursday, December 13, 2012 9:21:10 PM >> Subject: Re: secure remote rsyslog: Thanx > >> Very well put, Sam. Good thoughts, and instructive. > >> On Dec 13, 2012, at 8:41 PM, Sam Hooker < [email protected] > wrote: > >>> Maybe I'm misreading, but I think Rick's, "I don't allow access any >>> other way, only ssh, with keys, no passwords," meant "only key >>> authentication is enabled; no password-based methods are." But, in >>> any event... >> > >>> The only thing using key-based authentication without a password >>> has >>> over traditional password auth, IMHO, is that a trojaned sshd is >>> not >>> positioned to receive your password (think MiTM; you are checking >>> those host key fingerprints, aren't you? ;-)). I wouldn't dream of >>> removing the passphrase from (i.e., decrypting) the SSH keys I use >>> to authenticate interactive logins to remote machines. re: Joe's >>> initial inquiry, we were talking about what are, effectively, >>> service accounts which need to be able to authenticate unattended. >>> In this case, the unencrypted private SSH key is a "something you >>> know" for machines. >> > >>> Yes, this is susceptible to theft. But careful use of directives in >>> the authorized_keys files on the server side (think "from=" and >>> "command="), in conjunction with adherence to the principle of >>> least >>> privilege, can at least minimize the scope of the risks posed by >>> key >>> theft. Most of the "service accounts" using unencrypted SSH keys on >>> my servers log into unprivileged accounts on the far end; those >>> that >>> are able to log in as root do so to (nearly) identical members of >>> clusters/host groups with identical functions, such that the actual >>> exposure isn't appreciably different. (i.e., I'm just as screwed if >>> you pwn mx0-3 as I am if you jack mx0 alone, so convenience can >>> reasonably win out in this case.) The majority of the time, I hew >>> to >>> a "one key per (remote) function" ethic, e.g.: >> > >>> [blerg_manager@blort ~]$ ssh -i .ssh/enable-blerg.pub >>> blerg_manager@blerg1 "/usr/bin/blerg on" >> > >>> [blerg_manager@blerg1 ~]$ head -1 .ssh/authorized_keys2 >> >>> from="blort",command="/usr/bin/blerg on" ssh-dss >>> AAAAB3NzaC...3Y1RXo+pg= enable-blerg@blort >> > >>> and >> > >>> [blerg_manager@blort ~]$ ssh -i .ssh/disable-blerg.pub >>> blerg_manager@blerg1 "/usr/bin/blerg off" >> > >>> [blerg_manager@blerg1 ~]$ tail -1 .ssh/authorized_keys2 >> >>> from="blort",command="/usr/bin/blerg off" ssh-dss >>> AAAABTG7d9...BV98he= disable-blerg@blort >> > >>> If you're still unconvinced, and can tolerate a requirement for >>> administrator interaction on reboot, you could use encrypted SSH >>> keys, and load up one or more ssh-agents with the keys every time >>> the machine comes up. >> > >>> In other words: There are options. :-) >> > >>> Cheers, >> > >>> -sth >> > >>> sam hooker| [email protected] | http://www.noiseplant.com >> > >>> "I have not failed, I've just found 10,000 ways that won't work." >> >>> Thomas Edison >> > >>> ----- Original Message ----- >> > >>>> From: "Stanley Brinkerhoff" < [email protected] > >>> >> >>>> To: [email protected] >>> >> >>>> Sent: Thursday, December 13, 2012 6:50:49 PM >>> >> >>>> Subject: Re: secure remote rsyslog: Thanx >>> >> > >>>> I've always been curious how frequently the (arguably true) >>>> statement >>>> that SSH keys are more secure is followed by a "and no password". >>>> It >>>> seems to be trading one security mechanism (what you know, >>>> password) >>>> for another (what you have, a SSH key). >>> >> > >>>> In an instance where your harddrive contents are compromised >>>> (Malware.. corporate network.. stolen from your trunk..) you've >>>> lost >>>> your keys. People who seem to use SSH keys seem to also use them >>>> throughout their environment, so losing an SSH key to your >>>> personal >>>> workstation then lends itself to an attacker gaining access to >>>> other >>>> resources. >>> >> > >>>> On a 'Windows Domain' this is even more of a concern. With the >>>> trust >>>> relationship that allows an attacker to remotely access your >>>> machine >>>> with a domain adminstrator credential set your keys are at >>>> considerably more risk. >>> >> > >>>> I prefer a strong password (correcthorsebatterystaple), or a >>>> strong >>>> password and a SSH key. Service accounts are about the only place >>>> I >>>> use SSH keys w/o passwords. >>> >> > >>>> </soapbox> >>> >> > >>>> Stan >>> >> > >>>> On Thu, Dec 13, 2012 at 5:42 PM, Rick Bragg < [email protected] > >>>> wrote: >>> >> > >>>>> I allow access to my servers via ssh with keys only. I don't >>>>> allow >>>>> access any >>>> >>> >> >>>>> other way, only ssh, with keys, no passwords... Otherwise no >>>>> access. >>>> >>> >> > >>>>> My $0.02 ;) >>>> >>> >> >>>>> Rick Bragg >>>> >>> >> > >>>>>> Thanx Sam. Suspected as much. Cheers. >>>> >>> >> >>>>>> >>>> >>> >> >>>>>> -- >>>> >>> >> >>>>>> Joe Golden /_\ www.Triangul.us /_\ websites with class >>>> >>> >> >>>>>> >>>> >>> >> >>>>>> On 12/13/2012 11:01 AM, Sam Hooker wrote: >>>> >>> >> >>>>>>> Hi Joe, >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>>> I've tunneled a lot of stuff over SSH, and it's a great >>>>>>> band-aid, >>>>>>> but >>>> >>> >> >>>>>>> always feels heavy-handed. My initial thought is that you're >>>>>>> going >>>>>>> to >>>> >>> >> >>>>>>> deal with maintaining/distributing asymmetric crypto one way >>>>>>> or >>>>>>> the >>>> >>> >> >>>>>>> other. Which is to say: You'd probably want your SSH tunnels >>>>>>> to >>>> >>> >> >>>>>>> re-establish themselves w/o user intervention...which likely >>>>>>> means >>>> >>> >> >>>>>>> key-based auth (unless you've got a Kerberos card you >>>>>>> haven't >>>>>>> played >>>> >>> >> >>>>>>> yet)...which isn't that much more easily-managed than X.509 >>>>>>> certs >>>>>>> for >>>> >>> >> >>>>>>> TLS. Additionally, since SSH tunnels are bad at bringing >>>>>>> themselves >>>> >>> >> >>>>>>> back to life after link failure without additional glue, and >>>>>>> rsyslog >>>> >>> >> >>>>>>> probably has built-in support for addressing that problem, >>>>>>> rsyslog's >>>> >>> >> >>>>>>> own TLS implementation is probably a win. >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>>> $0.02, >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>>> -sth >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>>> sam hooker| [email protected] | http://www.noiseplant.com >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>>> "To invent, you need a good imagination and a pile of junk." >>>>>>> Thomas >>>> >>> >> >>>>>>> Edison >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>>> ----- Original Message ----- >>>> >>> >> >>>>>>>> From: "joe golden" < [email protected] > To: >>>>>>>> [email protected] >>>>>>>> Sent: >>>> >>> >> >>>>>>>> Thursday, December 13, 2012 10:45:00 AM Subject: secure >>>>>>>> remote >>>> >>> >> >>>>>>>> rsyslog >>>> >>> >> >>>>>>>> >>>> >>> >> >>>>>>>> Anyone have any links or advice for rsyslogd over ssh? Good >>>>>>>> idea? >>>> >>> >> >>>>>>>> Bad idea? >>>> >>> >> >>>>>>>> >>>> >>> >> >>>>>>>> I'm trying to set up centralized logging and might as well >>>>>>>> do >>>>>>>> it >>>>>>>> in >>>> >>> >> >>>>>>>> a secure fashion. Rather not go through the hassle of ssl >>>>>>>> certs >>>>>>>> if >>>> >>> >> >>>>>>>> not necessary. That said, it looks like rsyslogd with TLS >>>> >>> >> >>>>>>>> ( http://www.rsyslog.com/doc/rsyslog_tls.html ) may be the >>>>>>>> way >>>>>>>> to >>>> >>> >> >>>>>>>> go. >>>> >>> >> >>>>>>>> >>>> >>> >> >>>>>>>> I live in the Debian flavored world. >>>> >>> >> >>>>>>>> >>>> >>> >> >>>>>>>> Cheers with beers. >>>> >>> >> >>>>>>>> >>>> >>> >> >>>>>>>> -- Joe Golden /_\ www.Triangul.us /_\ websites with class >>>> >>> >> >>>>>>>> >>>> >>> >> >>>>>>> >>>> >>> >> >>>>>> >>>> >>> >> >>>>>> >>>> >>> >> >
