Password less authentication may required in various setup and we need to configure password less authentication for root user in cluster setup in order to install cluster software on both the machine simultaneously. Here we will see how to configure password less authentication using ssh on Solaris nodes.
How to to run sudo command without a password: Backup your /etc/sudoers file by typing the following command: sudo cp /etc/sudoers /root/sudoers.bak. Edit the /etc/sudoers file by typing the visudo command: sudo visudo. Append/edit the line as follows in the /etc/sudoers file for user named ‘vivek’ to run ‘/bin/kill’ and ‘systemctl’ commands. The post details out steps to configure passwordless ssh using RSA Public Key Authentication, in other words: passwordless login using public Key. This procedure is used to reduce the number of login prompts needed to do secure remote login with Sun Secure Shell (SSH) this including also SCP ( Secure Copy) and SFTP ( Secure File Transfer).
Login to node1.
Create a new ssh keygen .Here i have used RSA keygen. If you want you can use DSA instead of RSA.
Go to the directory where the keys are stored. It will be stored in root’s home directory by default.
Login to node2 and perform the same what we have did for node1.
Now i am copying the rsa key to node2 as authorized_keys where you want to login without password. By doing this , i can login from node1 to node2 without password.
In node2,i am copying the rsa key to node1 as authorized_keys.By doing this , i can login from node2 to node1 without password.
Testing the access from node1
Testing the access from node2
Thank you for reading this article.Please leave a comment if you have any doubt ,i will get back to you as soon as possible.
Solaris Secure Shell enables a user to securely access a remote host over an unsecured network. The shell provides commands for remote login and remote file transfer. The following is a list of the information in this chapter.
In Solaris Secure Shell, authentication is provided by the use of passwords, public keys, or both. All network traffic is encrypted. Thus, Solaris Secure Shell prevents a would-be intruder from being able to read an intercepted communication or from spoofing the system.
Solaris Secure Shell can also be used as an on-demand virtual private network, or VPN. A VPN can forward X Window system traffic or connect individual port numbers between the local machines and remote machines over an encrypted network link.
With Solaris Secure Shell, you can perform these actions:
Log in to another host securely over an unsecured network
Copy files securely between the two hosts
Run commands securely on the remote host
Solaris Secure Shell supportstwo versions of the Secure Shell protocol. Version 1 is the original version of the protocol. Version 2 is more secure, and amends some of the basic security design flaws of Version 1. Version 1 is provided only to assist users who are migrating to Version 2. Users are strongly discouraged from usingVersion 1.
Note –Hereafter in this text, v1 is used to represent Version 1, and v2 is used to represent Version 2.
The requirements for Solaris Secure Shell authentication are as follows:
User authentication – A user can be authenticated through either of the following:
Passwords – The user supplies the account password as in the login process.
Public keys – The user can create a public/private key pair that is stored on the local host. The remote hosts are provided with the public key, which is required to complete the authentication.
The source host maintains the private key, and target hosts are provided with the public key that is needed to complete authentication. Public key authentication is a stronger authentication mechanism than password authentication, because the private key never travels over the network. The public/privatekey pair is stored in the user's home directory under the .ssh subdirectory. The following table shows the default names for the identity files, which store the public keys and private keys.
Table 11–1 Naming Conventions for SSH Identity FilesPrivate Key, Public Key
Cipher and Protocol Version
identity, identity.pub
RSA v1
id_rsa, id_rsa.pub
RSA v2
id_dsa, id_dsa.pub
DSA v2
Host authentication – Host authentication requires the remote host to have access to the local host's public key. A copy of the local host's public key is stored in $HOME/.ssh/known_hosts on the remote host.
The following table shows the authentication methods, the compatible protocol versions, the local host and remote host requirements, and the relative security. Note that the default method is password-based authentication.
Table 11–2 Authentication Methods for Solaris Secure ShellAuthentication Method (Protocol Version) | Local Host Requirements | Remote Host Requirements | Security Level |
|---|---|---|---|
Password-based (v1 or v2) | User account | User account | Medium |
RSA/DSA public key (v2) | User account Private key in $HOME/.ssh/id_rsa or $HOME/.ssh/id_dsa Public key in $HOME/.ssh/id_rsa.pub or $HOME/.ssh/id_dsa.pub | User account User's public key (id_rsa.pub or id_dsa.pub ) in $HOME/.ssh/authorized_keys | Strong |
RSA public key (v1) | User account Private key in $HOME/.ssh/identity Public key in $HOME/.ssh/identity.pub | User account User's public key (identity.pub ) in $HOME/.ssh/authorized_keys | Strong |
.rhosts with RSA (v1) | User account | User account Local host name in /etc/hosts.equiv, /etc/shosts.equiv, $HOME/.rhosts, or $HOME/.shosts Local host public key in $HOME/.ssh/known_hosts or /etc/ssh/ssh_known_hosts | Medium |
.rhosts only (v1 or v2) | User account | User account Local host name in /etc/hosts.equiv, /etc/shosts.equiv, $HOME/.rhosts, or $HOME/.shosts | Weak |
Task | Description | For Instructions |
|---|---|---|
Create a public/private key pair | The use of public/private key pairs is the preferred method for authenticating yourself and encrypting your communications. | |
Log in with Solaris Secure Shell | Encrypted Secure Shell communication is enabled by logging in remotely through a process similar to using rsh. | |
Log in without a password with Solaris Secure Shell | You can log in using Secure Shell without having to provide a password by using ssh-agent. The ssh-agent command can be run manually or froma startup script. | |
Port forwarding in Solaris Secure Shell | You can specify a local port or a remote port to be used in a Secure Shell connection over TCP. | |
Copy files with Solaris Secure Shell | You can copy remote files securely. | |
Transfer files with Solaris Secure Shell | You can log in to a remote host with Secure Shell by using transfer commands that are similar to ftp. | |
Connect from a host inside a firewall to a host on the outside | Secure shell provides commands that are compatible with HTTP or SOCKS5. The commands can be specified in a configuration file or on the command line. |
How to Create a Public/Private Key Pair
The standard procedure for creating a Solaris Secure Shell public/private key pair follows. For additional options, see the ssh-keygen(1)man page.
Start the key generation program.
Enter the path to the file that will hold the key.
By default, the file name id_rsa, which represents an RSA v2 key, appears in parentheses. You can select this file by pressing the Return key. Or, you can type an alternative filename.
The public key name is created automatically. The string .pub is appended to the private key name.
Enter a passphrase for using your key.
This passphrase is used for encrypting your private key. A good passphrase is 10-30 characters long, mixes alphabetic and numeric characters, and avoids simple English prose and English names. A null entry means no passphrase is used. A null entry is strongly discouraged foruser accounts. Note that the passphrase is not displayed when you type it in.
Re-enter the passphrase to confirm it.
Check the results.
The key fingerprint, which is a colon-separated series of 2-digit hexadecimal values, is displayed. Check that the path to the key is correct. In the example, the path is /home/johndoe/.ssh/id_rsa.pub. At this point, you have created a public/private key pair.
Set up the authorized_keys file on the destination host.
Copy the id_rsa.pub file to the destination host. Type the command on one line with no backslash.
When you are prompted, supply your login password.
When the file is copied, the phrase “Key uploaded successfully.” is displayed.
How to Log In to Another Host With Solaris Secure Shell
Use the ssh command, specifying the name of the remote host.
The first time that you run the ssh command, a prompt questions the authenticity of the remote host:This prompt is normal. You should type yes and continue. If you have used ssh in the past on this remote host, then the prompt is not normal. You should check for a breach in your security.
Enter the Solaris Secure Shell passphrase and the account password when you are prompted for them.
Conduct transactions on the remote host. The commands that you send are encrypted. Any responses that you receive are encrypted.
Note –If you want to subsequently change your passphrase, use the ssh-keygen command with the -p option.
When you are finished with your remote session, type exit or use your usual method for exiting your shell.
How to Log In With No Password With the ssh-agent Command
If you want to omit passphrase and password entry when you are using Solaris Secure Shell, you can use the agent daemon. Use the ssh-agent command at the beginning of the session. Then, store your private keys with the agent by using the ssh-add command.If you have different accounts on different hosts, add those keys that you intend to use in the session.
You can start the agent manually when needed as described in the following procedure. Or, you can set the agent to run automatically at the start of every session as described in How to Set Up the ssh-agent Command to Run Automatically.
Start the agent daemon.
The ssh-agent command starts the agent daemon and displays its process ID.
Add your private key to the agent daemon.
The ssh-add command adds your private key to the agent daemon so that subsequent Secure Shell activity does not prompt you for the passphrase.
Start a Solaris Secure Shell session.
Example—Using ssh-add Options
You can use ssh-add to add other keys to the daemon as well. For example, you might concurrently have DSA v2, RSA v2, and RSA v1 keys. To list all keys that are stored in the daemon, use the -l option. To delete a single key from the daemon, use the -doption. To delete all keys, use the -D
option.How to Set Up the ssh-agent Command to Run Automatically
You can avoid providing your passphrase and password whenever you use Secure Shell by starting an agent daemon, ssh-agent. You can start the agent daemon from the .dtprofile script.
To start the agent daemon automatically, add the following lines to the end of the $HOME/.dtprofile script:
To terminate the Secure Shell agent daemon when you exit the CDE session, add the following to the $HOME/.dt/sessions/sessionexit script:
This entry ensures that no one can use the Secure Shell agent after the CDE session is terminated.
Start a Solaris Secure Shell session.
There is no prompt for a passphrase.
How to Use Solaris Secure Shell Port Forwarding
You can specify that a local port be forwarded to a remote host. Effectively, a socket is allocated to listen to the port on the local side. The connection from this port is made over a secure channel to the remote host. For example, you might specify port 143 to obtain email remotely with IMAP4.Similarly, a port can be specified on the remote side.
Note –Secure Shell port forwarding must use TCP connections. Secure Shell does not support UDP connections.
To set a local port to be forwarded, specify two ports. Specify the local port to listen to, and specify the remote host and port to forward to.
To set a remote port to receive a secure connection, specify two ports. Specify the remote port to listen to, and specify the local host and port to forward to.
Example—Using Local Port Forwarding to Receive Mail
The following example demonstrates how you can use local port forwarding to receive mail securely from a remote server.
This command forwards connections to port 9143 on myLocalHost to port 143, which is the IMAP v2 server port on myRemoteHost. When the user launches a mail application, the user needs to specify the local port number. Anexample that uses the dtmail command is shown in Figure 11–1.
Note that the term localhost in this case and in Example—Using Remote Port Forwarding to Communicate Outside of a Firewall refers to the keyword that designates the user's local host. The localhost keyword should not be confused with myLocalHost. The myLocalHostvariable is the hypothetical host name that identifies a local host in the examples in this chapter.
Figure 11–1 Specifying Port Forwarding for Email
Example—Using Remote Port Forwarding to Communicate Outside of a Firewall
This exampledemonstrates how a user in an enterprise environment can forward connections from a host on an external network to a host inside a corporate firewall.
Ssh Without Password Linux
This command forwards connections to port 9022 on myOutsideHost to port 22, the sshd server, on the local host.
This command demonstrates how after the remote forwarding connection has been established, the user can use the ssh command to connect securely from the remote host.
How to Copy Files With Solaris Secure Shell
Use the scp command to copy encrypted files between hosts. You can copy encrypted files between either a local and remote host, or between two remote hosts. The command operates similarly to the rcp command except that the scp commandprompts for passwords. See scp(1) for more information.
Start the secure copy program.
Specify the source file, user name at remote destination, and destination directory.
Type the Solaris Secure Shell passphrase when prompted.
After you type the passphrase, the progress meter is displayed. See the second line in the preceding output. The progress meter displays:
The file name
The percentage of the file that has been transferred at this point
A series of asterisks that are analogous to the percentage transferred
The quantity of data transferred
The estimated time of arrival, or ETA, of the complete file (that is, the remaining amount of time)
How to Transfer Files Remotely With the sftp Command
The sftp command works similarly to ftp, but uses a different set of subcommands. The following table lists some representative subcommands.
Table 11–3 Interactive sftp Subcommands| Category | Subcommands | Description |
|---|---|---|
Navigation | cdpath, | Changes the remote directory to path |
lcdpath | Changes the local directory to path | |
Ownership | chgrpgroupfile | Changes the group for file to group, a numeric GID |
chmodmodefile | Changes the permissions of file | |
File copying | getremote_file [local-path] | Retrieves a remote file and stores the file on the local host |
putlocal_file [remote_path] | Stores a local file on the remote host | |
renameold_filenew_file | Renames a local file | |
Directory listing | ls [path] | Lists the contents of the remote directory |
Directory creation | mkdirpath | Creates a remote directory |
Miscellaneous | exit, quit | Quits the sftp command |
How to Set Up Default Connections to Hosts Outside a Firewall
You can use Solaris Secure Shell to make a connection from a host inside a firewall to a host on the other side of the firewall. This task is done by specifying a proxy command for ssh either in a configuration file or as an option on the command line. For more information, see Example—Connecting to Hosts Outside a Firewall From the Command Line.
In general, you can customize your ssh interactions through a configuration file, either your own personal file $HOME/.ssh/config or an administrative configuration file in /etc/ssh/ssh_config. See ssh_config(4). There are two types of proxy commands. One proxy command is for HTTP connections. The other proxy command is for SOCKS5 connections.
Ssh Without Password
Specify the proxy commands and hosts in a configuration file.
Use the following syntax to add as many lines as you need:
where
- Hostoutside_host
Limits the proxy command specification to instances when a remote host name is specified on the command line. If you use a wildcard for outside_host, you apply the specificationto a set of hosts.
- proxy_command
Specifies the proxy command. The command can be either of the following:
/usr/lib/ssh/ssh-http-proxy-connect for HTTP connections
/usr/lib/ssh/ssh-socks5-proxy-connect for SOCKS5 connections
- -hproxy_server and -pproxy_port
These options specify a proxy server and a proxy port, respectively. If present, the proxies override any environment variables that specifyproxy servers and proxy ports, such as HTTPPROXY, HTTPPROXYPORT, SOCKS5_PORT, SOCKS5_SERVER, and http_proxy. The http_proxy variable specifies a URL. If the options are not used, then therelevant environment variables must be set. See the ssh-socks5-proxy-connect(1) and ssh-http-proxy-connect(1) man pages.
- outside_host
Designates a specific host to connect to. You can use %h to specify the host on the command line.
- outside_port
Designates a specific port to connect to. You can use %p to specify the port on the command line. By specifying %h and %p without using the Hostoutside_host option, the proxy command is applied to the host argument whenever the ssh command is invoked.
Run Solaris Secure Shell, specifying the outside host.
For example, type the following:
This command looks for a proxy command specification for myOutsideHost in your personal configuration file. If the specification is not found, then the command looks in the system-wide configuration file, ssh_config. The proxy command is substituted for ssh.
Ubuntu Ssh Without Password
Example—Connecting to Hosts Outside a Firewall From the Command Line
The -o option to the ssh command lets you type any line that is permitted in an ssh configuration file. In this case, the proxy command specification from the previous task is used.
Solaris Ssh Without Password Tp-link
Specify the proxy commands and hosts in a configuration file.
Run the ssh command. Include a proxy command specification as an argument to the -o option. For example, type the following:
This command substitutes the HTTP proxy command for ssh, uses port 8080 and myProxyServer as the proxy server, and connects to port 22 on myOutsideHost.