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