| ssh [-1246AaCfgkMNnqsTtVvXxY] [user@]hostname [command] [-e escape_char] [-l login_name] [-p port] [-F configfile] [-i identity_file] [-O ctl_cmd] [-S ctl_path] [-b bind_address] [-D [bind_address:]port] [-L [bind_address:]port:host:hostport] [-R [bind_address:]port:host:hostport] [-w local_tun[:remote_tun]] [-c cipher_spec] [-m MAC_spec] [-o option] | ssh-copy-id ssh-add |
Used to logon to a remote host, using a shell, for executing commands with secure encrypted communications over an insecure network.
Before connecting to a host for the first time, retrieve the SSH host FingerPrint using:
ssh-keygen -r example.netWhen 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)?If the finger print matches that displayed with
dig, answeryeswhich will add it to~/.ssh/known_hostsfor subsequent connections.If
digdid not report the fingerprint, continue and check the files (use:ls -la).
If they are not what you expect -or- if the fingerprint does not match
If there is nothing to use to verify the fingerprint, continue but beware that the finger print will be added to
- terminate the connection ( via
~.)- Contact the host's administrator and explain that you had a connection spoofed. Have your password changed.
- edit
~/.ssh/known_hostsand delete the entry for this host (check the end of the file).
~/.ssh/known_hostsfor subsequent connections.Copy/paste the randomart into a file for future comparision.
host key: is used to verify the identity of the remote host,
To display the host's randomart include-o VisualHostKey=yesin the ssh command line,
or to displayrandomartat every login, putVisualHostKey=yesin~/.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" attack or the host is not the the one you expect(perhaps an rogue DNS server has provided the incorrect IP address!).
After your identity has been validated
commandis executed or a shell prompt is displayed.
sshhas many variants and many options from antiquity(well pre broadband connection anyway) many of which no longer make sense.OPtions are deatiled in ssh_config
-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 debug1: pledge: filesystem fullAfter successful authentication environment is established and readyfor user inout.
Another example:
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↵Since you already have a key of this thpe , skip ahead to/Users/me > ssh-keygen -t ecdsa -b 521 sic ( type )(-t can be ecdsa, ed25519, dsa, rsa GoTeleport discussion.ssh-id-copy
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,
a small deviation in the key will cause a significantly difference in the randomart 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.
For Real-World-Systems.com
To retrieve the fingerprint :
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.
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 the hosts private key file crerated with ssh-keygen:
$ ssh-keygen -l -f /etc/ssh_host_&210D;
2048 7c:df:03:a8:49:1d:38:19:f7:f9:d7:13:3d:40:4d:f0 (&210D;)
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 prefixes the records.
real-world-systems.com IN SSHFP 1 1 ab54f8dee3955b89b137f88c765ab3ff54a12e
real-world-systems.com IN SSHFP 1 2 04389c97116e9e0a7577a59f4e50f19159d28ea10a16a27b9d3d695cdb5ac1
real-world-systems.com IN SSHFP 2 1 ceb5762b439a81592ae81730176307e0bd4a21
real-world-systems.com IN SSHFP 2 2 732e8157fe150dc20e1481dee2e4121295b41b6d61ec43f726cf9295e6ded9
real-world-systems.com IN SSHFP 3 1 442fde7d79fc316d52acfeac0d330aebe9a8e6
real-world-systems.com IN SSHFP 3 2 c6578c4a032d2ead79d4007a1bbf9fd24da54668125140a25f9a5558a412c7
real-world-systems.com IN SSHFP 4 1 35fb30d5b4e2bde08ab62b4b8652ed78011c99
real-world-systems.com IN SSHFP 4 2 a722ea7f3765e7661956ae0e05446e6ee80c4fb7ebd1d9174cf1e2c7369dba
Put VerifyHostKeyDNS ask in your SSH client's config, usually ~/.ssh/config..
ssh 4/04/19 Real-World-Systems.com Host key fingerprint is SHA256:0iQLS2WV1astZFyoKJThVcQKegJeucMSlXS9hmRGFhY
.
ECDSA key fingerprint is SHA256:AFco7eRba7XiYbqERz9wNls+rDsUWE98f/9IhsEgw.
ECDSA key fingerprint is MD5:e2:04d:51:02:0c:19:df:6f:7d:f8:7c:cc:a0:48:a4
The displayed lines must be added to the zonefile. 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.
Escape Character pairs
Used to communicate with ssh (not the remote host) once connected.
Valid escape pairs are only recognized at the beginning of a line. Typing ~/scriptname is not treated as an escape.
Default escape leadin is ~
| ~? | 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.equivlike 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.
tun, hosts.equiv(5), ssh_config(5), ssh-keysign(8), sshd(8)
-f )/homecat 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
Verification code: Some sites require a TOTP (Time-based One-Time Password) providedd by an Authenticator, perhaps OpenAuthenticator
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_ASKPASSssh-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 /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.
Runs with group execute sticky bit. ---x--s--x 1 root nobody ssh-agent
$SSH_AGENT_PID contains the agent's process ID.