Context Navigation

ssh.0 @ 18759

Visit:

Revision 18759, 31.7 KB checked in by zacheiss, 22 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r18758, which included commits to RCS files with non-trunk default branches.

Line
1	SSH(1) System General Commands Manual SSH(1)
2
3	NAME
4	ssh - OpenSSH SSH client (remote login program)
5
6	SYNOPSIS
7	ssh [-l login_name] hostname \| user@hostname [command]
8
9	ssh [-afgknqstvxACNTX1246] [-b bind_address] [-c cipher_spec]
10	[-e escape_char] [-i identity_file] [-l login_name] [-m mac_spec]
11	[-o option] [-p port] [-F configfile] [-L port:host:hostport] [-R
12	port:host:hostport] [-D port] hostname \| user@hostname [command]
13
14	DESCRIPTION
15	ssh (SSH client) is a program for logging into a remote machine and for
16	executing commands on a remote machine. It is intended to replace rlogin
17	and rsh, and provide secure encrypted communications between two
18	untrusted hosts over an insecure network. X11 connections and arbitrary
19	TCP/IP ports can also be forwarded over the secure channel.
20
21	ssh connects and logs into the specified hostname. The user must prove
22	his/her identity to the remote machine using one of several methods
23	depending on the protocol version used:
24
25	SSH protocol version 1
26
27	First, if the machine the user logs in from is listed in /etc/hosts.equiv
28	or /etc/shosts.equiv on the remote machine, and the user names are the
29	same on both sides, the user is immediately permitted to log in. Second,
30	if .rhosts or .shosts exists in the user's home directory on the remote
31	machine and contains a line containing the name of the client machine and
32	the name of the user on that machine, the user is permitted to log in.
33	This form of authentication alone is normally not allowed by the server
34	because it is not secure.
35
36	The second authentication method is the rhosts or hosts.equiv method comM--
37	bined with RSA-based host authentication. It means that if the login
38	would be permitted by $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, or
39	/etc/shosts.equiv, and if additionally the server can verify the client's
40	host key (see /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts in the
41	FILES section), only then login is permitted. This authentication method
42	closes security holes due to IP spoofing, DNS spoofing and routing spoofM--
43	ing. [Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts, and
44	the rlogin/rsh protocol in general, are inherently insecure and should be
45	disabled if security is desired.]
46
47	As a third authentication method, ssh supports RSA based authentication.
48	The scheme is based on public-key cryptography: there are cryptosystems
49	where encryption and decryption are done using separate keys, and it is
50	not possible to derive the decryption key from the encryption key. RSA
51	is one such system. The idea is that each user creates a public/private
52	key pair for authentication purposes. The server knows the public key,
53	and only the user knows the private key. The file
54	$HOME/.ssh/authorized_keys lists the public keys that are permitted for
55	logging in. When the user logs in, the ssh program tells the server
56	which key pair it would like to use for authentication. The server
57	checks if this key is permitted, and if so, sends the user (actually the
58	ssh program running on behalf of the user) a challenge, a random number,
59	encrypted by the user's public key. The challenge can only be decrypted
60	using the proper private key. The user's client then decrypts the chalM--
61	lenge using the private key, proving that he/she knows the private key
62	but without disclosing it to the server.
63
64	ssh implements the RSA authentication protocol automatically. The user
65	creates his/her RSA key pair by running ssh-keygen(1). This stores the
66	private key in $HOME/.ssh/identity and the public key in
67	$HOME/.ssh/identity.pub in the user's home directory. The user should
68	then copy the identity.pub to $HOME/.ssh/authorized_keys in his/her home
69	directory on the remote machine (the authorized_keys file corresponds to
70	the conventional $HOME/.rhosts file, and has one key per line, though the
71	lines can be very long). After this, the user can log in without giving
72	the password. RSA authentication is much more secure than rhosts authenM--
73	tication.
74
75	The most convenient way to use RSA authentication may be with an authenM--
76	tication agent. See ssh-agent(1) for more information.
77
78	If other authentication methods fail, ssh prompts the user for a passM--
79	word. The password is sent to the remote host for checking; however,
80	since all communications are encrypted, the password cannot be seen by
81	someone listening on the network.
82
83	SSH protocol version 2
84
85	When a user connects using protocol version 2 similar authentication
86	methods are available. Using the default values for
87	PreferredAuthentications, the client will try to authenticate first using
88	the hostbased method; if this method fails public key authentication is
89	attempted, and finally if this method fails keyboard-interactive and
90	password authentication are tried.
91
92	The public key method is similar to RSA authentication described in the
93	previous section and allows the RSA or DSA algorithm to be used: The
94	client uses his private key, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa, to
95	sign the session identifier and sends the result to the server. The
96	server checks whether the matching public key is listed in
97	$HOME/.ssh/authorized_keys and grants access if both the key is found and
98	the signature is correct. The session identifier is derived from a
99	shared Diffie-Hellman value and is only known to the client and the
100	server.
101
102	If public key authentication fails or is not available a password can be
103	sent encrypted to the remote host for proving the user's identity.
104
105	Additionally, ssh supports hostbased or challenge response authenticaM--
106	tion.
107
108	Protocol 2 provides additional mechanisms for confidentiality (the trafM--
109	fic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity
110	(hmac-md5, hmac-sha1). Note that protocol 1 lacks a strong mechanism for
111	ensuring the integrity of the connection.
112
113	Login session and remote execution
114
115	When the user's identity has been accepted by the server, the server
116	either executes the given command, or logs into the machine and gives the
117	user a normal shell on the remote machine. All communication with the
118	remote command or shell will be automatically encrypted.
119
120	If a pseudo-terminal has been allocated (normal login session), the user
121	may use the escape characters noted below.
122
123	If no pseudo tty has been allocated, the session is transparent and can
124	be used to reliably transfer binary data. On most systems, setting the
125	escape character to ``none'' will also make the session transparent even
126	if a tty is used.
127
128	The session terminates when the command or shell on the remote machine
129	exits and all X11 and TCP/IP connections have been closed. The exit staM--
130	tus of the remote program is returned as the exit status of ssh.
131
132	Escape Characters
133
134	When a pseudo terminal has been requested, ssh supports a number of funcM--
135	tions through the use of an escape character.
136
137	A single tilde character can be sent as ~~ or by following the tilde by a
138	character other than those described below. The escape character must
139	always follow a newline to be interpreted as special. The escape characM--
140	ter can be changed in configuration files using the EscapeChar configuraM--
141	tion directive or on the command line by the -e option.
142
143	The supported escapes (assuming the default `~') are:
144
145	~. Disconnect
146
147	~^Z Background ssh
148
149	~# List forwarded connections
150
151	~& Background ssh at logout when waiting for forwarded connection /
152	X11 sessions to terminate
153
154	~? Display a list of escape characters
155
156	~C Open command line (only useful for adding port forwardings using
157	the -L and -R options)
158
159	~R Request rekeying of the connection (only useful for SSH protocol
160	version 2 and if the peer supports it)
161
162	X11 and TCP forwarding
163
164	If the ForwardX11 variable is set to ``yes'' (or, see the description of
165	the -X and -x options described later) and the user is using X11 (the
166	DISPLAY environment variable is set), the connection to the X11 display
167	is automatically forwarded to the remote side in such a way that any X11
168	programs started from the shell (or command) will go through the
169	encrypted channel, and the connection to the real X server will be made
170	from the local machine. The user should not manually set DISPLAY. ForM--
171	warding of X11 connections can be configured on the command line or in
172	configuration files.
173
174	The DISPLAY value set by ssh will point to the server machine, but with a
175	display number greater than zero. This is normal, and happens because
176	ssh creates a ``proxy'' X server on the server machine for forwarding the
177	connections over the encrypted channel.
178
179	ssh will also automatically set up Xauthority data on the server machine.
180	For this purpose, it will generate a random authorization cookie, store
181	it in Xauthority on the server, and verify that any forwarded connections
182	carry this cookie and replace it by the real cookie when the connection
183	is opened. The real authentication cookie is never sent to the server
184	machine (and no cookies are sent in the plain).
185
186	If the ForwardAgent variable is set to ``yes'' (or, see the description
187	of the -A and -a options described later) and the user is using an
188	authentication agent, the connection to the agent is automatically forM--
189	warded to the remote side.
190
191	Forwarding of arbitrary TCP/IP connections over the secure channel can be
192	specified either on the command line or in a configuration file. One
193	possible application of TCP/IP forwarding is a secure connection to an
194	electronic purse; another is going through firewalls.
195
196	Server authentication
197
198	ssh automatically maintains and checks a database containing identificaM--
199	tions for all hosts it has ever been used with. Host keys are stored in
200	$HOME/.ssh/known_hosts in the user's home directory. Additionally, the
201	file /etc/ssh/ssh_known_hosts is automatically checked for known hosts.
202	Any new hosts are automatically added to the user's file. If a host's
203	identification ever changes, ssh warns about this and disables password
204	authentication to prevent a trojan horse from getting the user's passM--
205	word. Another purpose of this mechanism is to prevent man-in-the-middle
206	attacks which could otherwise be used to circumvent the encryption. The
207	StrictHostKeyChecking option can be used to prevent logins to machines
208	whose host key is not known or has changed.
209
210	The options are as follows:
211
212	-a Disables forwarding of the authentication agent connection.
213
214	-A Enables forwarding of the authentication agent connection. This
215	can also be specified on a per-host basis in a configuration
216	file.
217
218	Agent forwarding should be enabled with caution. Users with the
219	ability to bypass file permissions on the remote host (for the
220	agent's Unix-domain socket) can access the local agent through
221	the forwarded connection. An attacker cannot obtain key material
222	from the agent, however they can perform operations on the keys
223	that enable them to authenticate using the identities loaded into
224	the agent.
225
226	-b bind_address
227	Specify the interface to transmit from on machines with multiple
228	interfaces or aliased addresses.
229
230	-c blowfish\|3des\|des
231	Selects the cipher to use for encrypting the session. 3des is
232	used by default. It is believed to be secure. 3des (triple-des)
233	is an encrypt-decrypt-encrypt triple with three different keys.
234	blowfish is a fast block cipher, it appears very secure and is
235	much faster than 3des. des is only supported in the ssh client
236	for interoperability with legacy protocol 1 implementations that
237	do not support the 3des cipher. Its use is strongly discouraged
238	due to cryptographic weaknesses.
239
240	-c cipher_spec
241	Additionally, for protocol version 2 a comma-separated list of
242	ciphers can be specified in order of preference. See Ciphers for
243	more information.
244
245	-e ch\|^ch\|none
246	Sets the escape character for sessions with a pty (default: `~').
247	The escape character is only recognized at the beginning of a
248	line. The escape character followed by a dot (`.') closes the
249	connection, followed by control-Z suspends the connection, and
250	followed by itself sends the escape character once. Setting the
251	character to ``none'' disables any escapes and makes the session
252	fully transparent.
253
254	-f Requests ssh to go to background just before command execution.
255	This is useful if ssh is going to ask for passwords or
256	passphrases, but the user wants it in the background. This
257	implies -n. The recommended way to start X11 programs at a
258	remote site is with something like ssh -f host xterm.
259
260	-g Allows remote hosts to connect to local forwarded ports.
261
262	-i identity_file
263	Selects a file from which the identity (private key) for RSA or
264	DSA authentication is read. The default is $HOME/.ssh/identity
265	for protocol version 1, and $HOME/.ssh/id_rsa and
266	$HOME/.ssh/id_dsa for protocol version 2. Identity files may
267	also be specified on a per-host basis in the configuration file.
268	It is possible to have multiple -i options (and multiple identiM--
269	ties specified in configuration files).
270
271	-I smartcard_device
272	Specifies which smartcard device to use. The argument is the
273	device ssh should use to communicate with a smartcard used for
274	storing the user's private RSA key.
275
276	-k Disables forwarding of Kerberos tickets and AFS tokens. This may
277	also be specified on a per-host basis in the configuration file.
278
279	-l login_name
280	Specifies the user to log in as on the remote machine. This also
281	may be specified on a per-host basis in the configuration file.
282
283	-m mac_spec
284	Additionally, for protocol version 2 a comma-separated list of
285	MAC (message authentication code) algorithms can be specified in
286	order of preference. See the MACs keyword for more information.
287
288	-n Redirects stdin from /dev/null (actually, prevents reading from
289	stdin). This must be used when ssh is run in the background. A
290	common trick is to use this to run X11 programs on a remote
291	machine. For example, ssh -n shadows.cs.hut.fi emacs & will
292	start an emacs on shadows.cs.hut.fi, and the X11 connection will
293	be automatically forwarded over an encrypted channel. The ssh
294	program will be put in the background. (This does not work if
295	ssh needs to ask for a password or passphrase; see also the -f
296	option.)
297
298	-N Do not execute a remote command. This is useful for just forM--
299	warding ports (protocol version 2 only).
300
301	-o option
302	Can be used to give options in the format used in the configuraM--
303	tion file. This is useful for specifying options for which there
304	is no separate command-line flag.
305
306	-p port
307	Port to connect to on the remote host. This can be specified on
308	a per-host basis in the configuration file.
309
310	-q Quiet mode. Causes all warning and diagnostic messages to be
311	suppressed.
312
313	-s May be used to request invocation of a subsystem on the remote
314	system. Subsystems are a feature of the SSH2 protocol which
315	facilitate the use of SSH as a secure transport for other appliM--
316	cations (eg. sftp). The subsystem is specified as the remote comM--
317	mand.
318
319	-t Force pseudo-tty allocation. This can be used to execute arbiM--
320	trary screen-based programs on a remote machine, which can be
321	very useful, e.g., when implementing menu services. Multiple -t
322	options force tty allocation, even if ssh has no local tty.
323
324	-T Disable pseudo-tty allocation.
325
326	-v Verbose mode. Causes ssh to print debugging messages about its
327	progress. This is helpful in debugging connection, authenticaM--
328	tion, and configuration problems. Multiple -v options increases
329	the verbosity. Maximum is 3.
330
331	-x Disables X11 forwarding.
332
333	-X Enables X11 forwarding. This can also be specified on a per-host
334	basis in a configuration file.
335
336	X11 forwarding should be enabled with caution. Users with the
337	ability to bypass file permissions on the remote host (for the
338	user's X authorization database) can access the local X11 display
339	through the forwarded connection. An attacker may then be able
340	to perform activities such as keystroke monitoring.
341
342	-C Requests compression of all data (including stdin, stdout,
343	stderr, and data for forwarded X11 and TCP/IP connections). The
344	compression algorithm is the same used by gzip(1), and the
345	``level'' can be controlled by the CompressionLevel option for
346	protocol version 1. Compression is desirable on modem lines and
347	other slow connections, but will only slow down things on fast
348	networks. The default value can be set on a host-by-host basis
349	in the configuration files; see the Compression option.
350
351	-F configfile
352	Specifies an alternative per-user configuration file. If a conM--
353	figuration file is given on the command line, the system-wide
354	configuration file (/etc/ssh/ssh_config) will be ignored. The
355	default for the per-user configuration file is $HOME/.ssh/config.
356
357	-L port:host:hostport
358	Specifies that the given port on the local (client) host is to be
359	forwarded to the given host and port on the remote side. This
360	works by allocating a socket to listen to port on the local side,
361	and whenever a connection is made to this port, the connection is
362	forwarded over the secure channel, and a connection is made to
363	host port hostport from the remote machine. Port forwardings can
364	also be specified in the configuration file. Only root can forM--
365	ward privileged ports. IPv6 addresses can be specified with an
366	alternative syntax: port/host/hostport
367
368	-R port:host:hostport
369	Specifies that the given port on the remote (server) host is to
370	be forwarded to the given host and port on the local side. This
371	works by allocating a socket to listen to port on the remote
372	side, and whenever a connection is made to this port, the connecM--
373	tion is forwarded over the secure channel, and a connection is
374	made to host port hostport from the local machine. Port forwardM--
375	ings can also be specified in the configuration file. Privileged
376	ports can be forwarded only when logging in as root on the remote
377	machine. IPv6 addresses can be specified with an alternative
378	syntax: port/host/hostport
379
380	-D port
381	Specifies a local ``dynamic'' application-level port forwarding.
382	This works by allocating a socket to listen to port on the local
383	side, and whenever a connection is made to this port, the connecM--
384	tion is forwarded over the secure channel, and the application
385	protocol is then used to determine where to connect to from the
386	remote machine. Currently the SOCKS4 protocol is supported, and
387	ssh will act as a SOCKS4 server. Only root can forward priviM--
388	leged ports. Dynamic port forwardings can also be specified in
389	the configuration file.
390
391	-1 Forces ssh to try protocol version 1 only.
392
393	-2 Forces ssh to try protocol version 2 only.
394
395	-4 Forces ssh to use IPv4 addresses only.
396
397	-6 Forces ssh to use IPv6 addresses only.
398
399	CONFIGURATION FILES
400	ssh may additionally obtain configuration data from a per-user configuraM--
401	tion file and a system-wide configuration file. The file format and conM--
402	figuration options are described in ssh_config(5).
403
404	ENVIRONMENT
405	ssh will normally set the following environment variables:
406
407	DISPLAY
408	The DISPLAY variable indicates the location of the X11 server.
409	It is automatically set by ssh to point to a value of the form
410	``hostname:n'' where hostname indicates the host where the shell
411	runs, and n is an integer >= 1. ssh uses this special value to
412	forward X11 connections over the secure channel. The user should
413	normally not set DISPLAY explicitly, as that will render the X11
414	connection insecure (and will require the user to manually copy
415	any required authorization cookies).
416
417	HOME Set to the path of the user's home directory.
418
419	LOGNAME
420	Synonym for USER; set for compatibility with systems that use
421	this variable.
422
423	MAIL Set to the path of the user's mailbox.
424
425	PATH Set to the default PATH, as specified when compiling ssh.
426
427	SSH_ASKPASS
428	If ssh needs a passphrase, it will read the passphrase from the
429	current terminal if it was run from a terminal. If ssh does not
430	have a terminal associated with it but DISPLAY and SSH_ASKPASS
431	are set, it will execute the program specified by SSH_ASKPASS and
432	open an X11 window to read the passphrase. This is particularly
433	useful when calling ssh from a .Xsession or related script.
434	(Note that on some machines it may be necessary to redirect the
435	input from /dev/null to make this work.)
436
437	SSH_AUTH_SOCK
438	Identifies the path of a unix-domain socket used to communicate
439	with the agent.
440
441	SSH_CONNECTION
442	Identifies the client and server ends of the connection. The
443	variable contains four space-separated values: client ip-address,
444	client port number, server ip-address and server port number.
445
446	SSH_ORIGINAL_COMMAND
447	The variable contains the original command line if a forced comM--
448	mand is executed. It can be used to extract the original arguM--
449	ments.
450
451	SSH_TTY
452	This is set to the name of the tty (path to the device) associM--
453	ated with the current shell or command. If the current session
454	has no tty, this variable is not set.
455
456	TZ The timezone variable is set to indicate the present timezone if
457	it was set when the daemon was started (i.e., the daemon passes
458	the value on to new connections).
459
460	USER Set to the name of the user logging in.
461
462	Additionally, ssh reads $HOME/.ssh/environment, and adds lines of the
463	format ``VARNAME=value'' to the environment if the file exists and if
464	users are allowed to change their environment. See the
465	PermitUserEnvironment option in sshd_config(5).
466
467	FILES
468	$HOME/.ssh/known_hosts
469	Records host keys for all hosts the user has logged into that are
470	not in /etc/ssh/ssh_known_hosts. See sshd(8).
471
472	$HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa
473	Contains the authentication identity of the user. They are for
474	protocol 1 RSA, protocol 2 DSA, and protocol 2 RSA, respectively.
475	These files contain sensitive data and should be readable by the
476	user but not accessible by others (read/write/execute). Note
477	that ssh ignores a private key file if it is accessible by othM--
478	ers. It is possible to specify a passphrase when generating the
479	key; the passphrase will be used to encrypt the sensitive part of
480	this file using 3DES.
481
482	$HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub
483	Contains the public key for authentication (public part of the
484	identity file in human-readable form). The contents of the
485	$HOME/.ssh/identity.pub file should be added to
486	$HOME/.ssh/authorized_keys on all machines where the user wishes
487	to log in using protocol version 1 RSA authentication. The conM--
488	tents of the $HOME/.ssh/id_dsa.pub and $HOME/.ssh/id_rsa.pub file
489	should be added to $HOME/.ssh/authorized_keys on all machines
490	where the user wishes to log in using protocol version 2 DSA/RSA
491	authentication. These files are not sensitive and can (but need
492	not) be readable by anyone. These files are never used automatiM--
493	cally and are not necessary; they are only provided for the conM--
494	venience of the user.
495
496	$HOME/.ssh/config
497	This is the per-user configuration file. The file format and
498	configuration options are described in ssh_config(5).
499
500	$HOME/.ssh/authorized_keys
501	Lists the public keys (RSA/DSA) that can be used for logging in
502	as this user. The format of this file is described in the
503	sshd(8) manual page. In the simplest form the format is the same
504	as the .pub identity files. This file is not highly sensitive,
505	but the recommended permissions are read/write for the user, and
506	not accessible by others.
507
508	/etc/ssh/ssh_known_hosts
509	Systemwide list of known host keys. This file should be prepared
510	by the system administrator to contain the public host keys of
511	all machines in the organization. This file should be world-
512	readable. This file contains public keys, one per line, in the
513	following format (fields separated by spaces): system name, pubM--
514	lic key and optional comment field. When different names are
515	used for the same machine, all such names should be listed, sepaM--
516	rated by commas. The format is described on the sshd(8) manual
517	page.
518
519	The canonical system name (as returned by name servers) is used
520	by sshd(8) to verify the client host when logging in; other names
521	are needed because ssh does not convert the user-supplied name to
522	a canonical name before checking the key, because someone with
523	access to the name servers would then be able to fool host
524	authentication.
525
526	/etc/ssh/ssh_config
527	Systemwide configuration file. The file format and configuration
528	options are described in ssh_config(5).
529
530	/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,
531	/etc/ssh/ssh_host_rsa_key
532	These three files contain the private parts of the host keys and
533	are used for RhostsRSAAuthentication and HostbasedAuthentication.
534	If the protocol version 1 RhostsRSAAuthentication method is used,
535	ssh must be setuid root, since the host key is readable only by
536	root. For protocol version 2, ssh uses ssh-keysign(8) to access
537	the host keys for HostbasedAuthentication. This eliminates the
538	requirement that ssh be setuid root when that authentication
539	method is used. By default ssh is not setuid root.
540
541	$HOME/.rhosts
542	This file is used in .rhosts authentication to list the host/user
543	pairs that are permitted to log in. (Note that this file is also
544	used by rlogin and rsh, which makes using this file insecure.)
545	Each line of the file contains a host name (in the canonical form
546	returned by name servers), and then a user name on that host,
547	separated by a space. On some machines this file may need to be
548	world-readable if the user's home directory is on a NFS partiM--
549	tion, because sshd(8) reads it as root. Additionally, this file
550	must be owned by the user, and must not have write permissions
551	for anyone else. The recommended permission for most machines is
552	read/write for the user, and not accessible by others.
553
554	Note that by default sshd(8) will be installed so that it
555	requires successful RSA host authentication before permitting
556	.rhosts authentication. If the server machine does not have the
557	client's host key in /etc/ssh/ssh_known_hosts, it can be stored
558	in $HOME/.ssh/known_hosts. The easiest way to do this is to conM--
559	nect back to the client from the server machine using ssh; this
560	will automatically add the host key to $HOME/.ssh/known_hosts.
561
562	$HOME/.shosts
563	This file is used exactly the same way as .rhosts. The purpose
564	for having this file is to be able to use rhosts authentication
565	with ssh without permitting login with rlogin or rsh(1).
566
567	/etc/hosts.equiv
568	This file is used during .rhosts authentication. It contains
569	canonical hosts names, one per line (the full format is described
570	on the sshd(8) manual page). If the client host is found in this
571	file, login is automatically permitted provided client and server
572	user names are the same. Additionally, successful RSA host
573	authentication is normally required. This file should only be
574	writable by root.
575
576	/etc/shosts.equiv
577	This file is processed exactly as /etc/hosts.equiv. This file
578	may be useful to permit logins using ssh but not using
579	rsh/rlogin.
580
581	/etc/ssh/sshrc
582	Commands in this file are executed by ssh when the user logs in
583	just before the user's shell (or command) is started. See the
584	sshd(8) manual page for more information.
585
586	$HOME/.ssh/rc
587	Commands in this file are executed by ssh when the user logs in
588	just before the user's shell (or command) is started. See the
589	sshd(8) manual page for more information.
590
591	$HOME/.ssh/environment
592	Contains additional definitions for environment variables, see
593	section ENVIRONMENT above.
594
595	DIAGNOSTICS
596	ssh exits with the exit status of the remote command or with 255 if an
597	error occurred.
598
599	AUTHORS
600	OpenSSH is a derivative of the original and free ssh 1.2.12 release by
601	Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
602	de Raadt and Dug Song removed many bugs, re-added newer features and creM--
603	ated OpenSSH. Markus Friedl contributed the support for SSH protocol
604	versions 1.5 and 2.0.
605
606	SEE ALSO
607	rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
608	telnet(1), ssh_config(5), ssh-keysign(8), sshd(8)
609
610	T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH
611	Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January
612	2002, work in progress material.
613
614	BSD September 25, 1999 BSD

Note: See TracBrowser for help on using the repository browser.

Download in other formats:

Original Format