Managing server over SSH

Enabling ssh login without a password

Say you frequently need to login from box A to box B with ssh. If you don't want to type in a password every time, you can setup an RSA key. This can also be used with rsync or scp to automate the transferring of files.

The trick with RSA keys is that only box A knows how to encrypt the data. Box B will have the public decoding key, so even if the decoding key is stolen, the thieves will not be able to login to B because they don't know how to encode the data (this a very rough analogy of it, OpenSSL does that on a different level, but close enough for this description). The main concept is that the "password" only exists on A.. and B (where we're connecting to) has no idea, nor needs to know, what it is. This is why keys are secure. The traditional method of passwords requires it to be set on B, and if lost, anyone can login from anywhere. Since the private encoding key never leaves your server, it makes things much safer.

1. First login to box A with ssh. Box A is where we're going to be connecting from.
2. Next, cd to your home directory, and ensure there is an .ssh folder:

cd
mkdir -p .ssh
cd .ssh

3. Create the public (id_rsa.pub) and private (id_rsa) keys:

ssh-keygen -t rsa

Press enter 3 times to use the default values, and to skip the passphrase. If you specify a passphrase, then a password would be required anytime the encoding key is used which somewhat defeats the purposes for this particular application.

4. We now have 2 files on box A, then id_rsa and id_rsa.pub. Insert the id_rsa.pub to box B's file ~/.ssh/authorized_keys. If box B already has an ~/.ssh directory and there are no other entries in the authorized_keys, you could use this to copy it over:

scp -C ~/.ssh/id_rsa.pub root@1.2.3.4:~/.ssh/authorized_keys

where you'd adjust root@1.2.3.4 to use the User and IP you're intending to use. If authorized_keys has other entires, then just copy/paste the contents of the id_rsa.pub to the next line of the authorized_keys file on B. Note, that the entire id_rsa.pub is only 1 line. If you end up with 2 or 3 lines with your paste, you've done something wrong. Each remote box only uses 1 line in the authorized_keys.

5. For safety, chmod your id_rsa to 600, to ensure it's kept secret:

chmod 600 id_rsa

6. Test it out to see if it works:

ssh root@1.2.3.4

which should log you into B, from A, without any password.

Quick reference list of files used:

~/.ssh/authorized_keys  -  Exists on B. Contains one or more id_rsa.pub lines for one or more incoming servers.
~/.ssh/id_rsa           -  Private encoding key on box A.  Don't give this out.
~/.ssh/id_rsa.pub       -  Public decoding key.  It starts on A, but place it's contents onto a new line in the ~/.ssh/authorized_keys on box B.

Copying files between servers using ssh/scp

SSH is a protocol usually used to login to a system to alter files. It can also be used for file transfers between systems. SCP is the software used to manage the ssh file transfer.

Let's make a few assumptions:

• You're logged into box A with IP 1.2.3.4
• You want to upload or download a file from remote box B with IP
• Box B users SSH User login @4.3.2.1
• Remote box B uses ssh on port
• Local file:
• Remote file:

Push a file from A to B

If you want to push a file from A to B, you'd run:

scp -p -P "22" -C "/path/to/A/local/file.txt" "root@4.3.2.1:/path/to/B/remote/file.txt"

Pull a file from B to A

The same idea is used to download a file from remote box B to the local box A, just swap the values:

scp -p -P "22" -C "root@4.3.2.1:/path/to/B/remote/file.txt" "/path/to/A/local/file.txt"

Additional notes:

For both upload and download, they will ask you for your password on B. If needed (eg: for background crons), you can automate the login process so A can connect to B without a password using an RSA Key.

For cron scp calls, we've received a report that you may need to run:

pkill ssh-agent

to clean up the scp calls

Running a command as a specific User

Sometimes you'll need to run some commands as a specific User, but that User might not have a shell setup. Instead of turning on ssh for that User, you can instead use sudo to open a new shell, running as that User.

Say you want to open a shell as .

To do this, you'd login to ssh as root, and run:

su - "root" -s /bin/bash

To confirm it worked, run the command:

/usr/bin/id

to see which uid the current shell is running as.

Troubleshooting

FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)

Report of cronjobs not being able to run due to expired pam token. This basically means there was an expiry set on the password of the account, so the password needs to be reset.

To see the current password restrictions on a given User , run this as root:

chage -l "root"

which might display Last password change : password must be changed Password expires : password must be changed Password inactive : password must be changed Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 14600 Number of days of warning before password expires : 14

If you wish to remove any restrictions, then type:

chage --maxdays 0 "root"

Starting sshd: /etc/ssh/sshd_config line 371: too many allow users

If you get the following error when trying to start sshd:

Starting sshd: /etc/ssh/sshd_config line 371: too many allow users

that means that there are too many "AllowUsers" lines in the file.

What you can do, is remove all AllowUsers lines from the /etc/ssh/sshd_config, edit /usr/local/directadmin/conf/directadmin.conf. Change:

sshdconfig=/etc/ssh/sshd_config

to:

sshdconfig=/etc/ssh/sshd_config.plecibo

Save/exit, restart DirectAdmin.

Type:

touch /etc/ssh/sshd_config.plecibo

and then just double check one more time that there are no AllowUsers lines in your /etc/ssh/sshd_conf file.

Restart sshd.

What this will do is have DA add/remove users to a file that is a plecibo, which doesn't have any effect. As long as there are no AllowUsers lines in the main /etc/ssh/sshd_config file, then all users are allowed to connect. If one or more AllowUsers lines are present in the main sshd_config file, then only those, hence the importance to not have any show up. Make fully sure you've restarted DA before leaving the system alone, else you migh allow ssh to 1 user, thus blocking root or any other user ssh access.

Note that the /etc/ssh/sshd_config file can be edited from within the Admin Level -> File Editor, so don't fret if you mess it up. You can fix it through DA.