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

Reply via email to