Fri, 27 Jan 2012
/Admin/SSH-SSL:
Passwordless Authentication with SSH
How to use SSH keys to login to your server without giving a password -- perhaps contra-inuitively,
this kind of passwordless login is usually more, not less, secure then a password login. (Not
to mention convenient and time-efficient....)
Say we want to login to server.com from our desktop without a
password. The rdiff-backup wiki provides a somewhat obtuse and
hard-to-read article[1] on the subject. For the basics, I prefer to
start with this article[2].
On your desktop, run:
ssh-keygen -b 4096 -t rsa -f /home/username/.ssh/id_rsa
Do not enter a pass-phrase!! Leave it blank
(Note: we are creating a 4096 bit key here as recommended by
nearlyfreespeech.net[3]. It is possible that some situations will
require a 1024 bit key, and this key will not be useable in that
situation. It is possible to have multiple keys, which may be invoked by the "ssh -i" option, for instance.)
Now copy the public key "id_rsa.pub" to root@server.com:
scp /home/username/.ssh/id_rsa.pub root@server.com:
Go to server.com and append the new key to the authorized_keys:
ssh server.com
cd /root/.ssh/
cat ../id_rsa.pub >> authorized_keys
Restrict access to these keys on both your desktop and your
root@server:
chmod -R go-rwx ~/.ssh
Test to verify you are not prompted for a password. In a terminal on
your desktop, try a verbose ssh to server.com:
ssh -v root@server.com
If there are problems and you are prompted for a password (you should
not be) the -v output should give you some clues.
In some situations, one can make SSH key logins even more secure. For instance, on server.com, add
some security directives to a particular key in /root/.ssh/authorized_keys by pre-pending the
following:
command="rdiff-backup --server
--restrict-read-only/",no-port-forwarding,no-X11-forwarding,no-pty
ie. in /root/.ssh/authorized_keys the key in qestion now contains the
following, ALL ON ONE LINE, and note the single space before "ssh-rsa":
command="rdiff-backup --server --restrict-read-only
/",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa
AA ... uqdswe= user@desktop
"no-pty" explicitly forbids terminal priveleges. "command" here
restricts the session to running one and only one command: "rdiff-backup
--server --restrict-read-only".
Now if you try to ssh to root@server.com from a terminal, your
terminal will just lock-up and stop responding. If you really do want to
allow this (a terminal ssh to root@server.com without a password) just
remove the "command" and "no-pty" directives from the server.com
/root/.ssh/authorized_keys file.
Note that this will only work from the account "username" on your
desktop machine where you have generated a /home/username/.ssh/id_rsa
file and then passed the public key to server.com. Trying to ssh from
any other desktop account to root@server.com will result in a password
prompt.
[1] http://wiki.rdiff-backup.org/wiki/index.php/UnattendedRdiff
[2] http://linuxgazette.net/104/odonovan.html
[3] https://members.nearlyfreespeech.net/ckoen/support/faq?q=SSHKeys#SSHKeys
posted at: 06:51 | path: /Admin/SSH-SSL | permanent link to this entry
Fri, 26 Aug 2011
/Admin/SSH-SSL:
Some SSH Tricks
You can re-use existing SSH connections by adding this to ~/.ssh/config file:
Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p
Thereafter, after you login and open a connection to an SSH server, if you open another connection from another terminal, it will re-use
the first connection. No need to login again, no need to wait for the connection to be re-negotiated. Over a slow, long-distance SSH
connection, this can slow the wait time from tens of seconds to two seconds. This applies to SCP transfers as well. Much saved time.
If you have a long list of servers you log into regularly, particularly on non-standard ports, these connections can also be aliased in
the ~/.ssh/config file:
Host my-chosen-alias
Hostname server.com
IdentityFile /path/to/id_rsa
User root
Port 10122
Thereafter, "ssh my-chosen-alias" will connect to root@server.com on port 10122. Unfortunately SCP does not seem to respect these aliases,
or at least I have not found out how to make that work. But this is a way, for instance, to transparently get backuppc[1] to connect to a
backup client using a non-standard port.
[1] http://blog.langex.net/index.cgi/Admin/backups/backuppc/
posted at: 10:22 | path: /Admin/SSH-SSL | permanent link to this entry
Tue, 27 Jul 2010
/Admin/SSH-SSL:
OpenSSL Cheat Sheet
Extract information from a certificate:
openssl x509 -text -in /path/to/certificate.pem
Create a new self-signed certificate good for ten years:
openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/new-certificate.pem \
-keyout /etc/ssl/private/new-key.pem
References:
http://www.madboa.com/geek/openssl/
posted at: 04:07 | path: /Admin/SSH-SSL | permanent link to this entry
Thu, 16 Jul 2009
/Admin/SSH-SSL:
SSH Constantly Connecting: ServerAliveInterval
I cannot believe I put up with this for so long: in the past when I
connected to servers outside China, the SSH session would consistently
disconnect after the terminal had been idle for only a very few minutes.
This was very consistent, far more then "every once in a while". (I am
guessing there was some Great FireWall-related foul play involved....)
Thanks to Donncha[1] I have an elegant one-line solution by adding
the following to /etc/ssh/ssh_config:
ServerAliveInterval 60
This causes my ssh client to send a "keep alive" message to the
server after 60 seconds of inactivity. Only if the server fails to
respond is the connection broken. Even in China, this seems to be quite
efficient at keeping my international ssh connections open for hours at
a time.
[1] http://ocaoimh.ie/how-to-fix-ssh-timeout-problems/
posted at: 12:06 | path: /Admin/SSH-SSL | permanent link to this entry
Sat, 04 Apr 2009
/Admin/SSH-SSL:
Free SSL Certificates
If you run any kind of secure, encrypted public service on your server,
like https for instance, you can of course use a self-signed certificate.
And then you may get e-mail from users asking what is wrong with your
server, when their web browser complains about an untrusted certificate.
However, buying a certificate from a commercial provider ranges from
expensive, to very expensive, especially considering the actual small value
of the service they are providing[1].
Generating your own certificates is really easy[1]. There are also
organizations that provide free certificates[2][3].
[1] http://www.golden-gryphon.com/blog/manoj//blog/2009/03/31/Fighting_FUD__58___Working_with_openssl/
[2] http://www.cacert.org/
[3] http://www.startssl.com/
posted at: 05:53 | path: /Admin/SSH-SSL | permanent link to this entry
Mon, 02 Feb 2009
/Admin/SSH-SSL:
Controlling Multiple Machines with Cluster SSH
If you find yourself doing exactly the same set of steps on more then
one machine, then Cluster SSH[1] is an option. Its very simple to get
started. In ~/.csshrc define the set(s) of workstations that you would like
to control:
<![CDATA[
clusters = <tag1> <tag2> <tag3>
<tag1> = host1 host2 host3
<tag2> = user@host4 user@host5 host6
<tag3> = <tag1> <tag2>
]]>
Then execute "cssh tag1" and three terminals, one each for tag1, tag2,
and tag3 will appear, plus the cssh control window. Any text typed into the
control window will be echoed in all terminals.
If passwordless authentication has not been configured for the remote
boxes, then you will have to enter a password in each terminal at the start.
[1] http://sourceforge.net/projects/clusterssh/
posted at: 09:11 | path: /Admin/SSH-SSL | permanent link to this entry
