SSH Server Enabled By Default!
- Inicie sesión ou rexístrese para enviar comentarios
After installing Trisquel 6.0 desktop environment last night, and NOT selecting the "SSH Server" installation package, I have found this morning that the SSH service is indeed running on my desktop. I only selected the "Trisquel Desktop Environment" package during installation. It seems that this should be filed as something that should be "fixed". Please let me know what I can do in this regard.
Actually, SSH server is enabled by default in every Trisquel installation. Trisquel enviroment will include it too because you're asking the default Trisquel enviroment to be installed. If you download and install the packages for a desktop (just a desktop not desktop enviroment) like gnome it will not include SSH server by default.
SSH is secure and it has encryption so it's not a thing to worry about too much.
edit: it is not taken as an issue on Trisquel's world.
I and some other Trisquel users think that the SSH server running by default is an issue. We've expressed our concerns at https://trisquel.info/en/issues/2451 and maybe in other forum threads.
It is not an issue. It's an option and a policy. If someone think it shouldn't be, ask it as a feature request.
So Trisquel is an operating system which, for three years now according to https://trisquel.info/en/forum/ssh-server-enabled-default, has allowed for the installation of a desktop environment, which one could logically assume will be widely used by people who may not be versed in services and security and simply want a free desktop operating system with a graphical user interface, that opens up a listening port on all network interfaces by default, which allows communication to a commonly attacked and exploited service, without warning the user, and in fact, giving them the impression that no such condition exists?
For those who have influence over this project, please, for the integrity of the Trisquel project, change this behavior so that some poor ignorant user doesn't install the Trisquel Desktop Environment, set their account to a username of "bob" with a password of "bob", and have NO idea that their system is potentially open to compromise.
I am happy to do whatever I can to have this behavior changed. Screenshots, documentation, discussion, etc. The _ONLY_ reason that I stumbled upon this was by sheer accident. I look forward to a civil and considerate discussion.
It is not like that. In the following I'll post a text explainig this. On your offer of documenting, etc is good and in the text I mentioned I talked about it.
People using weak passwords is not a secutiry issue related to the SSH server but of users knowledge, policy and careless.
Hopely, no one has influence on the project leader. That could bring to loose perspective on the whole project.
I don't know if you understood properly, but this server gets installed and runs without many users knowing about its existence.
These users assume that on a desktop pc, no server is running, and so they decide for a weak password since there is normally no necessity for your home directory being strongly password protected.
And of course, they CAN assume that no server is running if not chosen otherwise during installation, so it's NOT their fault.
When I wrote "in the following" there's a missing word. It should say: "in the following days".
I'm aware of it. I'm the very first user who answer in this thread saying that openssh is install by default.
You say users assume there's no server running on their system so it's not they fault. But you assume that an attacker will break into their system. Ussuming it's not a proof of anything. The majority of users don't know what a server is. If they choose a strong password there's almost nothing to worry about in matters of security issues.
This is not about a security vulnerability, this is about password consciousness.
You can disable it and also block the ssh port.
The ssh server should only be installed if the user needs it.
It should not be installed by default and clearly not if someone chooses against an installation.
Every server service is a possible security risk and running an ssh server without using it is stupid.
WOW, this is a major issue. Not because it's SSH, but because it's the MOST INSECURE SSH setup I've ever seen. Just tested scanning my local area network running a Trisquel box. It runs on a default port with password based authentication (no KEYS!). What this means essentially is any script kiddie in the world can run a dictionary attack against all your local user accounts and gain remote access to your files.
Writing the developer mailing list about this seriously messed up default right now.......
Using fail2ban (which should be installed by default) with longer findtime and bantime than the default (say, one hour), it is OK to only rely on passwords.
Not really because it's impotent against a distributed brute force attack.
G4JC,
Please let me know how this goes or if I can contribute in any way.
There's no issue on it.
Don't write them. There are just a few of them and they don't need to be disturbed on non security issues.
Ha, I definitely should have noticed this before, except I don't use Trisquel as my main desktop. It's been busy though...
gnu@PC:/var/log$ grep -ir ssh /var/log/*
/var/log/auth.log:Feb 18 06:45:53 PC sshd[2700]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
/var/log/auth.log:Feb 18 06:45:55 PC sshd[2700]: reverse mapping checking getaddrinfo for customer-187-174-116-250.uninet-ide.com.mx [187.174.116.250] failed - POSSIBLE BREAK-IN ATTEMPT!
/var/log/auth.log:Feb 18 06:45:55 PC sshd[2700]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=187.174.116.250 user=root
/var/log/auth.log:Feb 18 06:45:55 PC sshd[2700]: pam_winbind(sshd:auth): getting password (0x00000388)
/var/log/auth.log:Feb 18 06:45:55 PC sshd[2700]: pam_winbind(sshd:auth): pam_get_item returned a password
/var/log/auth.log:Feb 18 06:45:55 PC sshd[2700]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user
/var/log/auth.log:Feb 18 06:45:57 PC sshd[2700]: Failed password for root from 187.174.116.250 port 44726 ssh2
/var/log/auth.log:Feb 18 06:45:58 PC sshd[2700]: Received disconnect from 187.174.116.250: 11: Bye Bye [preauth]
/var/log/auth.log:Feb 18 06:45:58 PC sshd[2703]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
/var/log/auth.log:Feb 18 06:46:00 PC sshd[2703]: reverse mapping checking getaddrinfo for customer-187-174-116-250.uninet-ide.com.mx [187.174.116.250] failed - POSSIBLE BREAK-IN ATTEMPT!
/var/log/auth.log:Feb 18 06:46:00 PC sshd[2703]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=187.174.116.250 user=root
/var/log/auth.log:Feb 18 06:46:00 PC sshd[2703]: pam_winbind(sshd:auth): getting password (0x00000388)
/var/log/auth.log:Feb 18 06:46:00 PC sshd[2703]: pam_winbind(sshd:auth): pam_get_item returned a password
/var/log/auth.log:Feb 18 06:46:00 PC sshd[2703]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user
/var/log/auth.log:Feb 18 06:46:02 PC sshd[2703]: Failed password for root from 187.174.116.250 port 46361 ssh2
In other news/the fix:
sudo apt-get remove --purge openssh-server winbind samba
(WinBind and Samba are only useful on a Windows network and are open ports as well)
And lastly (off-topic but related):
sudo modprobe -rf dcdbas
This will remove dcdbas driver which is used for flashing non-free Dell bios and for remote access to shutdown/startup pc when using Dell OpenManagement technology.
Thank you for the fix.
The log is a proof that there's no security issue on it.
It's good you post the whole command that removeds the software of the openssh server but don't called it a fix as there's nothing to fix.
Interesting, openssh-server, winbind and samba are required both by trisquel and trisquel-base.
Those are but metapackages, feel free to remove them.
Of course, but now I'm starting like everybody else: think of the children! Removing trisquel sounds pretty spectacular. Those two metapackages should not have such dependencies. Or at least trisquel-basic.
Perhaps a new clearly worded bug should be filed which wouldn't mention a firewall, unlike the old one that's marked won't fix. I'm all for removing ssh because I doubt most people will use it and because it presents an attack surface.
Exactly, that "issue" was about including a firewall not about ssh server despite talking about it there.
I doubt most people use ORCA. Do we must exclude it from beeing installed by default? No.
A bug in orca don't give people remote access to the system.
Would you prefer another examples? Abrowser opens ports...
What about Totem and zeitgeist?
There's no bug in openssh server.
None of those are servers, unlike ssh. If you want to remove abrowser, totem or zeitgeist, feel free to start another thread.
And it's absolutely ridiculous to say "there's no bug". No such piece of software without bugs. Here are the KNOWN bugs for openssh http://bugzilla.mindrot.org/buglist.cgi?product=Portable+OpenSSH
Both on this thread and on the feature request are not any bug posted. Known bugs are (supossedly) treated by openssh maintainers. Don't change my words. What I said was extremely clear.
Nobody here is talking about a bug in the SSH server. We are talking about a bug in the Trisquel distribution that should not run a SSH server out of the default install (without even telling the user that it is there).
To run openssh server is a decision made by the project leader not a bug. Thus, to talk about a bug here you need to say that openssh has one.
To think that the decision of having openssh by default is not good is request for a feature as Mzee made and I pointed out several times.
In this replies lembas said "A bug in orca don't give people remote access to the system.". Bug in ORCA is okey, bug in openssh is bad (obviously). That's what lembas try to make me (others) understand. So, yes, there are users talking about a (possible) bug in openssh.
If a decision made was a reckless one and causes a major security hole, that's a bug. The bug is the security hole, not SSH being installed by default, but the cause is SSH being installed by default.
A bug that is ultimately caused by a programmer or packager's poor decision is still a bug.
I am a member!
Thanks for the fix, G4JC.
I agree that this is a major security vuln, and I'm kicking myself for not noticing it sooner.
I use SSH to make outgoing connections to my server, but I have absolutely no reason to run the server daemon on my desktop, and certainly would never use password-based authentication(!!!).
I can't understand why this is enabled by default - it's exactly the kind of functionality that anyone who needs it knows how to install and enable it.
I hope it's removed promptly from future versions.
There's no security vulnerability.
quoted -- I can't understand why this is enabled by default - it's exactly the kind of functionality that anyone who needs it knows how to install and enable it. -- quoted
Newbies don't know such a things.
I am a member!
Newbies don't tend to use ssh. And if they did, they could easily apt-get install ssh-server.
They don't tend to use it because they don't know such a things. They could not easily install it because they do not know such a things. Learning curve.
Simply having it installed by default and without a notice does not make the user aware of it. She thinks no server is running and chooses a short password for convenience. She is screwed.
Notice that I use SSH on a daily basis. Yet, I see no point in installing an SSH server by default (no problem with the client... and for the same reason; it is a client; I see no problem with Abrowser). Someone who knows what SSH is certainly knows that firing 'sudo apt-get install ssh' will install it.
I am a member!
How about installing ssh and samba services, but leaving them disabled? Same for cups, if there's a security hole caused by having it enabled by default. Maybe the live installer can have a 'services' page where the user can select and configure these things, with the default option to leave them off in the standard "desktop" setup?
From a security standpoint, anything that is not used is a potential vulnerability. I am using a browser and my need for it outweights the issues arising from my usage. I don't do FTP, so having a FTP client around might mean something sometime, beyond the wasted space and bandwidth -- the system does not know I don't need FTP so it is going to try to updated it as well. A FTP server, now that is a dangerous thing.
antisnob (and others who think this is not an issue),
I think that there is a very basic misunderstanding here. I would like to address some very specific items. Please don't take these as personal attacks as I don't even know you so I have nothing against you.
On 24 February, 2014 - 15:55 antisnob said,
"It is not an issue. It's an option..."
Installing an SSH server that opens up a listening port on all network interfaces by default, which allows communication to a commonly attacked and exploited service, without warning the user, and in fact, giving them the impression that no such condition exists, is NOT an option when installing the Trisquel Desktop Environment when using the Trisquel 6.0 CD. The ONLY option that I had selected when installing was Trisquel Desktop Environment. There is an option at the top of the list to install an SSH server, but I did NOT have that selected. To summarize, when someone uses the Trisquel 6.0 installation CD and ONLY selects the Trisquel Desktop Environment, they end up with an SSH server running on their system.
On 24 February, 2014 - 16:17 antisnob said,
"There are just a few of them and they don't need to be disturbed on non security issues."
I'm not sure if there is a language barrier here, but I am concerned about your comments to not write the maintainers of Trisquel as It would seem quite contrary to ask people not to input information to an Open Source project. I'm assuming that you mean don't personally contact them, which I certainly have no intention of doing. The correct thing would be to do would be to open a bug. Perhaps you were suggesting an alternate method of communicating with the developers would be appropriate. I'm also worried that you, and perhaps others, are trying to convince themselves that there is no issue by simply repeating the words "non security issue" or "there is no security issue". I don't think that anyone would argue that if a person installed the Trisquel Desktop Environment, and set their username to "bob", and their password to "bob", and there was an SSH server running on the machine at the end of the install unbeknownst to them, that this would be considered a security issue.
On 24 February, 2014 - 16:01 antisnob said,
"...related to the SSH server but of users knowledge..."
That is EXACTLY what this discussion should be about. User's knowledge. User's are not informed that an SSH server will be installed when selecting the Trisquel Desktop Environment package, and are in fact given the opposite impression by the fact that the SSH Server option is not selected during the install process. This would be akin to including an SSH server, by default, without any notification, on every Windows XP installation.
Again, please don't anyone take this personally. I quoted antisnob because the person seemed to be the most vocal, which is perfectly acceptable. I think that the next appropriate step would be to open a bug on this, if that's possible.
MrMaui76, I'm antiesnob not antisnob (that's the English translation actually). I just wanted you to noticed that.
I ain't taking this as personal. Don't worry.
When I was talking about beeing an option I was just saying that Trisquel developers have taken that option. There are few of them and we must try to keep them on programming things without bothering and taking their time in discussions. I'm saying we should try to resolve as many things as we can by ourselves and give them solves things. This is a discussion not solved yet and we could do a lot of things before reaching them.
There are things to improved in installation and this is one among others.
Language barrier? Trisquel developers list is for developers, if you're not a developer of Trisquel don't use it. Because there's no bug here this does not need to bother developers on beeing contacted. Just open a new feature (done by Mzee). Password weakness is not a openssh bug and because its not related to openssh we could think of take a task to teach users about passwords weakness and policies. I agree this discussion should be about this but notice that didn't started this post saying that (well that was my impression) and most of users didn't post about that.
I didn't understood what you mention about Windows XP, could you explain it?
I am a member!
One reason that this is so serious, is that by implying during the installation that an SSH server will not be installed, users won't necessarily choose secure passwords for their user accounts.
The SSH server that is installed will allow access to anyone who has a valid username and password for the machine. If a user, thinking that there are no servers running on the machine, chooses a password of 'password', 'asdf' or 'bob', or some other unsecure password, they will almost certainly be hacked. Having such a weak account when there's a server running on port 22 is just asking for trouble.
lloydsmart,
You have summed up what I've been driving at nicely. That is the ONE and ONLY reason I even started this topic. The user simply is not made aware that an SSH server will be running on their system.
I couldn't find an issue for that, so I created one, which can be found here:
https://trisquel.info/en/issues/11188
Thank you, Mzee!
You are welcome. :-)
Guys, I'm sorry about not remaining my Ps and Qs but I have no time to write to everyone everything. I know it looks kinda roughly from me but I assure you I'm not trying to answer that way.
antiEsnob,
Sorry about the 'e', I honestly didn't notice.
That's fine if there are few developers. I don't recall anyone asking any developer to be a part of this discussion. This is an open forum that anyone can come and visit at any time so obviously they're welcome to participate at any time of their own free will. I'm not experienced at all with opening up "bugs" or things of that nature so I thought this was a good place to start a discussion on how to figure out the best way to get this VERY important issue fixed in Trisquel. Specifically with the installation of the Desktop Environment install. It seems like a great product with a serious flaw in its current state. What the developers do need to do, in my opinion, is fix the installation process so that users who install a Trisquel Desktop Environment don't end up with a running SSH server by DEFAULT, with NO WARNING. There is no user level interaction that should be considered acceptable because that would mean that every single Trisquel user would have to know about this issue first, and then take action on it which would hardly be considered a "fix".
I totally agree with your statement that there are things that can be improved and that this is one of them.
I mentioned the language barrier thing because you stated that the developers "don't need to be disturbed on non security issues." This IS a security issue, plain and simple, because people that install the Trisquel Desktop Environment package, and do NOT select the SSH Server option, still end up with an SSH server running on their computer.
As long as SOMETHING gets opened on this so that the Trisquel developers see it, and can act on it, then the goal of this discussion has been met. From that point on it's up to the developers to take this issue seriously, and hopefully do something about it.
I'm not sure how I could make my comments about Trisquel and Windows XP any clearer. Trisquel is a desktop operating system just like Windows XP. Can you imagine the security landscape if an SSH server was included with every installation of Windows XP, and no one knew about it? That is to say, what if the Trisquel Desktop Environment installation, in it's current state, were as popular as Windows XP? Then there would be a LOT of computers on the Internet running SSH servers without their owners even knowing that such a thing existed. I hope this clears things up.
I thank Mzee opening up an issue at https://trisquel.info/en/issues/11188 and look forward to progress being made.
I want to ssh to a remote machine. It has an ssh server running. Am I correct in thinking I only need an ssh client to do this i.e. no need to have a ssh server installed and running.
I've checked an sshd is not running on my 'Gluglug' machine. I take this to mean openssh-server is not installed. I don't think the openssh-client is installed either - can't find any reference to it on my machine. In fcat the only reference to openssh is in /usr/lib/openssh.
(1) Does executing ssh at the command line invoke the openssh-client or another (default?) client?
I have set up a basic firewall using iptables. Currently, my iptable rules do not include any relating to ssh either incoming or outgoing connections on any ports.
(2) I'm a little confused. Should I allow either an incoming or outgoing ssh connection in my set of rules to access the remote machine?
(3) Does the allowed port have to be 22 or is the choice up to me or the remote machine?
Thanks in advance.
Use e.g. "dpkg -l openssh-\*" to see if it's installed. Services
installed without running are harmless.
(1) Yes, /usr/bin/ssh is provided by openssh-client.
(2) You need an outgoing connection to access a remote server.
(3) The ssh server has port specified via e.g. "Port 22" in
/etc/ssh/sshd_config. Client specifies that port via the -p option
or a Port line in ~/.ssh/config for the specified host.
Thanks Michał. I able to connect to the remote machine now.
- Inicie sesión ou rexístrese para enviar comentarios