1ssh(1)                           User Commands                          ssh(1)
2
3
4

NAME

6       ssh - secure shell client (remote login program)
7

SYNOPSIS

9       ssh [-l login_name] hostname | user@hostname [ command]
10
11
12       ssh [-afgknqstvxACNTX1246] [-b bind_address] [-m mac_spec]
13            [-c cipher_spec] [-e escape_char] [-i identity_file]
14            [-l login_name] [-F configfile] [-o option] [-p port]
15            [-L [bind_address:]port:host:hostport]
16            [-R [bind_address:]port:host:hostport]
17            [-D [bind_address:]port] hostname | user@hostname [command]
18
19

DESCRIPTION

21       ssh  (Secure  Shell) is a program for logging into a remote machine and
22       for executing commands on a remote machine. It is intended  to  replace
23       rlogin  and rsh, and to provide secure encrypted communications between
24       two untrusted hosts over an insecure network. X11 connections and arbi‐
25       trary TCP/IP ports can also be forwarded over the secure channel.
26
27
28       ssh  connects and logs into the specified hostname. The user must prove
29       his or her identity to the remote machine using one of several  methods
30       depending on the protocol version used:
31
32   SSH Protocol Version 1
33       First,   if   the   machine   the  user  logs  in  from  is  listed  in
34       /etc/hosts.equiv or /etc/shosts.equiv on the remote  machine,  and  the
35       user  names are the same on both sides, the user is immediately permit‐
36       ted to log in. Second, if .rhosts or .shosts exists in the user's  home
37       directory on the remote machine and contains a line containing the name
38       of the client machine and the name of the user  on  that  machine,  the
39       user  is permitted to log in. This form of authentication alone is nor‐
40       mally not allowed by the server because it is not secure.
41
42
43       The second  (and  primary)  authentication  method  is  the  rhosts  or
44       hosts.equiv  method  combined  with  RSA-based  host authentication. It
45       means  that  if  the  login  would  be  permitted   by   $HOME/.rhosts,
46       $HOME/.shosts, /etc/hosts.equiv, or /etc/shosts.equiv, and if addition‐
47       ally   the   server   can   verify   the   client's   host   key   (see
48       /etc/ssh_known_hosts  in the FILES section), only then is login permit‐
49       ted. This authentication method closes security holes due to IP  spoof‐
50       ing, DNS spoofing, and routing spoofing.
51
52
53       Note  to  the  administrator:  /etc/hosts.equiv, $HOME/.rhosts, and the
54       rlogin/rsh protocol in general, are inherently insecure and  should  be
55       disabled if security is desired.
56
57
58       As  a  third  authentication method, ssh supports RSA-based authentica‐
59       tion. The scheme is based on public-key cryptography. There  are  cryp‐
60       tosystems where encryption and decryption are done using separate keys,
61       and it is not possible to derive the decryption key from the encryption
62       key.  RSA is one such system. The idea is that each user creates a pub‐
63       lic/private key pair for authentication purposes. The server knows  the
64       public  key,  and  only  the  user  knows  the  private  key.  The file
65       $HOME/.ssh/authorized_keys lists the public keys that are permitted for
66       logging  in.  When  the  user logs in, the ssh program tells the server
67       which key pair it would like to  use  for  authentication.  The  server
68       checks  if  this  key is permitted, and if so, sends the user (actually
69       the ssh program running on behalf of the user) a challenge in the  form
70       of  a  random number, encrypted by the user's public key. The challenge
71       can only be decrypted using the proper private key. The  user's  client
72       then  decrypts  the challenge using the private key, proving that he or
73       she knows the private key but without disclosing it to the server.
74
75
76       ssh implements the RSA authentication protocol automatically. The  user
77       creates  his  or her RSA key pair by running ssh-keygen(1). This stores
78       the  private  key  in  $HOME/.ssh/identity  and  the  public   key   in
79       $HOME/.ssh/identity.pub  in  the user's home directory. The user should
80       then copy the identity.pub to $HOME/.ssh/authorized_keys in his or  her
81       home  directory  on the remote machine (the authorized_keys file corre‐
82       sponds to the conventional $HOME/.rhosts file,  and  has  one  key  per
83       line,  though the lines can be very long). After this, the user can log
84       in without giving the password. RSA authentication is much more  secure
85       than rhosts authentication.
86
87
88       The  most  convenient  way  to  use  RSA  authentication can be with an
89       authentication agent. See ssh-agent(1) for more information.
90
91
92       If other authentication methods fail, ssh prompts the user for a  pass‐
93       word.  The  password  is sent to the remote host for checking. However,
94       since all communications are encrypted, the password cannot be seen  by
95       someone listening on the network.
96
97   SSH Protocol Version 2
98       The  SSH version 2 protocol supports multiple user authentication meth‐
99       ods, some of which are similar to those available with the SSH protocol
100       version 1. These authentication mechanisms are negotiated by the client
101       and server, with the client trying methods in the  order  specified  in
102       the  PreferredAuthentications  client  configuration option. The server
103       decides when enough authentication methods have passed successfully  so
104       as to complete the authentication phase of the protocol.
105
106
107       When  a  user connects by using protocol version 2, similar authentica‐
108       tion methods are available. Using the default values  for  PreferredAu‐
109       thentications,  the  client  tries  to  authenticate first by using the
110       hostbased method. If this method fails, public  key  authentication  is
111       attempted.  Finally,  if  this  method  fails, keyboard-interactive and
112       password authentication are tried.
113
114
115       The public key method is similar to RSA authentication described in the
116       previous  section  and  allows the RSA or DSA algorithm to be used: The
117       client  uses   his   or   her   private   key,   $HOME/.ssh/id_dsa   or
118       $HOME/.ssh/id_rsa,  to sign the session identifier and sends the result
119       to the server. The server checks whether the  matching  public  key  is
120       listed  in $HOME/.ssh/authorized_keys and grants access if both the key
121       is found and the  signature  is  correct.  The  session  identifier  is
122       derived  from  a  shared  Diffie-Hellman value and is only known to the
123       client and the server.
124
125
126       If public key authentication fails or is not available, a password  can
127       be  sent  encrypted to the remote host for proving the user's identity,
128       or an extended prompt/reply protocol can be engaged.
129
130
131       Additionally, ssh supports hostbased or challenge response  authentica‐
132       tion.
133
134
135       Protocol  2  provides  additional  mechanisms  for confidentiality (the
136       traffic is encrypted using 3DES,  Blowfish,  CAST128  or  Arcfour)  and
137       integrity  (hmac-sha1,  hmac-md5).  Protocol 1 lacks a strong mechanism
138       for ensuring the integrity of the connection.
139
140   Login Session and Remote Execution
141       When the user's identity has been accepted by the  server,  the  server
142       either  executes  the  specified  command, or logs into the machine and
143       gives the user a normal shell on the remote machine. All  communication
144       with the remote command or shell is automatically encrypted.
145
146
147       If  a  pseudo-terminal  has  been allocated (normal login session), the
148       user can use the escape characters noted below.  If  a  pseudo-terminal
149       has been allocated (normal login session), the user can disconnect with
150       ~., and suspend ssh with ~^Z. All forwarded connections can  be  listed
151       with ~#. If the session blocks waiting for forwarded X11 or TCP/IP con‐
152       nections to terminate, ssh can be backgrounded with ~&,  although  this
153       should  not be used while the user shell is active, as it can cause the
154       shell to hang. All available escapes can be listed with ~?.
155
156
157       A single tilde character can be sent as ~~, or by following  the  tilde
158       with a character other than those described above. The escape character
159       must always follow a newline to be interpreted as special.  The  escape
160       character can be changed in configuration files or on the command line.
161
162
163       If no pseudo tty has been allocated, the session is transparent and can
164       be used to reliably transfer binary data. On most systems, setting  the
165       escape character to "none" also makes the session transparent even if a
166       tty is used.
167
168
169       The session terminates when the command or shell on the remote  machine
170       exits  and  all  X11  and TCP/IP connections have been closed. The exit
171       status of the remote program is returned as the exit status of ssh.
172
173   Escape Characters
174       When a pseudo-terminal has been requested, ssh  supports  a  number  of
175       functions through the use of an escape character.
176
177
178       A  single  tilde  character can be sent as ~~ or by following the tilde
179       with a character other than those described below. The escape character
180       must  always  follow a newline to be interpreted as special. The escape
181       character can be changed in configuration files  using  the  EscapeChar
182       configuration directive or on the command line by the -e option.
183
184
185       The supported escapes, assuming the default ~, are:
186
187       ~.     Disconnect.
188
189
190       ~^Z    Background ssh.
191
192
193       ~#     List forwarded connections.
194
195
196       ~&     Background ssh at logout when waiting for forwarded connection /
197              X11 sessions to terminate.
198
199
200       ~?     Display a list of escape characters.
201
202
203       ~B     Send a break to the remote system. Only useful for SSH  protocol
204              version 2 and if the peer supports it.
205
206
207       ~C     Open command line. Only useful for adding port forwardings using
208              the -L and -R options).
209
210
211       ~R     Request rekeying of the connection. Only useful for SSH protocol
212              version 2 and if the peer supports it.
213
214
215   X11 and TCP Forwarding
216       If  the  ForwardX11 variable is set to ``yes'' (or, see the description
217       of the -X and -x options described later) and the  user  is  using  X11
218       (the  DISPLAY  environment  variable is set), the connection to the X11
219       display is automatically forwarded to the remote side  in  such  a  way
220       that  any X11 programs started from the shell (or command) goes through
221       the encrypted channel, and the connection to the real X server is  made
222       from  the local machine. The user should not manually set DISPLAY. For‐
223       warding of X11 connections can be configured on the command line or  in
224       configuration files.
225
226
227       The  DISPLAY  value set by ssh points to the server machine, but with a
228       display number greater than zero. This is normal behavior, because  ssh
229       creates  a  "proxy" X11 server on the server machine for forwarding the
230       connections over the encrypted channel.
231
232
233       ssh also automatically sets up Xauthority data on the  server  machine.
234       For  this purpose, it generates a random authorization cookie, store it
235       in Xauthority on the server, and verify that any forwarded  connections
236       carry this cookie and replace it by the real cookie when the connection
237       is opened. The real authentication cookie is never sent to  the  server
238       machine (and no cookies are sent in the plain).
239
240
241       If  the  ForwardAgent variable is set to "yes" (or, see the description
242       of the -A and -a options described later) and  the  user  is  using  an
243       authentication agent, the connection to the agent is automatically for‐
244       warded to the remote side.
245
246
247       Forwarding of arbitrary TCP/IP connections over the secure channel  can
248       be specified either on the command line or in a configuration file. One
249       possible application of TCP/IP forwarding is a secure connection to  an
250       electronic purse. Another possible application is firewall traversal.
251
252   Server Authentication
253       ssh  automatically maintains and checks a database containing identifi‐
254       cations for all hosts it has ever been used with. Host keys are  stored
255       in  $HOME/.ssh/known_hosts  in the user's home directory. Additionally,
256       the file /etc/ssh_known_hosts is automatically checked for known hosts.
257       The  behavior of ssh with respect to unknown host keys is controlled by
258       the StrictHostKeyChecking parameter. If a  host's  identification  ever
259       changes,  ssh  warns about this and disables password authentication to
260       prevent a trojan horse from getting the user's password.  Another  pur‐
261       pose  of  this  mechanism is to prevent attacks by intermediaries which
262       could otherwise be used to circumvent the encryption. The  StrictHostK‐
263       eyChecking  option can be used to prevent logins to machines whose host
264       key is not known or has changed.
265
266
267       However, when using key exchange protected by GSS-API, the  server  can
268       advertise  a  host  key. The client automatically adds this host key to
269       its known hosts file, $HOME/.ssh/known_hosts, regardless of the setting
270       of  the  StrictHostKeyChecking  option,  unless the advertised host key
271       collides with an existing known hosts entry.
272
273
274       When the user's GSS-API credentials expire, the client continues to  be
275       able to rekey the session using the server's public host key to protect
276       the key exchanges.
277
278   GSS-API User and Server Authentication
279       ssh uses the user's GSS-API credentials to authenticate the  client  to
280       the  server wherever possible, if GssKeyEx and/or GssAuthentication are
281       set.
282
283
284       With GssKeyEx, one can have an SSHv2 server that  has  no  host  public
285       keys,  so  that  only GssKeyEx can be used. With such servers, rekeying
286       fails if the client's credentials are expired.
287
288
289       GSS-API user authentication has the disadvantage that it does not obvi‐
290       ate  the need for SSH host keys, but its failure does not impact rekey‐
291       ing. ssh can try other authentication  methods  (such  as  public  key,
292       password, and so on) if GSS-API authentication fails.
293
294
295       Delegation of GSS-API credentials can be quite useful, but is not with‐
296       out danger. As with passwords, users should not  delegate  GSS  creden‐
297       tials to untrusted servers, since a compromised server can use a user's
298       delegated GSS credentials to impersonate the user.
299
300
301       GSS-API user authorization is covered in gss_auth_rules(5).
302
303
304       Rekeying can be used to redelegate credentials when GssKeyEx is  "yes".
305       (See ~R under Escape Characters above.)
306

