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
examples
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
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.
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.
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
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.
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.
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.
source
Linux- passwordless ssh from system (root) script
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