We want to script some jobs using ssh. The security people recommend using SSH with keys, but no pass phrases. They say that this encrypts the data transfers etc. I’m no expert by any means, but from what I’m reading is that keys with no passphrases will authenticate but not encrypt.
So, how safe is SSH with keys but no passphrase? Cites please. Cites in plain english preferred.
http://www.snailbook.com/faq/no-passphrase.auto.html
May be of help. It does not look like they like it.
Nah, it’ll encrypt. It’s also a bitch to set up.
I’ll dig around for some cites… gimme a couple of minutes. I recall a rather informative article in the Linux Journal from a couple of months ago detailing the entire setup process, but I don’t recall specifically how Englishish it was.
Here’s a tutorial on doing it with scp:
http://www.linuxjournal.com/article/8600
The criticisms in gazpacho’s link are valid; however, they don’t have anything to do with encrypting the traffic, and they’re valid for basically any scripted job that deals with remote systems, over any protocal, including ssh-over-ssl-over-vpn-over-courier-pigeon.
OpenSSH encrypts the whole session.
I’d have to second the “don’t do it!” command regarding not using passphrases. If someone gains access to your box, through whatever means, they automatically gain access to every other box you have a key on.
Before I configured my iptables (I run Debian Linux) to increment the ssh login on every failed connection attempt, I was getting a random person trying to log on to my system once every day or so. Granted, they’re just script-kiddies and just have a list of common names/passwords to try (of course, “Administrator/password” was one of them to target ignorant Windows users), but scanning happens more than you might think. And who knows what they’d do if they did gain access…
I guess I’m seeing/understanding that it will be encrypted throughout. That’s nice.
But here’s another asociated question. We will be running these scripts as root on the local system, and want root permissions on the remote system. How safe is that?
Also, doesn’t that mean that we’d have to allow root to ssh in? (That is, allow any ssh user the ability to supply “root” as their userid and let them hack away at a password? I believe we have our configs set to deny that at the moment.)
It depends on what you’re trying to do.
It might be worth configuring your setup to allow non-root, system users to run the scripts. Or putting the user in a group with elevated permissions that’s not quite root.
Or if you absolutely must run them with root permissions, investigate setuid. It’ll allow the script, or whatever, to execute with root permissions (hopefully) temporarily. It’s normally considered a great big gaping security hole, but in some contexts, it’s the only way to do something.
As black455 says. My immediate reaction was to say no, don’t allow root login. But you have to consider the alternative – it’s better than, say, doing it over telnet.
I’d suggest looking into suid or perhaps into expect (the thought being that you could set up your ssh-agent, login with a public key, then do an su to the user you need; of course, that user can’t be root, because then you’re storing the plaintext root password in the expect script).
How automatic does your process have to be?
I had to do something similar a while ago, but I made it so that my script would ask for the connection password every time it ran. It would then store the password in a temporary variable and use expect to automate the rest of the SSH/SCP connections. Basically, no keys or passphrases were saved in files – a human just has to manually login once per session. If you’re anticipating long uptimes for these machines, that “once per session” may only be once every few weeks or months.
Or, you could consider something like the following (very convoluted) setup: You’d use one “master” machine to control the others. Write a script that would SSH from the master system to remote system A and then force remote system A to SSH to remote system B. The remote systems would not have passwords saved anywhere and would rely on the master to provide them. The master script could either ask for the passwords every time or store them in a file – but even then, you’d only have one secret file to worry about instead of one on every machine. If one of the remote systems gets compromised, just disconnect it and it won’t be able to log back in because it doesn’t have the password.
If you’re worried about the master getting compromised, change the setup slightly. Each remote system A would have a script that connects it to a remote system B, but the script doesn’t know the password and will have to wait for the master to provide it. The SSHD user that runs this script would be a very limited account (NOT root anymore) who cannot do anything except run the script – he’ll have execute permissions on that one script and that’s it. The master script would connect to remote system A and provide it with the password, and system A would run the script to connect to B and do all the other fun stuff. This way, if the master gets compromised, all it can do is force the remote systems to reconnect to each other. It can’t change anything on them.
Thanks to all.
I’ll implement as many of the instructions as I understand (where I can).
FWIW, I’m a little hacked off at our “security team” for telling me I had to use ssh with keys but no passphrases without any guidelines or examples of -how- to get that done. I asked them how, they said: “Google it”. Thanks “security team”! Googling for ssh returns so few hits. :rolleyes: