RE: SSH and RSA
> -----Original Message-----
> From: Duane Powers [mailto:duane@uberLAN.net]
> Sent: Tuesday, February 20, 2001 7:37 AM
> To: Mike Dresser
> Cc: email@example.com
> Subject: Re: SSH and RSA
> Mike Dresser wrote:
> > You don't mention whether the previous admin is still with
> you, but if not, you'll want to remove his RSA keys from the
> server, or else you can change your root password all you want,
> and he'll still be able to connect, assuming he can get to the
> machine via your network/internet.
Mike has an exceptionally pertinant point here.
Right now - even before you start trying to load your own RSA key in, log
into all machines running SSH and remove the previous admins key from
9762349856239487562347896 Bilbo Baggins
Each line in this file contains some directives (as in the first entry above
(from=, command=), a public key (starts with 1024 35 XXX.... in the examples
above), and a comment, usually the name or email address of the person who
generated it. Remove any appearing to belong to the previous admin.
Those containing a command="..." directive will only be able to execute that
command and so may be related to automated processes.
To add your own key first generate it (possibly on your workstation if you
are sure it is well secured) using ssh-keygen. Make sure you use a
passphrase. A command like;
ssh-keygen -b 1024 -f .ssh/identity -C "Joe New Admin"
should suffice. Make sure that the generated .ssh/identity is not readable
by any but you and shouldn't be writeable by anybody.
Now copy the file .ssh/identity.pub onto all of the machines running SSH and
add it to the end of ~root/.ssh/authorized_keys on each machine. You can do
this using scp or even a cut-and-paste via ssh. Make sure that you do not
split the line up when adding it to authorized_keys.
This will give you RSA keypair authentication to all of those machines
instead of password access.
I would also recommend creating a non-root account to log in with and
totally disallow root logins. You would be able to simply move the
authorized_keys file to the non-root .ssh directory.
Andrew J. Stephen Network Operations Manager
"The important thing about standards is to have them."
-- Bruce Schneier, creator of the Twofish algorithm
> A couple of quick notes, I just realized that by trying to be
> cute and
> putting my comments in angle brackets, those among us who may
> read html
> mail, may not be able to see my comments (my bad).
> And second, I saw him login once, he was prompted for his RSA key as
> (to the best of my recollection)
> ssh firstname.lastname@example.org
> enter RSA passkey:
> # <<<---- remote prompt
> > Duane Powers wrote:
> >> Hi all,
> >> Recently I was made administrator over a dozen Solaris boxen <heh>
> >> The prior admin was offsite and used ssh with rsa keys to
> access the boxes.
> >> He allowed root login, and used the RSA key functionality
> to keep the root
> >> password safe.
> >> I am not as mature as he was regarding ssh <newbie> and
> have only used
> >> ssh as a plug in replacement to telnet, <I tend to not set
> a different
> >> p/w during
> >> ssh-keygen> and simply access the boxes as follows: ssh -l
> <me> <hostname>
> >> then I login using the normal p/w that is local to the
> box. I have found
> >> that he did
> >> not need to transmit the local password over the tunnel,
> but rather used
> >> RSA to
> >> verify his identity, but I can't find documentation on how
> to do it.
> >> <man ssh, man ssh-agent, man ssh-add, Practical UNIX & Internet
> >> Security> does anyone have any information on how I can
> implement the
> >> same safeguards? Or where I can at least find some documentation on
> >> practical ssh implementation.
> >> As always, You guys are great, thanks in advance for the help,
> >> ~duane
> The plan was simple. Unfortunately, so was Bullwinkle.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact
This email with any attachments is confidential and may be subject to legal
privilege. If it is not intended for you please reply immediately, destroy
it and do not copy, disclose or use it in any way.