dbclient - lightweight SSH2 client
dbclient [-Tt] [-p port] [-i id] [-L l:h:r] [-R l:h:r] [-l user] host
dbclient [ args ] [user1]@host1[/port1],[user2]@host2[/port2],...
dbclient is a SSH 2 client designed to be small enough to be used in
small memory environments, while still being functional and secure
enough for general use.
If compiled with zlib support and if the server supports it, dbclient
will always use compression.
Remote port. Connect to port port on the remote host. Default
Identity file. Read the identity from file idfile (multiple
Local port forwarding. Forward the port listenport on the local
host through the SSH connection to port port on the host host.
Remote port forwarding. Forward the port listenport on the
remote host through the SSH connection to port port on the host
Username. Login as user on the remote host.
-t Allocate a pty.
-T Don’t allocate a pty.
-N Don’t request a remote shell or run any commands. Any command
arguments are ignored.
-f Fork into the background after authentication. A command
argument (or -N) is required. This is useful when using
-g Allow non-local hosts to connect to forwarded ports. Applies to
-L and -R forwarded ports, though remote connections to -R
forwarded ports may be limited by the ssh server.
-y Always accept hostkeys if they are unknown. If a hostkey
mismatch occurs the connection will abort as normal.
Specify the per-channel receive window buffer size. Increasing
this may improve network performance at the expense of memory
use. Use -h to see the default buffer size.
Ensure that traffic is transmitted at a certain interval in
seconds. This is useful for working around firewalls or routers
that drop connections after a certain period of inactivity. The
trade-off is that a session may be closed if there is a
temporary lapse of network connectivity. A setting if 0 disables
Disconnect the session if no traffic is transmitted or received
for idle_timeout seconds.
Use the standard input/output of the program proxy_command
rather than using a normal TCP connection. A hostname should be
still be provided, as this is used for comparing saved hostkeys.
"Netcat-alike" mode, where Dropbear will connect to the given
host, then create a forwarded connection to endhost. This will
then be presented as dbclient’s standard input/output.
Dropbear will also allow multiple "hops" to be specified,
separated by commas. In this case a connection will be made to
the first host, then a TCP forwarded connection will be made
through that to the second host, and so on. Hosts other than the
final destination will not see anything other than the encrypted
SSH stream. A port for a host can be specified with a slash (eg
matt@martello/44 ). This syntax can also be used with scp or
rsync (specifying dbclient as the ssh/rsh command). A file can
be "bounced" through multiple SSH hops, eg
scp -S dbclient matt@martello,root@wrt,canyons:/tmp/dump .
Note that hostnames are resolved by the prior hop (so "canyons"
would be resolved by the host "wrt") in the example above, the
same way as other -L TCP forwarded hosts are. Host keys are
checked locally based on the given hostname.
A password to use for remote authentication can be specified in
the environment variable DROPBEAR_PASSWORD. Care should be taken
that the password is not exposed to other users on a multi-user
system, or stored in accessible files.
dbclient can use an external program to request a password from
a user. SSH_ASKPASS should be set to the path of a program that
will return a password on standard output. This program will
only be used if either DISPLAY is set and standard input is not
a TTY, or the environment variable SSH_ASKPASS_ALWAYS is set.
Matt Johnston (email@example.com).
Mihnea Stoenescu wrote initial Dropbear client support
Gerrit Pape (firstname.lastname@example.org) wrote this manual page.