Talk:OpenSSH

Wikibooks as further reading

There is a wikibook available under a CC license that can be linked to for Further Reading. http://en.wikibooks.org/wiki/OpenSSH What is needed to bring it up to the level where it can be included here? [18 Nov 2012] — Preceding unsigned comment added by 88.193.52.2 (talk) 13:24, 18 November 2012 (UTC)

cleaned up

That discussion page was a horrible mess, it needed a reboot. I have given it one. Please remember when posting to add your comment to the bottom of the page, or under what you're replying to, or else it becomes garbled, aslo, sign your comments using the four tildes so that it is easier to tell who's said what. 74.13.54.124 19:51, 12 July 2007 (UTC)

Possible point worth making...

One thing that might be worth pointing-out, and which none of the SSH manuals make clear, is that this software installs and starts FTP(SFTP) and Telnet(SCP) servers without your OK. Not only that, the SFTP server is totally without any limits as to where in the host disk-structure access is allowed.

Thus, if you installed SSH purely for secure portmapping (which many people do) this behaviour may be totally unexpected, and could in fact lead to your system's security being compromised instead of improved. The issue is more serious with Windows hosts, Linux hosts typically having some inherent directory-traversal protection by way of filesystem permissions, whereas Windows systems may not. In neither case is it a desirable situation, though.

Maybe the article could usefully mention this point?

--Anteaus 22:07, 18 October 2007 (UTC)

SCP is a file transfer protocol not related to telnet in ANY way and SFTP, while also a protocol for file transfer, is not FTP. It might be worth clarifying that the sshd daemon can also perform scp and sftp, but this should not be phrased as a biased warning. This is not only to remain NPOV, but because it is misleading--having shell access is more dangerous than being able to transfer files (and will be even more dangerous if the permissions for reading/writing/EXECUTING on a system are poor). --Karnesky 23:21, 18 October 2007 (UTC)

It may be useful to point out, if such additions are to be made, that it is very simple to disable sftp the interactive shell and password based logins. Geoff Riley 06:56, 19 October 2007 (UTC)

Agree, and apologies for SCP typo. However I don't think this is showing bias, just stating a demonstratable fact. An alarming one, too, considering that SSH will mostly find use on servers for establishing secure site-to-site portmappings, and not many admins would willingly give ordinary users telnet, or filesystem-root FTP access to a server. Yet, unless they've studied the manpages very thoroughly, they may not even realise they have inadvertently done so.

--Anteaus 09:48, 19 October 2007 (UTC)

It is a verifiable claim that sshd is able to be used to provide shell and file transfer access. I don't think it is verifiable or NPOV that many admins don't know this and wouldn't want it. The article for Secure Shell seems to address this quite well with "SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols." --Karnesky 15:05, 19 October 2007 (UTC)

Yes, it's a verifiable claim, but then to take an example, Samba also facilitiates file-transfer, BUT I've yet to see a Samba daemon which throws-open the whole disk-subsystem to all valid users by default as soon as you launch it. (Or even a Windows server-process, at least for non-Administrators.) Yes you could make either do so, but it would take a deliberate action on your part. Likewise any decent, so-called 'insecure' FTP server will have controls over which folders are published, and will not permit directory-traversal exploits such as 'dot-dot' paths. It's this total lack of bounds-limiting that I find alarming. Anyway, enough on this, think I've made my point.

--Anteaus 22:18, 19 October 2007 (UTC)

I think you're being a little unfair with your statements. What you say is true; however, you presuppose that people are so lacking in security skills that they allow just anyone to gain access; if this were really so then they would already be having problems long before attempting to install an OpenSSH service. I have, literally, thousands of attempted logins attempted every day with whole dictionaries being used; but none get into because I enforce good password regulations. SSH, and associated protocols, can only be accessed by people with an appropriate key --- password logins are disabled --- and the number of keys issued is very small.

You are only partially correct in stating that it "throws-open the whole disk-subsystem to all valid users"; yes, you can wander around the disk, but the user does not gain access to anything that the user would be allowed to with an ordinary old fashioned tty login.

Anything that you install needs to be set up appropriately, OpenSSH is no different in that regard: you mention Samba, well that takes quite a bit of setting up before it will do anything at all. Are you really suggesting that OpenSSH is just too simple to set up?

