Linux Commands Examples

A great documentation place for Linux commands

ssh-agent

authentication agent


see also : ssh - ssh-add - ssh-keygen

Synopsis

ssh-agent [-c -s] [-d] [-a bind_address] [-t life] [command [arg ...]]
ssh-agent
[-c -s] -k


add an example, a script, a trick and tips

: email address (won't be displayed)
: name

Step 2

Thanks for this example ! - It will be moderated and published shortly.

Feel free to post other examples
Oops ! There is a tiny cockup. A damn 404 cockup. Please contact the loosy team who maintains and develops this wonderful site by clicking in the mighty feedback button on the side of the page. Say what happened. Thanks!

examples

0
source
            
ssh-agent &
xmonad
0
source
            
ssh-agent -k
0
source
            
eval $(ssh-agent -k)
0
source

How to automatically add a protected key to ssh-agent on startup?

GNOME stores your SSH key passphrases in GNOME Keyring, which (the login keyring) is unlocked with your login password by pam_gnome_keyring:

#%PAM-1.0
auth           ...
auth           ...
auth           optional        pam_gnome_keyring.so

session        ...
session        ...
session        optional        pam_gnome_keyring.so auto_start

However, your current setup will not work with this, as you are starting a ssh-agent at the last step, overwriting any environment variables that gnome-keyring may have set. Remove ssh-agent, and try adding this after all keyring daemon processes:

eval $(gnome-keyring-daemon --start)

Keep in mind also that gnome-keyring-daemon publishes a few environment variables over DBus which are then read by gnome-shell, which Awesome doesn't do. That, and you are starting the DBus session bus after all daemons have started, so they may be unable to connect to your session at all.

One more thing: Many of the daemons must be started inside a ConsoleKit session – the PolicyKit authentication agent, for example. You'll have more luck if you replace your entire ~/.xinitrc script with:

exec ck-launch-session dbus-launch --exit-with-session ~/.xinitrc-session

then use ~/.xinitrc-session to launch the rest of GNOME.


You can go an easier way. Use the standard ck-launch-session dbus-launch --exit-with-session gnome-session, and just tell GNOME session manager to launch Awesome as the window manager. Follow the official instructions.

Abridged form for GNOME 2:

mkdir -p ~/.local/share/applications/
cp /usr/share/applications/awesome.desktop ~/.local/share/applications/
cat >> ~/.local/share/applications/awesome.desktop
X-GNOME-WMName=Awesome
X-GNOME-WMSettingsModule=awesome
X-GNOME-Autostart-Phase=WindowManager;Panel
X-GNOME-Provides=windowmanager;panel
X-GNOME-Autostart-Notify=true
[Ctrl-D]
gconftool-2 --set /desktop/gnome/session/required_components/windowmanager --type string awesome

0
source

ssh-agent and screen

Can you launch ssh-agent from an initscript instead of .bash_profile? For instance, I might put

su -c 'ssh-agent -s > ~/.ssh_agent_env' myusername

in the appropriate part of /etc/conf.d/local, although RHEL/Fedora probably uses a different system. As you pointed in your comment, terminal sessions will need to be able to connect to the agent, which is why that command creates the file .ssh_agent_env in the user's home directory. Then you can add

[ -f ~/.ssh_agent_env ] && source ~/.ssh_agent_env >/dev/null

in .bash_profile.

Another thing you could do is put the following in .bash_profile

ps -U myusername | grep -q ssh-agent || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

which will start ssh-agent only if it's not already running. Then you don't have to kill it.

As a slightly different alternative to the second suggestion, instead of checking for the existence of an ssh-agent process, you could check for the existence of the file ~/.ssh_agent_env,

[ -f ~/.ssh_agent_env ] || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

If everything works properly, there shouldn't be any significant difference between the two ways.

0
source

How do I stop ssh-agent from forgetting my password after I login to the screen session from SSH?

On my server ssh (out) I use Funtoo Keychain I use the funtoo keychain on my Ubuntu server. I only have to save the passphrase once per system boot.

Here is information from their site: The Funtoo "Keychain helps you to manage ssh and GPG keys in a convenient and secure manner. It acts as a frontend to ssh-agent and ssh-add, but allows you to easily have one long running ssh-agent process per system, rather than the norm of one ssh-agent per login session." Here are install instructions for Ubuntu-Debian Linux Server keychain

On my Ubuntu client using Xfce I am using Gnome Services. In order to save it I use the Ghome keyring.

0
source

Automate Backups over SSH on a Linux Desktop

You can start ssh-agent when you login to the shell by placing the following in your .profile:

SSH_ENV="$HOME/.ssh/environment"

function start_agent {
     echo "Initialising new SSH agent..."
     /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
     echo succeeded
     chmod 600 "${SSH_ENV}"
     . "${SSH_ENV}" > /dev/null
     /usr/bin/ssh-add;
}

# Source SSH settings, if applicable

if [ -f "${SSH_ENV}" ]; then
     . "${SSH_ENV}" > /dev/null
     #ps ${SSH_AGENT_PID} doesn't work under cywgin
     ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
         start_agent;
     }
