ssh [-1246AaCfgkMNnqsTtVvXxY] [user@]hostname [command] [-e escape_char] [-l login_name] [-p port] [-F configfile] [-i identity_file] [-O ctl_cmd] [-o option] [-b bind_address] [-D [bind_address:]port] [-L [bind_address:]port:host:hostport] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-w local_tun[:remote_tun]] [-c cipher_spec] [-m MAC_spec] | ssh-copy-id |
Used to logon to a remote host, using a shell, for executing commands with secure encrypted communications between two untrusted hosts over an insecure network.
Before connecting to a host for the first time, retrieve the SSH host FingerPrint using:
/usr/bin/dig -t SSHFP +short host.example.comIf
dig
does not report the fingerprint it may just be that the administrator didn't bother to set it up.When connecting to a server for the first time, the fingerprint is displayed.
The authenticity of host 'dapie (192.168.1.2)' can't be established. (Since this is my first time!)
RSA key fingerprint is db:b0:c6:0e:63:73:af:87:6b:d9:dd:10:35:99:eb:6e.
or
ECDSA key fingerprint is 61:5f:65:2e:6c:a3:dc:09:57:cd:77:fd:bc:24:95:84
Are you sure you want to continue connecting (yes/no)?
After verifying the finger print by QQQQQQQQ, answer yes
which will add it to ~/.ssh/known_hosts
for subsequent connections.
If the fingerprint does not match
-or-
If dig
did not report the fingerprint, continue and check the files (use: ls -la
).
If they are not what you expect DISCONNECT (don't poke around!)
~.
)
~/.ssh/known_hosts
and delete the entry for this host (check the end of the file). ~/.ssh/known_hosts
for subsequent connections.
host key: is used to verify the identity of the remote host,
To display the host's randomart include -o VisualHostKey=yes
in the ssh command line, or put VisualHostKey=yes
in ~/.ssh/config
.
Host key fingerprint is SHA256:0iQLS2WV1astZFyoKJThVcQKegJeucMSlXS9hmRGFhY +---[RSA 2048]----+ | oo=EB=+o.o | |.. =BB .o . o | |..+oO.oooo . . | | oo=o+oB. + . | | .oo.+ So o | | . o . | | . | | | | | +----[SHA256]-----+If the randomart is unfamiluar there may be a "Man In The Middle" attaack or the host is not the genuine one!
After your identity has been validated command
is executed or a shell prompt is displayed.
ssh
has many variants and many options from antiquity(well pre broadband connection anyway) many of which no longer make sense.
-l login_name | to use on the remote host | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-F [configfile] | default:/.ssh/config .
The system-wide configuration file (/etc/ssh_config ) is ignored.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-v | Verbose mode. display debugging messages. For debugging connection, authentication, and configuration. Multiple -v options increase the verbosity. maximum is 3 For example: -v -v -v
-v OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011 debug1: Reading configuration data /etc/ssh_config debug1: Applying options for * debug1: Connecting to Real-World-Systems.com [174.127.119.33] port 22. debug1: Connection established. debug1: identity file /Users/me/.ssh/id_… type -1 † debug1: identity file /Users/me/.ssh/id_…-cert type -1 debug1: identity file /Users/me/.ssh/id_dsa type -1 debug1: identity file /Users/me/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH_4* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'real-world-systems.com' is known and matches the RSA host key. debug1: Found key in /Users/me/.ssh/known_hosts:5 † debug1: ssh_…: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: /Users/me/.ssh/id_… debug1: Trying private key: /Users/me/.ssh/id_dsa debug1: Next authentication method: password Another eample:
ssh -vvv and another and the diff
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-A | authentication agent connection forwarding. Should be avoided. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-a |
Example:
/usr/bin/ssh -o EscapeChar=_ pi93graf
ssh
obtains configuration data from per-user and system-wide configuration files as
described in ssh_conf.
ssh
exits with the exit status of the remote command or with 255 if an error occurred.
/etc/hosts.equiv
or /etc/shosts.equiv
on the remote machine or /.rhosts
or .shosts
in home directory on the remote machine contains a line containing the name of the client and username, the user is considered for login. The server must be able to verify the client's host key.
ssh-keygen
/Users/me > ssh-keygen -t ecdsa -b 521sic Generating public/private … key pair. Enter file in which to save the key (/Users/me/.ssh/id_…):↵ /Users/me/.ssh/id_… already exists. Overwrite (y/n)? n↵ /Users/me > ssh-keygen -t ecdsa -b 521sic Generating public/private … key pair. Enter file in which to save the key (/Users/me/.ssh/id_…): /Users/me/.ssh/id_….180525†↵ Enter passphrase (empty for no passphrase): ↵ Enter same passphrase again: ↵ Your identification has been saved in /me/me/.ssh/id_….180525. Your public key has been saved in /me/me/.ssh/id… The key fingerprint is: SHA256:bzBkHH9KRJS5ppuqmxVe/aoYaZbcyRmeCRgXEXQDkPk me@localhost The key's randomart image is: +---[… 2048]----+ | .=*++o+o | | o + =o | | ... + o.. | | +Eo ooo | | . o Soo | | o X.X . | | X Ooo . | | = oo. . | | +oo.... | +----[SHA256]-----+
Since is difficult to tell if it has been changed, perhaps by a ne'er-do-well,
randomart
A small deviation in the key will cause a significantly different image.
.ssh/authorized_keys
> ssh-copy-id [-p port] dauser@remoteServer copies the most recent file
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Volumes/DATA/dauser/.ssh/id_….pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
dauser@newHost's password:
Number of key(s) added: 1
--or--
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
(If you think this is a mistake, you may want to use -f
force )
ssh dauser@newHost
or
On your remote host(server)
> cat ~/.ssh/id_….pub | ssh dauser@newHost "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
This example is for encrypting communication between an IRC
client and a server which does not directly support encrypted communications. The user connects to
the remote host using
The
If
If the fingerprint is known, it is matched and the key is accepted.
From ssh 4/04/19 Real-World-Systems.com Host key fingerprint is SHA256:0iQLS2WV1astZFyoKJThVcQKegJeucMSlXS9hmRGFhY
For Real-World-Systems.com
ECDSA key fingerprint is SHA256:AA1Fco7eRba7XiYbqERz9wNls+rDsUWE98f/9IhsEgw.
ECDSA key fingerprint is MD5:e2:08:4d:51:02:0c:19:df:6f:7d:f8:7c:cc:a0:48:a4.
The displayed lines must be added to the zonefile.
the client connects:
See
This example would connect client network 10.0.50.0/24 with
remote network 10.0.99.0/24 using a point-to-point connection from
10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway
to the remote network, at 192.168.1.15, allows it.
The following
entry would permit connections on tun(4) device 1 from /etc/ssh_known_hosts
is checked for known hosts.
~/.ssh/known_hosts
contains identification for hosts.
New hosts can be added by ssh
on first connection.The authenticity of host '192.168.3.1 (192.168.3.1)' can't be established.
RSA key fingerprint is SHA256:AI+Xndd4h3tbWICI+Q1BEuKKu1REAocsIimS3pWjA.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.3.1' (…) to the list of known hosts.
If a host's identification differs from the previous one, ssh
reports:
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
SHA256:MhtvZsNm5yqnKqKv8/trTiJiK4FmqdQrsKUSk5klXfk.
Please contact your system administrator.
Add correct host key in /Users/dauser/.ssh/known_hosts to get rid of this message.
Offending DSA key in /Users/dauser/.ssh/known_hosts:9
DSA host key for theDomain.com has changed and you have requested strict checking.
Host key verification failed.
and disables password authentication.StrictHostKeyChecking
option controls logins to machines whose host key is not known or has changed.
TCP FORWARDING
Forwarding an arbitrary TCP connections over the secure channel can be specified either on the command line or in a configuration file.
One application is a secure connection to a mail server; another is going through firewalls.
ssh
, specifying a port to be used to forward connections to the remote server. Then starts the
service which is to be encrypted on the client machine, connecting to the
same local port, and ssh
will encrypt and forward the connection.
$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10
$ irc -c '#users' -p 1234 pinky 127.0.0.1
This tunnels a connection to IRC server server.example.com
, joining
channel #users
, using port 1234 and nickname pinky
. It doesn't matter which port is used, as long as it
doesn't conflict with ports already in use and
is greater than 1023 ( only processes with root priveledge can open sockets below 1024.)
The connection is forwarded to port 6667 on the remote server, the standard port for IRC services.
-f
Backgrounds ssh and sleep 10
is
specified to allow some time to start the service which is to be tunnelled. If no connections are made
within the time specified, ssh exits.
X11 FORWARDING
If ForwardX11
is set to yes
or
-X, -x, and -Y
) and the user is using X11 ($DISPLAY
environment variable is set), the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell (or command) will go through the encrypted
channel, and the connection to the real X server will be made from the
local machine. The user should not manually set DISPLAY
. Forwarding of
X11 connections can be configured on the command line or in configuration files.
$DISPLAY
value set by ssh
will point to the server machine, but with a
display number greater than zero. This is normal, and happens because
ssh creates a proxy
X server on the server machine for forwarding the
connections over the encrypted channel.
ssh
will also automatically set up Xauthority
data on the server sysetm.
For this purpose, it will generate a random authorization cookie, store
it in Xauthority on the server, and verify that any forwarded connections
carry this cookie and replace it by the real cookie when the connection
is opened. The real authentication cookie is never sent to the server
system (and no cookies are sent in the plain).
ForwardAgent
is set to yes
(or
-A and -a
) and the user is using an authentication
agent, the connection to the agent is automatically forwarded to the remote side.
Verifying Host KEYS
Fingerprints are generated using from the hosts private key file: ssh-keygen
:
$ ssh-keygen -l -f /etc/ssh_host_…
2048 7c:df:03:a8:49:1d:38:19:f7:f9:d7:13:3d:40:4d:f0 (…)
SSH FingerPrints may be availale through the DNS (Domain Name System).
A resource record (RR
), SSHFP, is added to a zonefile and the
connecting client is able to match the fingerprint with that of the key presented.
ssh-keygen -r real-world-systems.com # domain name can be anything and prefixes the records
real-world-systems.com IN SSHFP 1 1 ab1454f8dee3955b89b137f88c765ab3ff54a12e
real-world-systems.com IN SSHFP 1 2 0404389c97116e9e0a7577a59f4e50f19159d28ea10a16a27b9d3d695cdb5ac1
real-world-systems.com IN SSHFP 2 1 cea9b5762b439a81592ae81730176307e0bd4a21
real-world-systems.com IN SSHFP 2 2 73742e8157fe150dc20e1481dee2e4121295b41b6d61ec43f726cf9295e6ded9
real-world-systems.com IN SSHFP 3 1 44242fde7d79fc316d52acfeac0d330aebe9a8e6
real-world-systems.com IN SSHFP 3 2 c608578c4a032d2ead79d4007a1bbf9fd24da54668125140a25f9a5558a412c7
real-world-systems.com IN SSHFP 4 1 3556fb30d5b4e2bde08ab62b4b8652ed78011c99
real-world-systems.com IN SSHFP 4 2 a70e22ea7f3765e7661956ae0e05446e6ee80c4fb7ebd1d9174cf1e2c7369dba
Put VerifyHostKeyDNS ask
in your SSH client's config, usually ~/.ssh/config.
.
To retrieve the fingerprint :
dig -t SSHFP host.example.com +short
ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
VerifyHostKeyDNS
in ssh_config(5)
SSH-BASED VIRTUAL PRIVATE NETWORKS
ssh contains support for Virtual Private Network (VPN) tunnelling using
the tun(4) network pseudo-device, allowing two networks to be joined
securely.
ssh_config
PermitTunnel controls
If the server supports this, and at what level (layer 2 or 3 traffic).
On the client:
> ssh -f -w 0:1 192.168.1.15 true
> ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
> route add 10.0.99.0/24 10.1.1.2
On the server:
> ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
> route add 10.0.50.0/24 10.1.1.1
Client access may be more finely tuned via /root/.ssh/authorized_keys
and the PermitRootLogin
server option. jane
and
on tun device 2 from john
, if PermitRootLogin is set to forced-commands-only
:
tunnel="1",command="sh /etc/netstart tun1" ssh-… ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-… ... john
Since an SSH-based setup entails a fair amount of overhead, it may be
more suited to temporary setups, such as for wireless VPNs.
More permanent VPNs are better provided by tools such as ipsecctl and
isakmpd.
~/scriptname
is not treated as an escape. ~? | list escape pairs. |
~~ | transmit ~ |
~C | Open command line. !command executes a command on the local host
allows addition of |
~B | Send BREAK |
~# | List forwarded connections. |
~R | Request rekeying of the connection |
~. | Disconnect. |
~^Z | Background ssh. |
~& | Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate. |
The escape character can be changed in configuration files with the EscapeChar
or on the command line with -e
.
(default: ~).
Setting the character to none
disables escapes and makes the session fully transparent.
X11 connections and arbitrary TCP ports can be forwarded over the secure channel.
All communication is encrypted.
$DISPLAY | Location of the X11 server hostname:n
|
ssh
reads ~/.ssh/environment
, and adds lines of the format
VARNAME=value
to the environment if users are allowed to change their environment.
See PermitUserEnvironment
in sshd_config
.
StrictHostKeyChecking
has been disabled).
~/.rhosts
for host‑based authentication. owned by the user, must be 700
~/.ssh/authorized_keys
public keys (RSA/DSA) . sshd
~/.ssh/config
configuration file. ssh_config
~/.ssh/environment
additional definitions >
~/.ssh/identity
~/.ssh/id_dsa
~/.ssh/id_…
private key for authentication. must be 700
~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_….pub
public key
~/.ssh/known_hosts
list of host keys for all hosts the user has logged into not in systemwide known hosts.
~/.ssh/rc
Commands executed when the user logs in, before the user's shell (or command) is started.
/etc/hosts.equiv
for host‑based authentication (see above). It should only be writable by root.
/etc/shosts.equiv
like hosts.equiv
, but allows host‑based authentication without permitting login with rlogin/rsh
.
etc/ssh_config
Systemwide configuration
/etc/ssh_config.system_default
differes only in the 2 (also commented out) lines:GSSAPI Authentiation and KeyExchange
/etc/ssh_host_key
/etc/ssh_host_dsa_key
/etc/ssh_host_…
private parts of the host keys and are used for host‑based authentication.
/etc/ssh_known_hosts
Systemwide known host keys.
/etc/sshrc
Commands executed at logs in, before the shell (or command) is started.
-f
)/home
cat
to get the keys.
Address 174.327.119.33 maps to our-systems.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
/usr/bin/ssh-copy-id: ERROR: No identities found
ssh_dispatch_run_fatal: Connection to 192.168.3.1 port 22: Broken pipe: The server disconnected most likely due to timeout There is a mismatch in the DNS system.
dig our-systems.com
and determine which address is correct and have the DNS records corrected.
ssh_exchange_identification: Connection closed by remote host
-v
tried again and it worked.
to GoDaddy 7/29/14
> /usr/bin/ssh -vl m4685586 autoinsurancecoverageverify.com OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug1: /etc/ssh_config line 102: Applying options for * debug1: Connecting to autoinsurancecoverageverify.com [50.63.41.190] port 22. debug1: Connection established. debug1: identity file /Users/me/.ssh/id_… type 1 debug1: identity file /Users/me/.ssh/id_…-cert type -1 debug1: identity file /Users/me/.ssh/id_dsa type -1 debug1: identity file /Users/dgerman/.ssh/id_dsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2 ssh_exchange_identification: Connection closed by remote host > echo $? 255
You don't exist. Go Away!
ssh xxx
produces the same message clarifying any network issues.su user2
then ssh host
works fine!.From
ssh-keygen.c /* we need this for the home * directory. */ pw = getpwuid(getuid()); if (!pw) { printf("You don't exist, go away!\n"); exit(1);and
ssh.c pw = getpwuid(original_real_uid); if (!pw) { logit("You don't exist, go away!"); exit(255);
echo $?
to see who it was.
getpwuid
should return:
char *pw_name User's login name. uid_t pw_uid Numerical user ID. gid_t pw_gid Numerical group ID. char *pw_dir Initial working directory. char *pw_shell Program to use as shell.
Intesteringly
/var/log/warn
contains:
coreservicesd[38]: _scserver_ServerCheckin: client uid validation failure; getpwuid(503) == NULL
/var/log/notice
for May 5 08:01:26 2012contains:applepushserviced[90]: <APSCourier: 0x102e27bb0>: Stream error occurred for <APSTCPStream: 0x7fe46351c1e0>: The operation couldn't be completed. Socket is not connected applepushserviced[90]: <APSCourier: 0x102e27bb0>: Stream error occurred for <APSTCPStream: 0x7fe46351c1e0>: The operation couldn't be completed. (kCFErrorDomainCFNetwork error 2. com.apple.var-db-shadow-backup[92780]: Error adding file shadow
ssh_exchange_identification: read: Connection reset by peer
Host is down
Operation timed out
no matching host key type found. Their offer: ssh-…
~/.ssh/config Host ssh.dev.azure.com User git PubkeyAcceptedAlgorithms +ssh-… HostkeyAlgorithms +ssh-…deprecated name PubkeyAcceptedKeyTypes instead of PubkeyAcceptedAlgorithms
ERROR: No identities found
Permission denied (publickey)
Definitive: OpenSSH for OpenBSD
ssh-copy-id [-f] [-n] [-s] [-i [identity_file]] [-p port] [-o ssh_option] [user@]hostname
ssh-copy-id -h | -?
Assembles fingerprints and enables logins with those keys on the remote host
by appending them to the remote user's ~/.ssh/authorized_keys
-i identity_file[.pub] |
Default behaviour without -i
use output from ssh-add -L
.
This results in the comment on the key being the filename that was given to ssh-add
when the key was loaded into your
ssh-agent rather than the comment contained in that file. Otherwise, if ssh-add
provides no keys contents of the default_ID_file will be used.
The default_ID_file
is the most recent file that matches: ~/.ssh/id*.pub
(excluding those that match ~/.ssh/*-cert.pub
)
touch
a key's .pub
(making it newest) to have ssh-copy-id
use a specific file.
ssh-agent
. -c
,
then load one or more old keys into the agent, possibly by ssh-ing to the client machine that has that old
key, using -A
to allow agent forwarding:
user@newclient$ ssh-add user@newclient$ ssh -A old.client user@oldl$ ssh-add -c ... prompt for pass-phrase ... user@old$ logoff user@newclient$ ssh someserver
-i
in this case is to ensure that the comment on the installed key is the
one from the .pub
, rather than the filename that was loaded into your agent. It also ensures that only the id
you intended is installed, rather than all the keys that you have in your ssh-agent. You can specify
another id, or use the contents of the ssh-agent as you prefer.
Use ssh-add -c
when using agent forwarding to avoid keys from
being hijacked, It is better to use ssh's ProxyCommand and -W
, to bounce through remote
servers while always doing direct end-to-end authentication. This way the middle hop(s) don't get access to your
ssh-agent.
Do a web search for ssh proxycommand nc
(use the -W
rather than nc).
ssh-add [-cDdkLlXx] [-E fingerprint_hash] [-t lifetime ]
[file ]
ssh-add -e|-s pkcs11
Adds private key identities to the authentication agent, ssh-agent(1).
Without arguments, it adds
~/.ssh/id_…, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/identity
.
After loading a private key, loads the corresponding certificate information from the filename obtained by appending -cert.pub
to the name of the private key file.
Alternative file names can be given on the command line.
If a file requires a passphrase, it is accepted from the tty. The last passphrase is used if multiple identity files are given.
The authentication agent must be running and the $SSH_AUTH_SOCK
must contain the name of its socket
-c |
$DISPLAY
and $SSH_ASKPASS
ssh-add
needs a passphrase, it will read it from the current terminal. $DISPLAY
and SSH_ASKPASS
are set,
it will execute the program specified by $SSH_ASKPASS
(default ssh-askpass
) and
open an X11 window to read the passphrase. Useful when using an .xsession or related script. /dev/null
.
$SSH_AUTH_SOCK
Path of a UNIX-domain socket used to communicate with the agent.
version 1 RSA | ~/.ssh/identity |
ssh-add
ignores identity files if they are accessible by others.
ssh-agent [-c | -s] [-Dd] [-a bind_address] [-E fingerprint_hash] [-t lifetime] [command [arg ...]]
ssh-agent [-c | -s] -k
Holds private keys used for public key authentication (RSA, DSA, ECDSA, Ed25519).
Usually started in the beginning of an X-session or a login session, and all other windows or programs are started as
clients to ssh-agent
. Environment variables allow the agent to be located and used
for authentication when logging in to other machines using ssh
.
The agent initially does not have any private keys. Keys are added using ssh-add
. Multiple identities may be stored
concurrently and ssh
will use them if present.
ssh-add
removes and query the keys that are held.
-a bind_address |
If a commandline is given, this is executed as a subprocess of the agent. When the command dies, so does the agent.
The agent is run in the user's local terminal. Authentication data need not be stored on any other machine and authentication passphrases don't go over the network. The connection to the agent is forwarded over SSH remote logins and the user can use the privileges given by the identities anywhere in the network in a secure way.
ssh-agent xterm &
.i
eval `ssh-agent -s`
for
Bourne-type shells such as sh(1) or ksh(1)
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 not send a private key over its request channel. 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 $SSH_AUTH_SOCK
. The
socket is made accessible only to the current user.
This method is easily abused by root or another instance of the same user.
$SSH_AGENT_PID
contains the agent's process ID.
The agent exits automatically when the command given on the command line terminates.