Can anyone give me some basic pointers and tips on ssh? (Specific questions at end.) Background. In the process of trying to compare and contrast the configuration differences across three different Linux laptops in my home--this in order to try to figure why one of them consistently fails to connect to imap.comcast.net (continuing saga; not what I wish to address here)--it occurred to me that I might be able to ssh from one computer into the others in order to see and copy certain portions of the different directory structures into a text file on my desktop. This so that I could study everything in a convenient, organized fashion in one place (again not the topic at issue; but, yes, I'm not the kind of person who can memorize a phone book.) Sure enough! I can ssh into Debian machine from Kubuntu machine. I can ssh into Debian machine from Ubuntu Mate machine. But connections are refused from Debian machine into Kubuntu and Ubuntu Mate and between Kubuntu and Ubuntu Mate machines. If I remember correctly, when I setup the Debian machine I opted to install a server. But that was months ago and I haven't thought it about since, nor do I even know where to find it. Does it boot with the machine and make itself available so that I can ssh into it? I don't know. Old as I am I'm still a server-side noob, barely a twinkle in my Daddy's eye. All I know about servers is that I've watched some videos and installed a couple of Ubuntu Server virtual machines for trying to learn some basics about understanding and managing networks and servers (became interested mostly because of the longtime foggy notion that I'd like to someday get a Raspberry Pi and setup a PiHole to work with our router; again, not the issue at hand, just more background for those of you who know me.) I've used ssh at the most basic level about half a dozen times in my life. So my questions are: 1. Is it not possible to ssh from the machine you are typing at into the target/host machine without having a server installed and running on the target machine? Are there permissions or shares or ports or whatnot that need to be configured on the target machines? To the best of my knowledge there are no firewalls running on the machines. 2. Where might general ssh learning time be best spent first? Any good cheat sheets or overviews to recommend? (Yes, I know what man pages are, and even how to use them passably well if I have a clear concept of what it is I'm supposed to be looking for.) Thanks, Tom
Tom Ashcraft writes:
Sure enough! I can ssh into Debian machine from Kubuntu machine. I can ssh into Debian machine from Ubuntu Mate machine. But connections are refused from Debian machine into Kubuntu and Ubuntu Mate and between Kubuntu and Ubuntu Mate machines.
If I remember correctly, when I setup the Debian machine I opted to install a server. But that was months ago and I haven't thought it about since, nor
One way to try to answer questions like this is aptitude search: % aptitude search ssh | grep server Admittedly, in this case it gives a fairly long list, so I'll skip to the chase and tell you the package you want is openssh-server. If you install it, it should configure itself so that you'll be able to ssh into that machine.
So my questions are:
1. Is it not possible to ssh from the machine you are typing at into the target/host machine without having a server installed and running on the target machine?
Correct. An ssh server must be running on the remote machine.
Are there permissions or shares or ports or whatnot that need to be configured on the target machines?
Installing ssh-server should take care of that.
2. Where might general ssh learning time be best spent first? Any good cheat sheets or overviews to recommend?
I don't know of a specific source, but googling [ssh basics] finds lots of tutorials, so maybe try some of those and see which one best fits your learning style. For ssh, tutorials will probably be more helpful than the man pages. Many tutorials will include a section on how to set up keys so you can ssh without a password. While that's certainly useful, I'd recommend skipping that part for now, until you're more comfortable with the basics of ssh with a password. ...Akkana
Akkana Peck writes:
Many tutorials will include a section on how to set up keys so you can ssh without a password. While that's certainly useful, I'd recommend skipping that part for now, until you're more comfortable with the basics of ssh with a password.
Using ssh keys and disabling passwords is the number one most important configuration to enable on any ssh server. This is the number of attempts by bots yesterday to break into my home PC via ssh. Not a server with a public domain name, but my desktop computer sitting in my apartment: # grep 'Jun 15' /var/log/authlog | grep sshd | wc -l 76010 That is approaching a hundred thousand attempts PER DAY. On a server not linked on any website or indexed by any search engine. I wouldn't trust a password to that, even my own reasonably well chosen ones. Back when I was an undergrad, I took a cybersecurity class in UNM's CS department. One kid ran a public ssh server for an assignment. A bot guessed his password. When the professor found out, he imaged the disk, and the next class assignment was to study the hard drive to figure out what the bots do once they succeed in breaking in. So what is it they do? First they silently replace passworded tools (sudo, ssh, and the like) with trojaned versions that log all passwords of all sites you log into. Then they set up bruteforcers and start using YOUR machine to attack more servers. And then they cover their tracks. I don't mean to scare people, but running an ssh server without disabling passwords is incredibly unsafe, both for oneself and for everyone else on the internet. Doesn't matter how good your passwords are--the risk of a compromised machine is too great. Disabling passwords is easy: in /etc/ssh/sshd_config, add the following line: PasswordAuthentication no Then restart the server (or restart the machine). Using keys is easy too. It is only two steps. Step one: on the client machine (the one you "ssh" *from*), run: $ ssh-keygen It will ask where to save it (default of ~/.ssh/id_rsa is fine), and ask for a passphrase to use (blank/no passphrase is perfectly fine). (Personally I run "ssh-keygen -t ed25519 -c 'my comment goes here'" but running just "ssh-keygen" is fine too.) Step two: copy the public key (it ends in ".pub", like ~/.ssh/id_rsa.pub) to the destination machine (the one you ssh *to*), at: ~/.ssh/authorized_keys Now you can ssh from the one machine to the other, with passwords disabled. You won't even have to enter a password (very convenient), yet it is vastly more secure than a password-enabled configuration. -- Anthony J. Bentley
Thank you, thank you, Anthony. As I say, you are a mensch! I have just now added 'PasswordAuthentication no' to /etc/ssh/sshd_config on all three machines and suspect I may have reason to figure out and look at /var/log/authlog with some care very soon. This evening when I first knowingly installed openssh-server on the Kubuntu machine and sshed in from the Debian machine it mentioned that my last login was April 15 (I believe) and I was a little taken aback at that as I don't quite recall having any server installed at that time except possibly (now that I think about it) I may have fiddled with one on an MX or antiX USB that I tested on that machine. Now I suppose I should try to figure out exactly how the ip address would have shown across the USB operating systems and the Ubuntu Server VM. Not to mention that I most certainly intend to heed the rest of your good advice below. I've heard it from you before in a different venue but did not at the time have sufficient conceptual or experiential infrastructure in place to fully grasp it. Tom On 6/16/19 9:40 PM, Anthony J. Bentley wrote:
Akkana Peck writes:
Many tutorials will include a section on how to set up keys so you can ssh without a password. While that's certainly useful, I'd recommend skipping that part for now, until you're more comfortable with the basics of ssh with a password. Using ssh keys and disabling passwords is the number one most important configuration to enable on any ssh server.
This is the number of attempts by bots yesterday to break into my home PC via ssh. Not a server with a public domain name, but my desktop computer sitting in my apartment:
# grep 'Jun 15' /var/log/authlog | grep sshd | wc -l 76010
That is approaching a hundred thousand attempts PER DAY. On a server not linked on any website or indexed by any search engine. I wouldn't trust a password to that, even my own reasonably well chosen ones.
Back when I was an undergrad, I took a cybersecurity class in UNM's CS department. One kid ran a public ssh server for an assignment. A bot guessed his password. When the professor found out, he imaged the disk, and the next class assignment was to study the hard drive to figure out what the bots do once they succeed in breaking in.
So what is it they do? First they silently replace passworded tools (sudo, ssh, and the like) with trojaned versions that log all passwords of all sites you log into. Then they set up bruteforcers and start using YOUR machine to attack more servers. And then they cover their tracks.
I don't mean to scare people, but running an ssh server without disabling passwords is incredibly unsafe, both for oneself and for everyone else on the internet. Doesn't matter how good your passwords are--the risk of a compromised machine is too great.
Disabling passwords is easy: in /etc/ssh/sshd_config, add the following line:
PasswordAuthentication no
Then restart the server (or restart the machine).
Using keys is easy too. It is only two steps.
Step one: on the client machine (the one you "ssh" *from*), run:
$ ssh-keygen
It will ask where to save it (default of ~/.ssh/id_rsa is fine), and ask for a passphrase to use (blank/no passphrase is perfectly fine).
(Personally I run "ssh-keygen -t ed25519 -c 'my comment goes here'" but running just "ssh-keygen" is fine too.)
Step two: copy the public key (it ends in ".pub", like ~/.ssh/id_rsa.pub) to the destination machine (the one you ssh *to*), at:
~/.ssh/authorized_keys
Now you can ssh from the one machine to the other, with passwords disabled. You won't even have to enter a password (very convenient), yet it is vastly more secure than a password-enabled configuration.
participants (3)
-
Akkana Peck -
Anthony J. Bentley -
Tom Ashcraft