OPTIONS

308       The following options are supported:
309
310       -1
311
312           Forces ssh to try protocol version 1 only.
313
314
315       -2
316
317           Forces ssh to try protocol version 2 only.
318
319
320       -4
321
322           Forces ssh to use IPv4 addresses only.
323
324
325       -6
326
327           Forces ssh to use IPv6 addresses only.
328
329
330       -a
331
332           Disables forwarding of the authentication agent connection.
333
334
335       -A
336
337           Enables forwarding of the authentication agent connection. This can
338           also be specified on a per-host basis in a configuration file.
339
340           Agent forwarding should be enabled with  caution.  Users  with  the
341           ability  to  bypass  file  permissions  on the remote host (for the
342           agent's UNIX-domain socket) can access the local agent through  the
343           forwarded  connection.  An attacker cannot obtain key material from
344           the agent. However, the attacker can perform operations on the keys
345           that  enable  the  attacker  to  authenticate  using the identities
346           loaded into the agent.
347
348
349       -b bind_address
350
351           Specifies the interface to transmit from on machines with  multiple
352           interfaces or aliased addresses.
353
354
355       -c cipher_spec
356
357           Selects the cipher specification for encrypting the session.
358
359           For  protocol  version  1,  cipher_spec is a single cipher. See the
360           Cipher option in ssh_config(4) for more information.
361
362           For protocol version 2, cipher_spec is a  comma-separated  list  of
363           ciphers  listed  in  order of preference. See the Ciphers option in
364           ssh_config(4) for more information.
365
366
367       -C
368
369           Requests compression of all data (including stdin, stdout,  stderr,
370           and data for forwarded X11 and TCP/IP connections). The compression
371           algorithm is the same used by gzip(1). The gzip man page is  avail‐
372           able in the SUNWsfman package. The "level" can be controlled by the
373           CompressionLevel option (see ssh_config(4)). Compression is  desir‐
374           able on modem lines and other slow connections, but only slows down
375           things on fast networks. The default value can be set on a host-by-
376           host  basis  in the configuration files. See the Compression option
377           in ssh_config(4).
378
379
380       -D [bind_address:]port
381
382           Specifies a local dynamic application-level port  forwarding.  This
383           works  by  allocating a socket to listen to port on the local side,
384           optionally bound to the specified bind_address. Whenever a  connec‐
385           tion  is  made  to  this port, the connection is forwarded over the
386           secure channel. The application protocol is then used to  determine
387           where  to connect to from the remote machine. Currently, the SOCKS4
388           and SOCKS5 protocols are supported and ssh acts as a SOCKS  server.
389           Only  a  user  with enough privileges can forward privileged ports.
390           Dynamic port forwardings can also be specified in the configuration
391           file.
392
393           IPv6  addresses  can  be  specified  with  an  alternative  syntax:
394           [bind_address/]port or by enclosing the address in square brackets.
395           By default, the local port is bound in accordance with the Gateway‐
396           Ports setting. However, an explicit bind_address  can  be  used  to
397           bind  the  connection  to  a  specific address. The bind_address of
398           localhost indicates that the listening port be bound for local  use
399           only, while an empty address or * indicates that the port should be
400           available from all interfaces.
401
402
403       -e ch | ^ch | none
404
405           Sets the escape character for sessions with a pty  (default:  `~').
406           The escape character is only recognized at the beginning of a line.
407           The escape character followed by a dot (.) closes  the  connection.
408           If  followed  by  CTRL-z, the escape character suspends the connec‐
409           tion. If followed by itself,  the  escape  character  sends  itself
410           once.  Setting the character to none disables any escapes and makes
411           the session fully transparent.
412
413
414       -f
415
416           Requests ssh to go to background  just  before  command  execution.
417           This is useful if ssh is going to ask for passwords or passphrases,
418           but the user wants it  in  the  background.  This  implies  the  -n
419           option.  The recommended way to start X11 programs at a remote site
420           is with something like ssh -f host xterm.
421
422
423       -F configfile
424
425           Specifies an alternative per-user configuration file. If a configu‐
426           ration  file is specified on the command line, the system-wide con‐
427           figuration file, /etc/ssh_config, is ignored. The default  for  the
428           per-user configuration file is $HOME/.ssh/config.
429
430
431       -g
432
433           Allows remote hosts to connect to local forwarded ports.
434
435
436       -i identity_file
437
438           Selects a file from which the identity (private key) for RSA or DSA
439           authentication is read. The default is $HOME/.ssh/identity for pro‐
440           tocol  version  1,  and $HOME/.ssh/id_rsa and $HOME/.ssh/id_dsa for
441           protocol version 2. Identity files can also be specified on a  per-
442           host basis in the configuration file. It is possible to have multi‐
443           ple -i options (and multiple identities specified in  configuration
444           files).
445
446
447       -l login_name
448
449           Specifies  the  user  to log in as on the remote machine. This also
450           can be specified on a per-host basis in the configuration file.
451
452
453       -L [bind_address:]port:host:hostport
454
455           Specifies that the specified port on the local (client) host is  to
456           be  forwarded  to  the  specified host and port on the remote side.
457           This works by allocating a socket to listen  to  the  port  on  the
458           local  side,  optionally bound to the specified bind_address. Then,
459           whenever a connection is made to this port, the connection is  for‐
460           warded  over  the  secure  channel and a connection is made to host
461           port hostport from the remote machine. Port forwardings can also be
462           specified in the configuration file. Only a user with enough privi‐
463           leges can forward privileged ports. IPv6 addresses can be specified
464           with an alternative syntax: [bind_address/]port/host/hostport or by
465           enclosing the address in square brackets.
466
467           By default, the local port is bound in accordance with the Gateway‐
468           Ports  setting.  However,  an  explicit bind_address can be used to
469           bind the connection to a  specific  address.  The  bind_address  of
470           localhost  indicates that the listening port be bound for local use
471           only, while an empty address or * indicates that the port should be
472           available from all interfaces.
473
474
475       -m mac_spec
476
477           Additionally,  for protocol version 2 a comma-separated list of MAC
478           (message authentication code) algorithms can be specified in  order
479           of preference. See the MACs keyword for more information.
480
481
482       -n
483
484           Redirects  stdin  from  /dev/null  (actually, prevents reading from
485           stdin). This must be used when ssh is run in the background. A com‐
486           mon  trick  is to use this to run X11 programs on a remote machine.
487           For example,
488
489             ssh -n shadows.cs.hut.fi emacs &
490
491
492           starts an emacs on shadows.cs.hut.fi, and  the  X11  connection  is
493           automatically  forwarded over an encrypted channel. The ssh program
494           is put in the background. This does not work if ssh  needs  to  ask
495           for a password or passphrase. See also the -f option.
496
497
498       -N
499
500           Does  not execute a remote command. This is useful if you just want
501           to forward ports (protocol version 2 only).
502
503
504       -o option
505
506           Can be used to give options in the format used in the configuration
507           file.  This  is useful for specifying options for which there is no
508           separate command-line flag. The option has the  same  format  as  a
509           line in the configuration file.
510
511
512       -p port
513
514           Specifies  the  port  to connect to on the remote host. This can be
515           specified on a per-host basis in the configuration file.
516
517
518       -P
519
520           Obsoleted option. SSHv1 connections from privileged ports  are  not
521           supported.
522
523
524       -q
525
526           Quiet  mode.  Causes all warning and diagnostic messages to be sup‐
527           pressed. Only fatal errors are displayed.
528
529
530       -R [bind_address:]port:host:hostport
531
532           Specifies that the specified port on the remote (server) host is to
533           be forwarded to the specified host and port on the local side. This
534           works by allocating a socket to listen to the port  on  the  remote
535           side. Then, whenever a connection is made to this port, the connec‐
536           tion is forwarded over the secure channel and a connection is  made
537           to  host port hostport from the local machine. Port forwardings can
538           also be specified in the configuration file. Privileged  ports  can
539           be  forwarded  only when logging in on the remote machine as a user
540           with enough privileges.
541
542           IPv6 addresses can be specified by enclosing the address in  square
543           braces       or       using       an       alternative      syntax:
544           [bind_address/]host/port/hostport.
545
546           By default, the listening socket on the  server  is  bound  to  the
547           loopback  interface  only.  This  can be overridden by specifying a
548           bind_address. An empty bind_address, or the  address  *,  indicates
549           that  the remote socket should listen on all interfaces. Specifying
550           a remote bind_address only succeeds if  the  server's  GatewayPorts
551           option is enabled. See sshd_config(4).
552
553
554       -s
555
556           Can be used to request invocation of a subsystem on the remote sys‐
557           tem. Subsystems are a feature of the SSH2 protocol which facilitate
558           the  use  of  SSH as a secure transport for other applications, for
559           example, sftp. The subsystem is specified as the remote command.
560
561
562       -t
563
564           Forces pseudo-tty allocation. This can be used to execute arbitrary
565           screen-based  programs  on a remote machine, which can be very use‐
566           ful, for example, when  implementing  menu  services.  Multiple  -t
567           options force allocation, even if ssh has no local tty.
568
569
570       -T
571
572           Disables pseudo-tty allocation (protocol version 2 only).
573
574
575       -v
576
577           Verbose  mode.  Causes  ssh  to  print debugging messages about its
578           progress. This is helpful in debugging connection,  authentication,
579           and  configuration  problems. Multiple -v options increase the ver‐
580           bosity. Maximum is 3.
581
582
583       -x
584
585           Disables X11 forwarding.
586
587
588       -X
589
590           Enables X11 forwarding. This can also be specified  on  a  per-host
591           basis in a configuration file.
592
593           X11 forwarding should be enabled with caution. Users with the abil‐
594           ity to bypass file permissions on the remote host (for the user's X
595           authorization  database)  can  access the local X11 display through
596           the forwarded connection. An attacker can then be able  to  perform
597           activities such as keystroke monitoring.
598
599           For  this reason, X11 forwarding might be subjected to X11 SECURITY
600           extension restrictions. Refer to the ForwardX11Trusted directive in
601           ssh_config(4) for more information.
602
603           If  X11  forwarding  is  enabled,  remote X11 clients is trusted by
604           default. This means that they have full access to the original  X11
605           display.
606
607

ENVIRONMENT VARIABLES

609       ssh normally sets the following environment variables:
610
611       DISPLAY
612
613           The  DISPLAY  variable  must  be  set for X11 display forwarding to
614           work.
615
616
617       SSH_ASKPASS
618
619           If ssh needs a passphrase, it reads the passphrase from the current
620           terminal if it was run from a terminal. If ssh does not have a ter‐
621           minal associated with it but DISPLAY and SSH_ASKPASS  are  set,  it
622           executes the program specified by SSH_ASKPASS and opens an X11 win‐
623           dow to read the passphrase. This is particularly useful when  call‐
624           ing  ssh  from  a  .Xsession or related script. On some machines it
625           might be necessary to redirect the input  from  /dev/null  to  make
626           this  work.  The  system  is  shipped with /usr/lib/ssh/ssh-askpass
627           which is the default value for SSH_ASKPASS
628
629
630       SSH_AUTH_SOCK
631
632           Indicates the path of a unix-domain socket used to communicate with
633           the agent.
634
635
636       SSH_LANGS
637
638           A comma-separated list of IETF language tags (see RFC3066) indicat‐
639           ing the languages that the user can read and write. Used for  nego‐
640           tiation of the locale on the server.
641
642
643       LANG, LC_ALL, LC_COLLATE, LC_CTYPE,
644       LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME
645
646           The values of these environment variables can be set in remote ses‐
647           sions according to the locale  settings  on  the  client  side  and
648           availability of support for those locales on the server side. Envi‐
649           ronment Variable Passing (see RFC 4254) is used  for  passing  them
650           over to the server side.
651
652
653
654       See the ENVIRONMENT VARIABLES section in the sshd(1M) man page for more
655       information on how locale setting can be further changed  depending  on
656       server side configuration.
657

EXIT STATUS

659       The status of the remote program is returned as the exit status of ssh.
660       255 is returned if an error occurred at anytime during the ssh  connec‐
661       tion, including the initial key exchange.
662

FILES

664       $HOME/.ssh/known_hosts    Records  host keys for all hosts the user has
665                                 logged    into    that     are     not     in
666                                 /etc/ssh/ssh_known_hosts. See sshd(1M).
667
668
669       $HOME/.ssh/identity       Contains  the  authentication identity of the
670       $HOME/.ssh/id_dsa         user. These files are  for  protocol  1  RSA,
671       $HOME/.ssh/id_ssa         protocol  2  DSA, and protocol 2 RSA, respec‐
672                                 tively. These files  contain  sensitive  data
673                                 and  should  be  readable by the user but not
674                                 accessible  by  others  (read/write/execute).
675                                 ssh  ignores  a  private  key  file  if it is
676                                 accessible by others. It is possible to spec‐
677                                 ify a passphrase when generating the key. The
678                                 passphrase is used to encrypt  the  sensitive
679                                 part of this file using 3DES.
680
681
682       /etc/ssh/sshrc            Commands  in  this  file  are executed by ssh
683                                 when the user logs in just before the  user's
684                                 shell or command is started. See sshd(1M) for
685                                 more information.
686
687
688       $HOME/.ssh/rc             Commands in this file  are  executed  by  ssh
689                                 when  the user logs in just before the user's
690                                 shell or command is started. See sshd(1M) for
691                                 more information.
692
693
694       $HOME/.ssh/environment    Contains  additional definitions for environ‐
695                                 ment variables. See ENVIRONMENT VARIABLES.
696
697

ATTRIBUTES

699       See attributes(5) for descriptions of the following attributes:
700
701
702
703
704       ┌─────────────────────────────┬─────────────────────────────┐
705       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
706       ├─────────────────────────────┼─────────────────────────────┤
707       │Availability                 │SUNWsshu                     │
708       ├─────────────────────────────┼─────────────────────────────┤
709       │Interface Stability          │See below.                   │
710       └─────────────────────────────┴─────────────────────────────┘
711
712
713       The command line syntax  is  Committed.  The  remote  locale  selection
714       through passing LC_* environment variables is Uncommitted.
715

SEE ALSO

717       rlogin(1),  rsh(1),  scp(1),  ssh-add(1),  ssh-agent(1), ssh-keygen(1),
718       ssh-http-proxy-connect(1),   ssh-socks5-proxy-connect(1),    telnet(1),
719       sshd(1M),       ssh_config(4),      sshd_config(4),      attributes(5),
720       gss_auth_rules(5), kerberos(5), privileges(5)
721
722
723       RFC 1928
724
725
726       RFC 4254
727
728
729
730SunOS 5.11                        20 May 2009                           ssh(1)
Impressum