else
     start_agent;
fi

0
source

How do I clear out the ssh-agent entries (on Mac OS X )?

Your SSH keys should not get automatically added to the agent just because you SSH'ed to a server...

Run ssh-add -l to list the agent's keys, ssh-add -D to clean out all keys.

0
source

keychain/ssh-agent loading only one key

Doh! I use git to keep my .profile and other configs synced between several machines. My latest git merge didn't merge the way I expected so I had two different lines with calls to keychain only one of which was getting executed.

0
source

ssh-keygen wont work

If it is asking for a "password" your SSH server isn't configured correctly.

If it is asking for a "passphrase" then this is working as intended, if you don't want to have to enter a passphrase while using keys then do not enter a passphrase when creating the key.

Not using a passphrase is a security issue, you should think about your servers situation (importance of what it does, who may be able to access it, etc) before proceeding without a passphrase.

0
source

Linux- passwordless ssh from system (root) script

Nothing wrong with the sudo part. To pick up an existing ssh agent, see these answers: http://superuser.com/questions/141044/sharing-the-same-ssh-agent-among-multiple-login-sessions

description

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA, ECDSA). The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh(1).

The options are as follows:

-a bind_address

Bind the agent to the UNIX-domain socket bind_address. The default is $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>.

-c

Generate C-shell commands on stdout. This is the default if SHELL looks like it’s a csh style of shell.

-d

Debug mode. When this option is specified ssh-agent will not fork.

-k

Kill the current agent (given by the SSH_AGENT_PID environment variable).

-s

Generate Bourne shell commands on stdout. This is the default if SHELL does not look like it’s a csh style of shell.

-t life

Set a default value for the maximum lifetime of identities added to the agent. The lifetime may be specified in seconds or in a time format specified in sshd_config(5). A lifetime specified for an identity with ssh-add(1) overrides this value. Without this option the default maximum lifetime is forever.

If a commandline is given, this is executed as a subprocess of the agent. When the command dies, so does the agent.

The agent initially does not have any private keys. Keys are added using ssh-add(1). When executed without arguments, ssh-add(1) adds the files ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/identity. If the identity has a passphrase, ssh-add(1) asks for the passphrase on the terminal if it has one or from a small X11 program if running under X11. If neither of these is the case then the authentication will fail. It then sends the identity to the agent. Several identities can be stored in the agent; the agent can automatically use any of these identities. ssh-add -l displays the identities currently held by the agent.

The idea is that the agent is run in the user’s local PC, laptop, or terminal. Authentication data need not be stored on any other machine, and authentication passphrases never go over the network. However, the connection to the agent is forwarded over SSH remote logins, and the user can thus use the privileges given by the identities anywhere in the network in a secure way.

There are two main ways to get an agent set up: The first is that the agent starts a new subcommand into which some environment variables are exported, eg ssh-agent xterm &. The second is that the agent prints the needed shell commands (either sh(1) or csh(1) syntax can be generated) which can be evaluated in the calling shell, eg eval ’ssh-agent -s’ for Bourne-type shells such as sh(1) or ksh(1) and eval ’ssh-agent -c’ for csh(1) and derivatives.

Later ssh(1) looks at these variables and uses them to establish a connection to the agent.

The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, private keys are not exposed to clients using the agent.

A UNIX-domain socket is created and the name of this socket is stored in the SSH_AUTH_SOCK environment variable. The socket is made accessible only to the current user. This method is easily abused by root or another instance of the same user.

The SSH_AGENT_PID environment variable holds the agent’s process ID.

The agent exits automatically when the command given on the command line terminates.


see also ~/.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_ecdsa

Contains the protocol version 2 ECDSA authentication identity of the user.

~/.ssh/id_rsa

Contains the protocol version 2 RSA authentication identity of the user.

$TMPDIR/ ssh -XXXXXXXXXX/agent.<ppid>

UNIX-domain sockets used to contain the connection to the authentication agent. These sockets should only be readable by the owner. The sockets should get automatically removed when the agent exits.

ssh, ssh-add , ssh-keygen , sshd


authors

OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH. Markus Friedl contributed the support for SSH protocol versions 1.5 and 2.0.

BSD July 18, 2013 BSD

How can this site be more helpful to YOU ?


give  feedback