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 > > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
