This is an old revision of the document!
Table of Contents
SSH
How to set up SSH so I don't have to type a password
Using an ssh keypair enables us to scp files from machine to machine without needing a password<br /> The private key MUST remain private - if anyone gets hold of it, they can also transfer files to the remote machine.<br /> The private key stays on the local machine, the public key goes out to anyone who wants it!<br /> Or put another way, private key is on the sending machine, public key is on the receiving machine.<br /> *Generate a key-pair Run
0@@
to generate an RSA keypair. You now have 2 keys. The public key is stored in ~/.ssh/id_rsa.pub, and your private key is in ~/.ssh/id_rsa.<br /> *Upload public key to remote machine
1@@
Login to remote machine and
2@@
Check file permissions<br /> authorized_keys and id_rsa have to be 600<br /> id_rsa.pub can be 644
3@@
*Load your private key into an agent (optional) If you load your private key into an agent, it will hold the decrypted key in memory. Otherwise, you would have have to enter the key's passphrase (if you used one) every time you connect. To load the key, run
4@@
and enter the key's passphrase. (If your key is not in the default location ~/.ssh/id_rsa, you will need to provide the full path. For example, ssh-add ~/.ssh/id_rsa_my_ssh_key).<br /> If ssh-add says “Could not open a connection to your authentication agent.”, then you don't have a SSH agent running. Launch one using this command:
5@@
scp files to server adding automatically to known_hosts
When copying files to a server for the first time, you are asked if you want to add the servers fingerprint to the known_hosts file. To avoid the question and add automatically, use:
6@@
Problems?
- Permissions. Check your home directory is writable only by you (eg: 750), the .ssh directory is 700 and the id* and auth* files are 600.
- From the client (the one with the private key on it), add a -v switch to the scp command. This will show debugging info. -vv gives more. -vvv gives even more!
- On the server (remote machine), look at the logs to see if there is any more info in there (try /var/log/messages or /var/log/auth.log or /var/log/authlog or /var/log/secure)
- Check the /etc/ssh/sshd_config file on the remote machine for settings like StrictModes. If this is on, the permissions above will be important.
- After all these failed attempts, has your username been locked out?
On AIX, look at and reset the unsuccessful login counter:<br />
7@@
- Check the server log file:
vi /etc/syslog.conf and see where the auth logs go<br /> On AIX, this is /var/adm/syslogs/auth. This shows:<br /> Authentication tried for <user> with correct key but not from a permitted host <host><br /> authorized_keys file on the server will need 'from=“<ip addr>,<ip addr>,<ip addr>…”'<br /> On Redhat Linux, this file is called /var/log/secure<br /> <br />
- Start up another sshd server for diagnosis
Start up a second instance of sshd on an alternative port (on the server machine)
8@@
Keep that window open, as the debugging information is written to standard output. Then on the client, connect to the alternative port:
9@@
If the key is rejected, a reason for the rejection should be revealed on the server.
Client is still asking for password even though keys are setup?
Try forcing the ssh options… (useful if you cannot change the sshd config on the server)
10@@
References
Tunneling
Building an SSH tunnel can be very useful for working on the other side of firewalls.
References
Regenerate a public key from a private key
-y option spits out the public key!
11@@
A small script (seems to originate from Oracle) that sets up ssh keys between 2 accounts
12@@
A bigger (more elaborate) script that I also found embedded in an Oracle setup
13@@
Add this to /etc/ssh/sshrc to get the magic cookies added automatically
14@@
Some stuff I did to get tunnels open to an Oracle server - didn't work yet
15@@
16@@
17@@
18@@
19@@
20@@
21@@
22@@
23@@