If you are just concerned with the Windows implementation then perhaps you are either unaware of or are forgetting about the administration shares that get set up by default and are often points of weakness because of bad passwords. Geoff Riley 08:23, 20 October 2007 (UTC)

Apologies for being so late to this discussion - I must have missed the invite;). I suggest that it is users who are considering the use of OpenSSH may find some benefit in being presented with information about default options - particularly where those defaults are likely to go against most users' intent. The presence of a Wikipedia article indicates that the topic is reasonably important and that some readers may benefit from learning about OpenSSH. Informing potential users about potential vulnerabilities would make up part of that important learning. If it is not possible to include a reasonably-sized section on configuration, or 'dangerous defaults', then maybe that should be its own article - or if a list exists elsewhere it can be referred to clearly within the current article. Please note that I am not an expert in ICT, and so my broad knowledge does not include OpenSSH. Were I to have a reason to use it, I would want to know about potential risks.

I also see a point made by Anteaus above, that SAMBA does not open the whole disk-subsystem to all valid users by default on launch. This is an interesting argument that has become slightly dated given the recent discoveries of SAMBA/SMB vulnerabilities that effectively do exactly that.

Finally, weak passwords is a side argument that is irrelevant to discussion of an individual tool. Ambiguosity (talk) 09:17, 4 June 2017 (UTC)

openssh.com vs. openssh.org

My understanding was that openssh.COM was the official domain name for the OpenSSH project, and openssh.ORG is not under the developers' control. Does anyone know why the article shows the website as http://www.openssh.org ? Both domains point to the same site at the moment, but it seems to me the article should really be showing the official domain name... EclecticMonk (talk) 14:40, 8 April 2008 (UTC)

Try using nslookup, it's not so hard. 74.13.60.58 (talk) 23:51, 9 April 2008 (UTC)

While they currently point to the same IP address, the concern was over the domain name ownership. Try using whois, it's not so hard. --Karnesky (talk) 01:33, 10 April 2008 (UTC)

I see you've updated it; fantastic. I probably should have just gone in and changed it, but I'm new here and lacking confidence :-) EclecticMonk (talk) 11:17, 15 April 2008 (UTC)

Userbox

If you use OpenSSH and SSHFS for networking on Linux, please feel free to put this userbox on your user page!

Code	Result
{{User:Ahunt/SSHFS}}	This user networks Linux PCs with OpenSSH and SSHFS.	Usage

If you want variations on this box please leave me a note here and I will make them up. -Ahunt (talk) 23:57, 15 April 2009 (UTC)

OpenSSH 6.8 features

Hello, MureninC! Regarding your edit that added new features for not-yet-released OpenSSH 6.8, in general we should stick to describing already released versions; as summed up in my revert, the section is called "Versions", not "Future versions". Also, the fact that code for some feature has been committed into project's source code repository doesn't necessarily mean that it's going to be part of the next release – it can always be reverted for some reason before 6.8 is actually released. As we know, the content you've added isn't lost, and can be easily restored once 6.8 is released. Hoping that you agree, I'm open to discussing this further. — Dsimic (talk | contribs) 21:03, 13 February 2015 (UTC)

Hello, Dsimic! No, I do not agree; please see WP:FUTURE: It is appropriate to report discussion and arguments about the prospects for success of future proposals and projects or whether some development will occur, if discussion is properly referenced. If you remove valid stuff from the article, it is lost. We cannot babysit the article to make sure that the information is placed back when the new release is released, such manual process and manual reminders and backnotes just don't make any sense in the context of Wikipedia, and are just not scalable, not to mention that they impact the ability of the non-English Wikipedias to have enough time to pick up any such information. Moreover, if you personally feel that "Versions" means "Past Versions" and can under no circumstance include upcoming ones, then you should move the new content under a new "New/Upcoming Versions" section, instead of removing it outright (however, I think such interpretation and the implied necessity of a "Future versions" section seem to be inconsistent with the no-branch release model of both OpenSSH and OpenBSD). MureninC (talk) 05:20, 14 February 2015 (UTC)

Please don't get me wrong, but you should speak for yourself – I do "babysit" articles, by reviewing all edits and maintaining my own to-do list that contains various tasks. Also, no "babysitting" almost always ends up in low-quality articles, software projects, you name it. With that in mind, you should be aware that I would be returning the content once OpenSSH 6.8 is released, if it would be still relevant of course. Mentioning scalability as an argument makes no sense whatsoever, as the rate at which substantial chunks of good-quality new content are added into Wikipedia (at least into computing-related articles) is quite low. Oh, and by the way, Slashdot posts shouldn't be used as a reliable sources. Anyway, I can also be careless to the same degree; thus, I can live with your addition to the article. — Dsimic (talk | contribs) 06:22, 14 February 2015 (UTC)

