Tired of typing passwords to SSH servers you often access? Well get used to it! Passwords provide a high level of security, but but it have a tendency be tedious, and also prevent you from running local scripts that automatic logon to your server to perform tasks or you you simply will backup/copy files from your server to your local Mac. The good news is that's a simple solution to all this.

To enable automatic login to a SSH server, the server must have a copy of your public key. The key is signed by what we call a passphrase, meaning that, when you now access a server that got a copy of your public key it prompt your for your password (passphrase) instead of the system user account password. So we really did not fix the problem, we just shifted the problem, but we shifted it in the right direction, and now we can do something about it.
Passphrase exchange
The most daring users, simply create a public key with a empty passphrase. This introduce a security problem. If you somehow gained access to a copy of your privat key, they will gain access to all the servers that trust your key.

A more secure way of solving this is using a program (ssh-agent) to propagate the passphrase. This solution is quite good, but like everything else it comes with a few drawbacks. You need to have your shell environment set up correctly, and only application with the correct environment setting is able to benefit from it. In OS X you are able avoid this problem simply by using the system utility "Keychain Access". It will store and propagate your passphrase, and in Leopard (10.5) Apple finally introduced native support for using Keychain Access also in terminal.
OS X has native support for creating and storing pass phrases (Keychain access) so setting this up on your Mac is not that hard. Linux users that are reading this can also follow along then the only difference is what application you use to store the passphrase. Like an example will Gnome users normally use the Gnome Keyring application.
ssh-keygen -t rsa
ssh-keygen will the ask where to store the public key it is about to create. Normally the default suggestion works just fine (~/.ssh/id_rsa.pub). ssh-keygen then ask you to enter a pass phrase. Please use something secure here and please also remember it.
cat ~/.ssh/id_rsa.pub | ssh username@example.com "cat - >> ~/.ssh/authorized_keys" scp ~/.ssh/id_rsa.pub username@example.com:~/.ssh/authorized_keyschmod 0600 ~/.ssh/authorized_keys to even further improve your system security.
Now you should be all set. The very first time you access the server by ssh, Keychain will prompt you for your keyphrase and then store it and you will never have to type it again.
Kommentarer
John Son (ikke bekreftet)
ons, 26.01.2011 - 20:22
Permanent lenke
By disabling password-based
By disabling password-based authentication and requiring ssh key pairs, you reduce the chances of compromise via a brute force attack. This can also help you protect against weak account passwords since a valid private key is required to gain access to the server. However, a weak account password is still a big problem if you allow your users to use sudo.link building software
webmaster
lør, 02.04.2011 - 21:29
Permanent lenke
Older post but still a good
Older post but still a good read, updated and added more information, language cleanup + added a few illustrations to it.
james (ikke bekreftet)
tor, 02.06.2011 - 20:12
Permanent lenke
As long as this isn't going
As long as this isn't going to affect my system security I am willing to give it a try, but I will have to ask an IT engineer for help just to make sure nothing goes wrong. You never know who is out there waiting to get a hold of your business data so I would rather not risk to have my content security damaged in any way.
Razor Bumps (ikke bekreftet)
tor, 16.06.2011 - 14:46
Permanent lenke
It is possible to automate
It is possible to automate SSH connections by generating “passphrase-less” secure keys and modifying our connection settings to use the new keys. In general, I would only recommend this procedure if you have a specific requirement for automating file transfers, and you clearly understand the security implications.
waqas786 (ikke bekreftet)
lør, 02.07.2011 - 03:33
Permanent lenke
their very own SSH/telnet
their very own SSH/telnet connection. Avoiding might be found you should maintain your system up-to-date by installing a firewall along with the lates
5 htp benefits
Rod Khleif (ikke bekreftet)
fre, 15.07.2011 - 17:20
Permanent lenke
If you want to avoid having
If you want to avoid having to input your password to log to a machine, you have to generate a pair of public/private keys and copy the public one to the machine where you want to log.
Alexey (ikke bekreftet)
lør, 03.09.2011 - 19:53
Permanent lenke
#!/usr/bin/expect -f
#!/usr/bin/expect -f
if { [llength $argv] < 3 } {
send "Usage: ssh2 <hostname> <username> <password> <su password (optional)>\n"
exit;
}
set host [lrange $argv 0 0]
set user [lrange $argv 1 1]
set pass [lrange $argv 2 2]
set supass [lrange $argv 3 3]
set timeout -1
spawn ssh $user@$host
match_max 100000
expect {
"*yes/no*" {
send -- "yes\r"
exp_continue
}
"*?assword:*" {
send -- "$pass\r"
}
}
interact
xenon hid lights (ikke bekreftet)
ons, 19.10.2011 - 14:18
Permanent lenke
Thanks for taking the time to
Thanks for taking the time to discuss about this, I feel strongly about it and love learning more on this topic. If possible, would you mind updating your blog with more information? It is extremely helpful for me.
Skriv ny kommentar