Hi, Sorry, I was thinking about a certain type of access that I implement for client specific needs. Obviously there are benefits to passwords that often easily outweigh keys...
Rick > 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 >> >> > >>> >> >> > >> >> >> > > >> >> > > >> > > >
