|author||Mike Frysinger <email@example.com>||2018-10-27 23:31:53 -0400|
|committer||Andreas Schneider <firstname.lastname@example.org>||2018-10-28 12:15:02 +0100|
doc: fix up various typos and trailing whitespace
Signed-off-by: Mike Frysinger <email@example.com> Reviewed-by: Andreas Schneider <firstname.lastname@example.org>
Diffstat (limited to 'doc')
8 files changed, 39 insertions, 39 deletions
diff --git a/doc/authentication.dox b/doc/authentication.dox
index 7a0023e3..ec6f1936 100644
@@ -127,7 +127,7 @@ The keyboard-interactive method is, as its name tells, interactive. The
server will issue one or more challenges that the user has to answer,
until the server takes an authentication decision.
-ssh_userauth_kbdint() is the the main keyboard-interactive function.
+ssh_userauth_kbdint() is the the main keyboard-interactive function.
It will return SSH_AUTH_SUCCESS,SSH_AUTH_DENIED, SSH_AUTH_PARTIAL,
SSH_AUTH_ERROR, or SSH_AUTH_INFO, depending on the result of the request.
@@ -154,9 +154,9 @@ Here are a few remarks:
- Even the first call can return SSH_AUTH_DENIED or SSH_AUTH_SUCCESS.
- The server can send an empty question set (this is the default behavior
on my system) after you have sent the answers to the first questions.
- You must still parse the answer, it might contain some
+ You must still parse the answer, it might contain some
message from the server saying hello or such things. Just call
- ssh_userauth_kbdint() until needed.
+ ssh_userauth_kbdint() until needed.
- The meaning of "name", "prompt", "instruction" may be a little
confusing. An explanation is given in the RFC section that follows.
@@ -187,7 +187,7 @@ keyboard-interactive authentication, coming from the RFC itself (rfc4256):
the name and prompts. If the server presents names or prompts longer than 30
characters, the client MAY truncate these fields to the length it can
display. If the client does truncate any fields, there MUST be an obvious
- indication that such truncation has occured.
+ indication that such truncation has occurred.
The instruction field SHOULD NOT be truncated. Clients SHOULD use control
character filtering as discussed in [SSH-ARCH] to avoid attacks by
diff --git a/doc/forwarding.dox b/doc/forwarding.dox
index be4ab94e..bb93c7b1 100644
@@ -4,7 +4,7 @@
Port forwarding comes in SSH protocol in two different flavours:
direct or reverse port forwarding. Direct port forwarding is also
-named local port forwardind, and reverse port forwarding is also called
+named local port forwarding, and reverse port forwarding is also called
remote port forwarding. SSH also allows X11 tunnels.
@@ -23,15 +23,15 @@ Mail client application Google Mail
5555 (arbitrary) |
| 143 (IMAP2)
- SSH client =====> SSH server
+ SSH client =====> SSH server
---P-->: port connexion through port P
+--P-->: port connections through port P
=====>: SSH tunnel
A mail client connects to port 5555 of a client. An encrypted tunnel is
established to the server. The server connects to port 143 of Google Mail (the
-end point). Now the local mail client can retreive mail.
+end point). Now the local mail client can retrieve mail.
@subsection forwarding_reverse Reverse port forwarding
@@ -51,7 +51,7 @@ Example of use of reverse port forwarding:
SSH client <===== SSH server
---P-->: port connexion through port P
+--P-->: port connections through port P
=====>: SSH tunnel
In this example, the SSH client establishes the tunnel,
@@ -148,9 +148,9 @@ To do reverse port forwarding, call ssh_channel_listen_forward(),
When you call ssh_channel_listen_forward(), you can let the remote server
-chose the non-priviledged port it should listen to. Otherwise, you can chose
-your own priviledged or non-priviledged port. Beware that you should have
-administrative priviledges on the remote server to open a priviledged port
+chose the non-privileged port it should listen to. Otherwise, you can chose
+your own privileged or non-privileged port. Beware that you should have
+administrative privileges on the remote server to open a privileged port
(port number < 1024).
Below is an example of a very rough web server waiting for connections on port
diff --git a/doc/guided_tour.dox b/doc/guided_tour.dox
index c74bfa87..2f1a9b8e 100644
@@ -31,20 +31,20 @@ A SSH session goes through the following steps:
- Invoke your own subsystem. This is outside the scope of this document,
but can be done.
- - When everything is finished, just close the channels, and then the connection.
+ - When everything is finished, just close the channels, and then the connection.
The sftp and scp subsystems use channels, but libssh hides them to
the programmer. If you want to use those subsystems, instead of a channel,
you'll usually open a "sftp session" or a "scp session".
@subsection setup Creating the session and setting options
The most important object in a SSH connection is the SSH session. In order
to allocate a new SSH session, you use ssh_new(). Don't forget to
-always verify that the allocation successed.
+always verify that the allocation succeeded.
@@ -69,12 +69,12 @@ The ssh_options_set() function sets the options of the session. The most importa
The complete list of options can be found in the documentation of ssh_options_set().
The only mandatory option is SSH_OPTIONS_HOST. If you don't use SSH_OPTIONS_USER,
-the local username of your account will be used.
+the local username of your account will be used.
Here is a small example of how to use it:
@@ -122,7 +122,7 @@ Here's an example:
@@ -285,9 +285,9 @@ int verify_knownhost(ssh_session session)
The authentication process is the way a service provider can identify a
user and verify his/her identity. The authorization process is about enabling
-the authenticated user the access to ressources. In SSH, the two concepts
+the authenticated user the access to resources. In SSH, the two concepts
are linked. After authentication, the server can grant the user access to
-several ressources such as port forwarding, shell, sftp subsystem, and so on.
+several resources such as port forwarding, shell, sftp subsystem, and so on.
libssh supports several methods of authentication:
- "none" method. This method allows to get the available authentications
@@ -313,7 +313,7 @@ The example below shows an authentication with password:
@@ -338,7 +338,7 @@ int main()
// Verify the server's identity
- // For the source code of verify_knowhost(), check previous example
+ // For the source code of verify_knownhost(), check previous example
if (verify_knownhost(my_ssh_session) < 0)
@@ -415,7 +415,7 @@ int show_remote_processes(ssh_session session)
nbytes = ssh_channel_read(channel, buffer, sizeof(buffer), 0);
if (nbytes < 0)
@@ -456,7 +456,7 @@ might be recoverable. SSH_FATAL means the connection has an important
problem and isn't probably recoverable.
Most of time, the error returned are SSH_FATAL, but some functions
-(generaly the ssh_request_xxx ones) may fail because of server denying request.
+(generally the ssh_request_xxx ones) may fail because of server denying request.
In these cases, SSH_REQUEST_DENIED is returned.
For thread safety, errors are bound to ssh_session objects.
diff --git a/doc/introduction.dox b/doc/introduction.dox
index cd786497..f2f3d3dd 100644
@@ -12,13 +12,13 @@ mean that you should not try to know about and understand these details.
libssh is a Free Software / Open Source project. The libssh library
is distributed under LGPL license. The libssh project has nothing to do with
-"libssh2", which is a completly different and independant project.
+"libssh2", which is a completely different and independent project.
libssh can run on top of either libgcrypt or libcrypto,
two general-purpose cryptographic libraries.
This tutorial concentrates for its main part on the "client" side of libssh.
-To learn how to accept incoming SSH connexions (how to write a SSH server),
+To learn how to accept incoming SSH connections (how to write a SSH server),
you'll have to jump to the end of this document.
This tutorial describes libssh version 0.5.0. This version is a little different
diff --git a/doc/scp.dox b/doc/scp.dox
index 1e7db780..618857ef 100644
@@ -2,7 +2,7 @@
@page libssh_tutor_scp Chapter 6: The SCP subsystem
@section scp_subsystem The SCP subsystem
-The SCP subsystem has far less functionnality than the SFTP subsystem.
+The SCP subsystem has far less functionality than the SFTP subsystem.
However, if you only need to copy files from and to the remote system,
it does its job.
@@ -158,7 +158,7 @@ Let's say you want to copy the following tree of files to the remote site:
+-- B --+
| +-- file2
--- A --+
+-- A --+
| +-- file3
+-- C --+
@@ -210,7 +210,7 @@ int scp_receive(ssh_session session, ssh_scp scp)
size = ssh_scp_request_get_size(scp);
filename = strdup(ssh_scp_request_get_filename(scp));
mode = ssh_scp_request_get_permissions(scp);
- printf("Receiving file %s, size %d, permisssions 0%o\n",
+ printf("Receiving file %s, size %d, permissions 0%o\n",
filename, size, mode);
diff --git a/doc/sftp.dox b/doc/sftp.dox
index 110976e0..78317f59 100644
@@ -100,7 +100,7 @@ Possible errors are:
@subsection sftp_mkdir Creating a directory
-The function sftp_mkdir() tahes the "SFTP session" we juste created as
+The function sftp_mkdir() takes the "SFTP session" we just created as
its first argument. It also needs the name of the file to create, and the
desired permissions. The permissions are the same as for the usual mkdir()
function. To get a comprehensive list of the available permissions, use the
@@ -358,19 +358,19 @@ int sftp_read_async(ssh_session session, sftp_session sftp)
@subsection sftp_ls Listing the contents of a directory
The functions sftp_opendir(), sftp_readdir(), sftp_dir_eof(),
-and sftp_closedir() enable to list the contents of a directory.
+and sftp_closedir() enable to list the contents of a directory.
They use a new handle_type, "sftp_dir", which gives access to the
directory being read.
In addition, sftp_readdir() returns a "sftp_attributes" which is a pointer
-to a structure with informations about a directory entry:
+to a structure with information about a directory entry:
- name: the name of the file or directory
- size: its size in bytes
sftp_readdir() might return NULL under two conditions:
- when the end of the directory has been met
- - when an error occured
+ - when an error occurred
To tell the difference, call sftp_dir_eof().
diff --git a/doc/shell.dox b/doc/shell.dox
index 35fdfc82..0693bbcc 100644
@@ -209,7 +209,7 @@ int interactive_shell_session(ssh_channel channel)
Of course, this is a poor terminal emulator, since the echo from the keys
pressed should not be done locally, but should be done by the remote side.
-Also, user's input should not be sent once "Enter" key is pressed, but
+Also, user's input should not be sent once "Enter" key is pressed, but
immediately after each key is pressed. This can be accomplished
by setting the local terminal to "raw" mode with the cfmakeraw(3) function.
cfmakeraw() is a standard function under Linux, on other systems you can
@@ -245,13 +245,13 @@ provide a more elegant way to wait for data coming from many sources.
The functions ssh_select() and ssh_channel_select() remind of the standard
UNIX select(2) function. The idea is to wait for "something" to happen:
-incoming data to be read, outcoming data to block, or an exception to
+incoming data to be read, outgoing data to block, or an exception to
occur. Both these functions do a "passive wait", i.e. you can safely use
them repeatedly in a loop, it will not consume exaggerate processor time
and make your computer unresponsive. It is quite common to use these
functions in your application's main loop.
-The difference between ssh_select() and ssh_channel_select() is that
+The difference between ssh_select() and ssh_channel_select() is that
ssh_channel_select() is simpler, but allows you only to watch SSH channels.
ssh_select() is more complete and enables watching regular file descriptors
as well, in the same function call.
diff --git a/doc/threading.dox b/doc/threading.dox
index bb6ab898..87d096b7 100644
@@ -11,10 +11,10 @@ libssh may be used in multithreaded applications, but under several conditions :
- If libssh is statically linked, threading must be initialized by calling
ssh_init() before using any of libssh provided functions. This initialization
must be done outside of any threading context. Don't forget to call
- ssh_finalize() to avoid memory leak
+ ssh_finalize() to avoid memory leak
- At all times, you may use different sessions inside threads, make parallel
connections, read/write on different sessions and so on. You *cannot* use a
- single session (or channels for a single session) in several threads at the same
+ single session (or channels for a single session) in several threads at the same
time. This will most likely lead to internal state corruption. This limitation is
being worked out and will maybe disappear later.