What is Slogin command?

On Unix-like operating systems, the slogin command is also referred to as ssh client, which is utilized to connect to a remote shell securely.

Description:

The SSH client is a program for connecting to and running commands on remote computers. It's meant to take the place of rlogin and rsh and offer secure encrypted communication between two untrusted hosts across an unsafe network. Additionally, the secure channel can be used to forward arbitrary TCP ports and X11 sessions.

The hostname supplied is connected to and logged into using ssh (with an optional user name). Depending on the protocol version, the user must utilize one of a few techniques to demonstrate his or her identity to the remote system.

Instead of using a login shell, the command is executed on the remote host if it is supplied.

Syntax:

ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]

[-D [bind_address:]port] [-e escape_char] [-F configfile]

[-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport]

[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]

[-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]

[-w local_tun[:remote_tun]] [user@]hostname [command]

There are several options in the syntax. These options can be described as follows:

• -1:
  It forces ssh only to attempt protocol version 1.
• -2:
  It forces ssh only to attempt protocol version 2.
• -4:
  It forces ssh to use only IPv4 addresses by default.
• -6:
  It forces ssh to use only IPv6 addresses by default.
• -A:
  It enables the connection of the authentication agent to be forwarded. In a configuration file, it can also be defined for each host separately.
  Agent forwarding needs to be turned on with care. Users having the capacity to go around file permissions on the distant host (for the agent's Unix-domain socket) can connect to the local agent via the forwarded connection. Attackers are unable to take key material from the agent, but they are able to manipulate the keys in such a way that they can use the identities that have been loaded into the agent for authentication.
• -a:
  It prevents the connection of the authentication agent from being sent.
• -b bind_address:
  As the connection's source address, use the local machine's bind_address. It is very useful only on systems that have multiple addresses.
• -C:
  It requests the compression of all data, including data from forwarded X11 and TCP/IP connections, as well as stdin, stdout, and stderr. The compression level option for protocol version 1 allows the "level" to be adjusted, and the compression technique is the same as that used by gzip. Compression is useful on modem lines and other sluggish connections, but it only slows down activity on fast networks. In the configuration files, the default value may be changed host-by-host.
• -c cipher_spec:
  It chooses the cipher to utilize to encrypt the session. Des, 3des, and blowfish are the supported values.
  By default, it utilizes the 3des. It is a reasonably secure cipher as of the time of authoring. Three distinct keys are used in the triple-DES algorithm known as 3des. A quick block cipher known as blowfish is substantially faster than 3des and seems to be quite secure. Only the des cipher is supported by the ssh client to be compatible with older Protocol 1 implementation that do not support the 3des cipher. As a result of its cryptographic flaws, use is severely prohibited.
• -D [bind_address:]port:
  It gives instructions for local "dynamic" application-level port forwarding. If desired, a socket is allocated and bound to the supplied bind_address on the local side. Every time a connection is made to this port, the connection is routed through a secure channel, and the application protocol is then utilized to decide which computer the connection should be made from. Currently, ssh will function as a SOCKS server and supports the SOCKS4 and SOCKS5 protocols. Privileged ports can only be forwarded by root. The configuration file also allows for the specification of dynamic port forwardings.
  You can specify IPv6 addresses by enclosing them in square brackets. Privileged ports can only be forwarded by the superuser (root). The local port is bound according to the GatewayPorts configuration by default. However, an explicit bind_address may be utilized to tie the connection to a specific address. An empty address or a '*' in the bind_address field means that the port should be accessible from all interfaces, while the value "localhost" implies that the port should be bound for local usage only.
• -e escape_char:
  It sets the escape character for pty sessions (default "~"). The escape character is recognized only at the beginning of a line. Close the connection by sending the escape character followed by a dot ('.'), suspend the connection by sending the escape character followed by control-Z, and transmit the escape character only once by sending the escape character alone. The session is completely transparent, and all escapes are disabled when the character is set to "none".
• -F config file:
  It is defined as a different per-user configuration file. If a configuration file is specified on the command line, the system configuration file (/etc/ssh/ssh_config) will not be used. The per-user configuration file's default location is $HOME/.ssh/config.
• -f:
  Before executing a command, asks ssh to enter the background. It can be helpful if the user wants ssh to ask for passwords or passphrases in the background but doesn't want it to actually ask. It means -n. The ssh -f host Xterm command is the suggested method for starting X11 programs at a remote location.
• -g:
  It enables connections from distant hosts to locally forwarded ports.
• -I smartcard_device:
  It defines the smartcard device to be used. The concept is that ssh should connect with a smartcard that stores the user's private RSA key.
• -i identity_file:
  It chooses a file to read the private key identity (identity) for public key authentication. The configuration file may also include per-host information about identity files. Multiple -i options (and different identities defined in configuration files) are possible. Additionally, ssh makes an attempt to load certificate data from the file named after the extension "-cert.pub" added to identity file names.
• -K:
  It enables the forwarding (delegation) of GSSAPI credentials to the server and GSSAPI-based authentication.
• -k :
  It prevents GSSAPI credentials from being forwarded (delegated) to the server.
• -L [bind_address:] port:host:hostport :
  It specifies that the host and port on the remote side should be routed from the local (client) host using the specified port. A socket is allocated for listening to the port locally, with the possibility of being bound to the provided bind_address. Every time a connection is made to this port, the connection is routed via the secure channel, and a connection is established from the remote computer to the hostport. In the configuration file, port forwardings can also be configured. By surrounding the address in square brackets, IPv6 addresses can be supplied. The only user with this privilege is the superuser. The local port is bound by default in accordance with the GatewayPorts configuration. You can use an explicit bind_address to tie the connection to a particular address. The value "localhost" indicates that the listening port should be bound for local usage only, while an empty address or a '*' suggests that the port should be accessible from all interfaces.
• -l login_name:
  It defines the user to log in on the remote computer. It also can be defined on a per-host basis in the configuration file.
• -M:
  It is utilized to place the ssh client into the "master" mode for connection sharing. Multiple -M options force ssh into "master" mode, requiring confirmation before accepting secondary connections.
• -m mac_spec:
  The MAC (message authentication code) algorithms for protocol version 2 can be specified in a comma-separated list in the order of preference.
• -N:
  It never carries out a remote command. It is helpful just for protocol version 2 port forwarding.
• -n:
  It redirects stdin to /dev/null (in reality, it prohibits reading from stdin). It should be utilized when ssh is being used in the background. It is a typical approach for running X11 applications on a distant system. For instance, if you start an emacs program on shadows.cs.hut.fi using the command ssh -n shadows.cs.hut.fi emacs &, the X11 connection will be sent through a secure channel. A background process for ssh will be created. It does not function when ssh needs to request a password or passphrase.
• -O ctl_cmd:
  It controls a master process for active connection multiplexing. The ctl_cmd parameter is processed and given to the master process when the -O option is supplied. The following are acceptable commands: "check" command is used to see if the master process is active; "forward" is used to request forwardings without executing instructions; "cancel" is used to cease forwardings; "exit" is used to ask the master to leave; and "stop" is used to ask the master to stop accepting new multiplexing requests.
• -o option:
  When there is no specific command-line flag for an option, it is helpful to specify it.
• -p port:
  Port is used to connect to the distant host. It may be defined on a per-host basis in the configuration file.
• -q:
  It is used to quite mode. Suppresses any and all warning and diagnostic signals. There are no more errors displayed. Even fatal mistakes are silenced if a second -q is provided.
• -R [bind_address:] port:host:hostport:
  It declares that the remote host's specified port should be forwarded to the local host's specified host and port. When a connection is made to the port on the remote side, the connection is passed via the secure channel, and a connection is made to the host port hostport from the local system. To make this work, a socket is designated for listening to the port on the remote side.
  In the configuration file, port forwardings can also be configured. Only when logged in as root on the remote workstation, can privileged ports be routed. IPv6 addresses can be supplied by surrounding the address in square brackets.
  The listening socket on the server will always be restricted to the loopback interface by default. It can be overridden by providing a bind_address. The address '*' or an empty bind_address designates the remote socket needs to be set to listen across all interfaces. Only when the server's GatewayPorts option is enabled, as described in sshd_config, can specifying a remote bind_address work.
  The listen port will be dynamically created on the server and reported to the client at run time if the port parameter is set to '0'. The allocated port will be printed to standard output when used in conjunction with -O forward.
• -S ctl_path:
  It defines the location of a control socket for connection sharing or the string "none" to turn off connection sharing.
• -s:
  It can be used to ask the remote system to invoke a subsystem. A feature of the SSH2 protocol called subsystems makes it easier to utilize SSH as a secure transport for other programs, such as sftp. As the remote command, the subsystem is mentioned.
• -T:
  It is unable to allocate pseudo-ttys.
• -t:
  It forced to allocate the Pseudo-tty. It has the ability to run any screen-based program on a different computer, which can be quite helpful for establishing menu services. Even when ssh lacks a local tty, several -t options compel tty allocation.
• -V:
  It shows the version number and then leave.
• -v:
  It defines the Verbose mode. As a result, debugging messages regarding its progress are printed by ssh. Debugging connection, authentication, and configuration issues can be aided by this function. The verbosity increases with additional -v parameters. The most is 3.
• -W host:port:
  It requests for the secure channel to be used to forward the client's standard input and output to the host on a port. It implies ExitOnForwardFailure, -N, -T, and ClearAllForwardings. It is only compatible with Protocol version 2.
• -w local_tun[:remote_tun]:
  It requests for tunnel device forwarding using the given tun devices between the client (local_tun) and server (remote_tun).
  Devices can be supplied by numerical ID or the keyword "any", which uses the following tunnel device that becomes accessible. If remote_tun is not supplied, the value "any" is used by default. Additionally, take a look at the ssh_config directives for Tunnel and TunnelDevice. If the Tunnel directive is not specified, the "point-to-point" tunnel mode is used by default.
• -X:
  It allows for X11 forwarding. It can also be provided in a configuration file on a per-host basis.
  X11 forwarding needs to be turned on with care. Users can access the local X11 display via the forwarded connection if they have the capacity to go around file permissions on the remote host (for the user's X authorization database). After that, an attacker might be able to carry out actions like keystroke monitoring.
  Because of this, X11 forwarding is subject to X11 SECURITY extension restrictions by default.
• -x:
  X11 forwarding is turned off.
• -Y:
  Trusted X11 forwarding is made possible. Trusted X11 forwardings are exempt from the controls of the X11 SECURITY extension.
• -y:
  Use the syslog system module to send log information. This data is often sent to stderr.

Authentication:

The OpenSSH SSH client provides support for SSH protocols 1 and 2. ssh_config's Protocol option, together with the -1 and -2 options (see above), allows you to override the default setting of using just protocol 2, which is to use protocol 2. The protocol 2 is the default protocol, which offers additional mechanisms for confidentiality (the traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and integrity (hmac-md5, hmac-sha1, hmac-sha2-256, hmac-sha2-512, umac-64, and hmac-ripemd160). Both protocols support similar authentication methods. Protocol 1 lacks a reliable technique to ensure the connection's integrity.

The techniques that can be used for authentication are:

• GSSAPI-based
• host-based
• public key
• challenge-response
• Password

Although protocol 2 provides a configuration option called PreferredAuthentications that allows it to vary the default sequence, authentication methods are tested in the order mentioned above.

host-based:

If the user login /etc/hosts.equiv on the system or /etc/ssh/shosts.equiv on the remote system, if both sides' user names match, the user is taken into account for login.

The server must be able to validate the client's host key for a login to be authorized. This authentication procedure resolves security gaps brought on by DNS, IP, and route spoofing.

public key :

The technique is based on public-key cryptography and employs cryptosystems in which encryption and decryption are carried out using different keys, making it impossible to infer the decryption key from the encryption key. Each user is supposed to generate a public/private key pair for authentication. Only the user is aware of the private key; the server is only aware of the public key. Using one of the DSA, ECDSA, or RSA algorithms, ssh automatically implements the public key authentication protocol. While protocol 2 is allowed to use any key, protocol 1 is limited to utilizing only RSA keys.

The public keys that are authorized for logging in are listed in the file /.ssh/authorized_keys. When a user logs in, the ssh program instructs the server to use a specific key pair and verifies that the matching public key is valid before using it.

challenge-response:

The server sends a random "challenge" string to receive a response. In contrast to Protocol 1, which is limited to just one challenge and one response, procedure 2 permits many challenges and responses. A few non-OpenBSD systems that use challenge-response authentication are PAM and BSD Authentication (see login.conf).

Password:

The ssh asks the user for a password as a last resort in the event that all other authentication techniques fail. Although the password is forwarded to the distant host for verification, it cannot be observed by someone eavesdropping on the network because all communications are encrypted.

TCP Forwarding:

Either on the command line or in a configuration file, it is possible to specify the forwarding of arbitrary TCP connections through the secure channel. A secure connection to a mail server is one potential use for TCP forwarding, as is passing past firewalls.

X11 Forwarding:

If the ForwardX11 parameter is set to "yes" (or see the explanations of the -X, -x, and -Y choices above) and the user uses X11 (the DISPLAY the environment variable is set), the connection to the X11 display is immediately forwarded to the other side in such a way that any X11 programs started from a shell (or command) go through the protected channel. The local machine will establish the connection to the real X server. The user shouldn't change DISPLAY by hand. On the command line or in configuration files, forwarding of X11 connections can be set up.

When using an authentication agent, the connection to the agent is automatically transmitted to the remote side if the ForwardAgent variable is set to "yes" and the user is using one.