New Lead as of 3-3-2015

I have gone through and created a new lead within the article as part of a project for this course. I am open to constructive criticism and hope to make this article the best it can be. Thank You. JRammy (talk) 15:40, 2 March 2015 (UTC)

Hello! First off, why is the whole lead section bunched together into a single paragraph? That makes it so unreadable. Next, where did you get the "OpenBSD Secure Shell" part from? Following that, stating that OpenSSH is an "alternative to the proprietary SSH network protocol" is pretty much wrong, as it's an alternative implementation of the endpoints for the same protocol. I have more suggestions, but let's go with a few at a time, if you agree. :) — Dsimic (talk | contribs) 13:21, 7 March 2015 (UTC)

@Dsimic: I am definitely open to improvement and corrections. I used the initial statement from the previous version by user MureninC stating that OpenSSH was also known as Open BSD Secure Shell. I also confirmed the information via this link. As for the formatting, It was just a single thought, so I wrote it as a single intro paragraph. I am open to breaking it up. In the statement referencing an alternative version, I was referring to an alternative option or a free version of the SSH protocol. It may be semantics here, but I believe we are getting at the same thing. My understanding is that the OpenSSH protocol came from an earlier fork of the SSH protocol before it's source was closed and is now being distributed as an open source alternative to the SSH protocol that is not open source. If my understanding is incorrect, I am certainly open to correcting it. JRammy (talk) 02:31, 9 March 2015 (UTC)

@JRammy: My apologies for a delayed response, got distracted with all the work on other articles. First off, IMHO breaking the lede into three paragraphs made it much more readable. Speaking of "Open BSD Secure Shell", on second thought mentioning that name shouldn't hurt, however to my knowledge it's mainly used in various sshd startup scripts so noting that using a short {{Efn}} note might be a good thing.

Regarding the wording around the SSH protocol itself, please see the OpenSSH protocol specifications and this OpenSSH FAQ entry; in other words, there are no two different versions of the SSH protocols, and—apart from minor incompatibilities‍—‌OpenSSH and the commercial SSH implementation are able to interoperate. Thus, the lede should say something like "open-source alternative to the proprietary SSH implemenation" instead of "open source alternative to the proprietary SSH network protocol". Also, stating that the commercial SSH implementation "is commonly used to secure data communications" might be misleading until there are some references providing such statistics.

I'm probably going to have a few more suggestions, but let's discuss these first – if you agree, of course. :) — Dsimic (talk | contribs) 13:36, 22 March 2015 (UTC)

@Dsimic:I am amenable to all those changes and have incorporated them. Sorry for the delay in responding. Our class project is over and I haven't logged into Wikipedia in quite some time. JRammy (talk) 13:24, 27 March 2015 (UTC)

No worries about the delay. I'm glad that you agree with those suggestions; I've cleaned up the lead section a bit further, hopefully you'll agree with those changes. — Dsimic (talk | contribs) 17:15, 27 March 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on OpenSSH. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20020301095306/http://www.newsforge.com:80/article.pl?sid=01/02/16/1520247 to http://www.newsforge.com/article.pl?sid=01/02/16/1520247

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 23:57, 29 January 2016 (UTC)

 Done, all fine. — Dsimic (talk | contribs) 06:32, 30 January 2016 (UTC)

Tatu Ylönen link

Why Tatu Ylönen link redirect to https://wiki.riteme.site/wiki/Secure_Shell_Protocol

 Done Hi, @XP 2600: Tatu Ylönen redirects back here because different people created a number of redirects redirecting to each other to facilitate searches (Tectia, Tatu Ylönen, may be more). I have removed the link on Tatu Ylönen because it does not serve any purpose, as you noticed. Anton.bersh (talk) 08:36, 10 June 2021 (UTC)

Thank you! XP_2600 (talk) 10:58, 7 August 2024 (UTC)

Vulnerabilities:regreSSHion maybe?

RCE; affects a LOT of systems (excluding OpenBSD).

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt 2A02:AB88:6A88:9A80:892:5FDA:5E09:7528 (talk) 16:40, 4 July 2024 (UTC)