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