1ssh(1) User Commands ssh(1)
2
3
4
6 ssh - secure shell client (remote login program)
7
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
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
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
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
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
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
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
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)