Computing/SSH: Difference between revisions

From OpenWetWare
Jump to navigationJump to search
No edit summary
Line 119: Line 119:
*Use RSA instead of DSA
*Use RSA instead of DSA
*[http://www.diceware.com/ DiceWare] recommends using at least five words each generated randomly by rolling five dice, which gives over 2^64 possible passphrases and is probably not a bad scheme. If you want your passphrase to make grammatical sense, this cuts down the possibilities a lot and you should use a longer one as a result.
*[http://www.diceware.com/ DiceWare] recommends using at least five words each generated randomly by rolling five dice, which gives over 2^64 possible passphrases and is probably not a bad scheme. If you want your passphrase to make grammatical sense, this cuts down the possibilities a lot and you should use a longer one as a result.
==Troubleshooting==
Slow login:
*[http://ubuntuforums.org/showthread.php?t=445677 Problem]: it takes up to 20 seconds for the password prompt to appear
*[http://ubuntuforums.org/showthread.php?p=3189998#post3189998 Solutions]:
**add <tt>UseDNS no</tt> to <tt>/etc/ssh/sshd_config</tt> (on the server)
**add <tt>GSSAPIAuthentication no</tt> on my <tt>/etc/ssh/ssh_config</tt> file (on the client)

Revision as of 13:30, 7 December 2007

SSH/OpenSSH is a secure remote login program

Resources

ssh -qTfnN -D 7070 remotehost
-q :- be very quite, we are acting only as a tunnel.
-T :- Do not allocate a pseudo tty, we are only acting a tunnel.
-f :- move the ssh process to background, as we don’t want to interact with this ssh session directly.
-N :- Do not execute remote command.
-n :- redirect standard input to /dev/null.

File locations

Linux/UNIX

  • Private keys
    • ~/.ssh/identity contains the protocol version 1 RSA authentication identity of the user
    • ~/.ssh/id_dsa contains the protocol version 2 DSA authentication identity of the user
    • ~/.ssh/id_rsa contains the protocol version 2 RSA authentication identity of the user
  • Public keys
    • ~/.ssh/id_dsa.pub - DSA protocol
    • ~/.ssh/id_rsa.pub - RSA protocol
  • Public keys from remote machines (one key per line)
    • ~/.ssh/authorized_keys

To enable publickey authentication for connection from account on localbox to account on remotebox, copy public key from ~/.ssh/id_dsa.pub on localbox to ~/.ssh/authorized_keys on remotebox.

To enable host key login:

[localbox]$ ssh-keygen -t rsa
[localbox]$ scp ~/.ssh/id_rsa.pub remotebox:
[remotebox]$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
[remotebox]$ rm ~/id_rsa.pub

Make sure your .ssh directory and your private key are accessible only by you:

[localbox]$ chmod 700 ~/.ssh
[localbox]$ chmod 600 ~/.ssh/id_rsa

Using ssh-agent for caching decrypted private keys:

eval `ssh-agent`
ssh-add

To change an SSH key passphrase:

ssh-keygen -p

Key management

Tutorial @ IBM: Parl 1, Part 2 and Part 3

Keychain script makes handling RSA and DSA keys both convenient and secure, it acts as a front-end to ssh-agent

  • ssh-keygen - authentication key pair generation, management and conversion
  • ssh-keyscan - utility for gathering the public ssh host keys of a number of hosts
  • ssh-agent - holds private keys used for public key authentication
  • ssh-add - adds RSA or DSA private keys to ssh-agent
-l displays the identities currently held by the agent
-s reader adds key to smartcard reader

Using keychain:

$ keychain ~/.ssh/id_rsa
$ source ~/.keychain/$HOSTNAME-sh

Here's a good standard keychain-enabled ~/.bash_profile:

# initialize SSH key management
/usr/bin/keychain ~/.ssh/id_rsa
source ~/.keychain/${HOSTNAME}-sh

Here's a run-through of how keychain works. When started from your ~/.bash_profile, it will first check to see whether an ssh-agent is already running. If not, then it will start ssh-agent and record the important SSH_AUTH_SOCK and SSH_AGENT_PID variables in the ~/.keychain/$HOSTNAME-sh file for safe keeping and later use.

Don't forget that you can also get your cron jobs and scripts to "hook in" to the running ssh-agent process. To use ssh or scp commands from your shell scripts and cron jobs, just make sure that they source your ~/.ssh-agent file first:

source ~/.keychain/$HOSTNAME-sh

Keychain options:

  • --clear option allows you to tell keychain to assume that every new login to your account should be considered a potential security breach until proven otherwise. When you start keychain with the --clear option, keychain immediately flushes all your private keys from ssh-agent's cache when you log in, before performing its normal duties. Using keychain with --clear still has advantages over using ssh-agent all by itself; remember, when you use keychain --clear, your cron jobs and scripts will still be able to establish passwordless connections; --clear option an ideal choice for infrequently accessed servers that need to perform occasional secure copying tasks, such as backup servers, firewalls, and routers.

A better ~/.bash_profile?

kch=`type -p keychain`;
hostfilename=`echo $HOST | sed 's/\..*//'`;
if [ -n "$kch" ]; then
    $kch;
    if [ -f ~/.keychain/${hostfilename}-sh ]; then
        echo "Sourcing ~/.keychain/${hostfilename}-sh...";
        . ~/.keychain/`uname -n`-sh;
        if ! ssh-add -l | grep -q id_rsa; then
            ssh-add;
        fi;
    else
        echo "No keychain host file found.";
    fi;
else
    echo "keychain script was not found!";
fi

OS X

SSH Keychain - GUI app for managing SSH keys

Port forwarding

Local

$ ssh -L localport:host:port server

Service runs on remote host:port. We ssh to server and forward localport to host:port via server. Example:

$ ssh -L 3002:localhost:631 openwetware.org

Remote

-R port:host:hostport Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remot side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine.

Authentication agent forwarding

  • running ssh-agent on untrusted machines is quite dangerous: if someone manages to get root access on the system, then your decrypted keys can be extracted from ssh-agent
  • Authentication forwarding allows remote ssh processes to contact the ssh-agent that is running on your local trusted machine -- rather than requiring a version of ssh-agent to be running on the same machine that you are sshing out from.
  • Add this line to your /etc/ssh/ssh_config:
ForwardAgent Yes
  • Advantages:
    1. The private key is stored only on the trusted machine. This prevents malicious users from grabbing your encrypted key from disk and attempting to crack the encryption.
    2. ssh-agent runs only on the trusted machine. This prevents an intruder from doing a memory dump of a remote ssh-agent process and then extracting your decrypted private keys from the dump.
    3. Since you only need to type in the passphrase on your trusted machine, you prevent any keystroke loggers from stealthily grabbing your passphrase as it is entered.

Miscellaneous

  • Use RSA instead of DSA
  • DiceWare recommends using at least five words each generated randomly by rolling five dice, which gives over 2^64 possible passphrases and is probably not a bad scheme. If you want your passphrase to make grammatical sense, this cuts down the possibilities a lot and you should use a longer one as a result.

Troubleshooting

Slow login:

  • Problem: it takes up to 20 seconds for the password prompt to appear
  • Solutions:
    • add UseDNS no to /etc/ssh/sshd_config (on the server)
    • add GSSAPIAuthentication no on my /etc/ssh/ssh_config file (on the client)