{"id":12127,"date":"2025-10-13T01:05:00","date_gmt":"2025-10-13T05:05:00","guid":{"rendered":"https:\/\/www.both.org\/?p=12127"},"modified":"2025-10-11T10:24:54","modified_gmt":"2025-10-11T14:24:54","slug":"rethinking-su-vs-sudo","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=12127","title":{"rendered":"Rethinking su vs sudo"},"content":{"rendered":"<div class=\"pld-like-dislike-wrap pld-template-1\">\r\n    <div class=\"pld-like-wrap  pld-common-wrap\">\r\n    <a href=\"javascript:void(0)\" class=\"pld-like-trigger pld-like-dislike-trigger  \" title=\"\" data-post-id=\"12127\" data-trigger-type=\"like\" data-restriction=\"cookie\" data-already-liked=\"0\">\r\n                        <i class=\"fas fa-thumbs-up\"><\/i>\r\n                <\/a>\r\n    <span class=\"pld-like-count-wrap pld-count-wrap\">    <\/span>\r\n<\/div><\/div>\n<p>If you&#8217;ve been hanging around Both.org for a while, you&#8217;ve undoubtedly noticed that I much prefer using the <strong>su &#8211; <\/strong>command to obtain elevated privileges on my Linux systems rather than the <strong>sudo<\/strong> command. I&#8217;ve written more than one <a href=\"https:\/\/www.both.org\/?p=2692\" data-type=\"link\" data-id=\"https:\/\/www.both.org\/?p=2692\" target=\"_blank\" rel=\"noreferrer noopener\">article<\/a> about appropriate uses for <strong>su<\/strong> and <strong>sudo<\/strong>. But I like to explore new ways of doing things. So, for at least 3 reasons &#8212; one of which is that I&#8217;m an unfit SysAdmin for my own network and the computer protection services (CPS) might come to remove them from my home and place them somewhere safer &#8212; I decided to stop using the <strong>su<\/strong> command and force myself to use <strong>sudo<\/strong>. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Why I did it<\/h2>\n\n\n\n<p>The primary reason I decided to give <strong>sudo<\/strong> a chance is that I haven&#8217;t been changing passwords very frequently for my internal network hosts, especially for some of the less-used test accounts I create when experimenting. My router\/firewall is definitely an exception to that. I also needed to ensure that all of the passwords are encrypted with yescrypt. yescrypt is a more secure encryption method than is the previous SHA-512 method.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How to determine the password encryption method<\/h2>\n\n\n\n<p>Before we go much further, we need to take a short side-trip to understand just a little about the \/etc\/shadow file, which contains the encrypted passwords for accounts that have them. <\/p>\n\n\n\n<p>The \/etc\/shadow file contains a line for every user ID on your Linux system. This is where the encrypted passwords are stored for users on your system. Most of those UIDs are for system accounts and don&#8217;t have passwords. Human users are usually few on today&#8217;s systems so you&#8217;ll only find two or three accounts with passwords.  The three IDs shown here illustrate a bit about what this file looks like. The lxdm account is for the lxdm <a href=\"https:\/\/www.both.org\/?p=4555\" data-type=\"link\" data-id=\"https:\/\/www.both.org\/?p=4555\" target=\"_blank\" rel=\"noreferrer noopener\">display manager<\/a> and it doesn&#8217;t have a password &#8212; like many other system accounts. That&#8217;s indicated by the exclamation point (!), aka, the &#8220;bang,&#8221; in the second field of the shadow entry, which is the password field.<\/p>\n\n\n\n<p>The second account is for a test user that I use for experimentation and it does have a password. The first three characters of the password field in this entry are $6$ which is used to specify the encryption method used. In this case, the 6 indicates that this password is encrypted using the SHA-512 method.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>lxdm:!:20193::::::\ntestuser1:$6$j9T$oQeeqedOSQWS9YaLHAGDG$O8&lt;SNIP&gt;6lyGx7UFtg4:20363:0:99999:7:::\ntestuser2:$y$W3gDNhne4mCFishV$kTYsium&lt;SNIP&gt;1Riko^TEjKjfJv0:19631:0:99999:7:::<\/code><\/pre>\n\n\n\n<p>The last line in this sample is another test user I created. In this entry, $y$ indicates that this is already a yescrypt password so doesn&#8217;t need to be changed &#8212; unless it&#8217;s time to change it based on its age.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How I did it<\/h2>\n\n\n\n<p>Since testuser1 still uses SHA-512 encryption, it needs to be changed to yescrypt. It&#8217;s truly simple. Just change the password as you normally would using the passwd command &#8212; or the user management GUI application if your GUI desktop provides one. No special options are required. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">So now sudo<\/h2>\n\n\n\n<p>The first passwords I changed were the root passwords on all my systems. I&#8217;d previously created very long and random passwords for my firewall system so that all the script kiddies can bang their heads on it all they like. But long, complex passwords can&#8217;t be memorized, and writing them down is &#8212; well, just shoot me now. That means that I need an easier method to boost my privilege level to root when necessary. <\/p>\n\n\n\n<p>Seth is one of the editors for Both.org, and we&#8217;ve had an ongoing discussion about using <strong>su &#8211; <\/strong>vs <strong>sudo<\/strong>. I have been all-in for <strong>su<\/strong> because it&#8217;s the historical method and <strong>sudo<\/strong> is for providing limited access to a few commands for non-root users. Seth&#8217;s preference is for <strong>sudo<\/strong> because it&#8217;s more secure. <\/p>\n\n\n\n<p>So, much to my chagrin, Seth, I find that the <strong>sudo<\/strong> command becomes necessary.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A final thought<\/h2>\n\n\n\n<p>So &#8212; yeah &#8212; I&#8217;m also going to be more proactive about changing passwords.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>If you&rsquo;ve been hanging around Both.org for a while, you&rsquo;ve undoubtedly noticed that I much prefer using the<\/p>\n","protected":false},"author":2,"featured_media":2702,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[5,75,89,841],"tags":[662,261,838,299,842],"class_list":["post-12127","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-security","category-system-administration","category-tips","tag-password","tag-security","tag-su-2","tag-sudo","tag-tips"],"modified_by":"David Both","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/12127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=12127"}],"version-history":[{"count":22,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/12127\/revisions"}],"predecessor-version":[{"id":12186,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/12127\/revisions\/12186"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/2702"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}