----- Original Message ----- > From: "Rick Bragg" <[email protected]> > > Obviously there are benefits to passwords that often easily > outweigh keys...
Really? Other than portability, I mean? Because I can load up ssh-agent* with my laptop key by providing the (sufficiently-lengthy) passphrase first thing in the morning, and not have to re-enter it again when executing the subsequent 143 interactive logins that day (works for scp too!). And it's pretty unlikely you'll be able to phish my private key out of me, because I don't know it. You have to steal it AND phish the passphrase. So, used judiciously, it *is* something I have and something I know. Is it better or worse than two-factor schemes utilizing a physical token? That's debatable. But those passwords are still just something I know. *Yes, all you RAM-freezers and DMA-vacuumers have me so 0wned. You've also got my WDE key. We should all just stay in bed, hide under the covers, and read paperbacks. Wait, was that out loud? ;-) Cheers, -sth sam hooker|[email protected]|http://www.noiseplant.com "To invent, you need a good imagination and a pile of junk." Thomas Edison > > 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 > >> > >> > >>> > >> > >> > >> > >> > >> > > > >> > >> > > > >> > > > > > > >
